2ª Escola Potiguar de Computação e suas Aplicações Natal-RN 18 a 20 de novembro de 2009

Tamanho: px
Começar a partir da página:

Download "2ª Escola Potiguar de Computação e suas Aplicações Natal-RN 18 a 20 de novembro de 2009"

Transcrição

1 2ª Escola Potiguar de Computação e suas Aplicações 18 a Natal-RN 20 de novembro de 2009

2 Índice ConBus: Uma arquitetura de middleware para provisão de contexto em dispositivos móveis 1 Uma Ontologia sobre Aprendizagem Colaborativa Apoiada por Computador 7 Utilização do ESB em sistema de monitoramento de ovinos e bovinos confinados: uma abordagem didática 14 Análise comparativa de Framework com Jquery 21 Roteamento em Algoritmos IA-RWA em Redes Ópticas Limitadas por Dispersão de Modo de Polarização 27 Clusterização de Dados Coletados do Exame de Glicemia Usando o Algoritmo Fuzzy C-Means Intervalar 33 Banco de Dados Objeto-Relacional: comparação do suporte oferecido por SGBDs para a persistência de objetos 40 Abordagem com interação entre as camadas de aplicação, roteamento e MAC para redes de sensores sem fio 46 Heterogenous e Camaleão: Gestão e Difusão Contínua do Conhecimento para Desenvolvimento de Softwares em Ambientes Heterogêneos 54 Um Jogo Eletrônico para a Educação Ambiental 60 Computação Ubíqua: dos anos 90 ao século XXI 66 Proposta de Modelo Gerador de Regras de Navegação Adaptativas usando proxy Squid 72 Estudo da Viabilidade Técnica da Implementação de Referência Ninf-G para Computação Distribuída Baseado na ISO/IEC Projeto e Implementação de um Servidor para Persistência e Recuperação do Estado de Persistent Browser-Based Games 84 Um Protótipo para a Simulação do Acionamento dos Preventores de Erupção em Poços Petrolíferos 90 Técnicas de Sistemas de Gerenciamento de Banco de Dados em Tempo-Real para Redes de Sensores sem Fio 96 Uma Solução para a Recepção de Vídeos em WLANs com Mobilidade Limitada 104 EnigMaze: Um jogo Educacional para a TV Digital 110 Geração automática de casos de testes para interface gráfica 115 Uma solução para a gestão de autenticação em redes através do padrão X: Arapuca 121 Visualização de requisitos a partir de modelos em AOV-Graph 127 Melhorando a Vazão TCP em MANETs Simulação de Agentes com Aspectos Emocionais 139 Múltiplas conexões Bluetooth no ambiente da televisão digital interativa 145 Modelos de Confiança e Qualidade de Serviço na Web 151 Uma Ferramenta para Avaliação de Conhecimento em Meio Digital Utilizando Bluetooth e Dispositivos Móveis 157 Ferramenta de extração de características e análise do sinal de voz patológica 164 Middleware para RSSF com suporte a QoS: Uma Visão 170 Componentes da Web Semântica - Uma análise na perspectiva do desenvolvedor 176 Implementação de Controladores utilizando Microcontroladores 181 Protocolo de Controle de Concorrência para Banco de Dados em Tempo-Real 187 HN2NInt: Um Middleware para Interoperação de Sistemas Multiusuários Pervasivos 193 TV Mímica: Uma aplicação NCLua, como uma Atrativa Ferramenta de Aprendizagem 199 LuaR, Uma Ferramenta para Desenvolvimento de Aplicações Customizáveis para a TVDI 205 NCL+ uma opção à utilização de APIs externas junto com linguagem NCL 211 Compressão de Vídeo baseada no Padrão H.264/AVC Utilizando o Algoritmo Diamond Search 217 Um Mecanismo para Programação Multithreaded em Arquitetura Multicore 223 A Interoperabilidade do Padrão IEEE 1451 em Redes de Sensores sem Fio 229 Migração de um Sistema de Dimensionamento de Poços de Bombeio Mecânico para Dispositivos Móveis 235 Um roteador de baixo consumo baseado na placa BeagleBoard 241 TV-Turismo: Uma Aplicação Turísticas para TV Digital utilizando Ginga-NCL 247 Influência de corpos dáqua na qualidade do sinal de redes Wireless: um estudo prático 252 Componentes gráficos no Ginga-J: vantagens e desvantagens da API LWUIT 258

3 Índice de autores A. Silva, R.: 72 Aglaé, A.: 199 Alencar, M.: 46 Almeida, A.: 223 Almeida, E. V.: 46 Almeida, N. C.: 164 Alves Pontes, A.: 7 Araújo, M. A.: 170 Barbalho, T.: 84, 90 Barbosa, D. F.: 110 Barreto, G.: 54 Basilio, J. O.: 84 Bedregal, B.: 33 Bezerra, D.: 199 Bezerra, K. S.: 139 Burlamaqui, A. M.: 110, 145, 193, 199, 205, 211, 247, 258 Cabrita, P.: 199 Cacho, N.: 235 Campos, A.: 139 Castro, A.: 60 Castro, T.: 40 Coelho, F.: 60, 78, 187 Coelho, R. S.: 115 Costa, F.: 199, 205 Costa Filho, R. V.: 181 Costa Neto, M. A.: 33, 115 da Silva, H.: 110 Dantas, J.: 110 Dantas, K. A.: 145 Dantas, R.: 193 de Araújo, J. M.: 241 de Sá, M. P.: 1 de Souza, S.: 40 Delicato, F.: 66 Dias, R.: 193, 205 Feitosa, A.: 139 Fernandes, C.: 27 Ferreira, A.: 27 Ferreira, L. P.: 157 Florencio, N.: 247 Fonseca, I.: 27, 46 Fontes, L.: 7 Freitas, C. R.: 176 Fussiger, F.: 0 Gonçalves, L. M.: 211 Guerreiro, A. G.: 164 Henrique, D.: 205 Jacinto, K.: 121, 252 Jacinto, K.: 121, 252 Jó da Silva, J.: 181 Lago, C.: 66 Leite, J. C.: 115 Leite, L.: 211 Lima, E. P.: 96 Lima, P. B.: 21 Lopes, F. A.: 66

4 Matsumoto, P. M.: 0 Medeiros, A. L.: 247 Medeiros, E.: 90 Medeiros, M.: 110 Melo, J.: 211, 258 Melo, S.: 258 Mendes Neto, F. M.: 7, 187 Menescal, Y.: 78, 187 Monteiro, C. d.: 72, 104, 133 Morais, M.: 110 Moura, M.: 241 Nepomuceno de Souza, J.: 14 Nobre, C. A.: 229 Nobre, M.: 193 Oliveira, A.: 193 Oliveira, J. G.: 151 Oliveira, L.: 252 Oliveira, V.: 27 Padovani de Souza, K.: 14 Pereira, M.: 84, 90 Pereira, M. A.: 217 Pires, P. F.: 66 Próspero Sanchez, P.: 0 Queiroga, J.: 66 Ramalho, W.: 46 Ribeiro, C.: 151, 170, 176 Ribeiro, D.: 258 Ribeiro Neto, B.: 223 Ribeiro Neto, P. F.: 187 Rios, V.: 133 Rocha, D. F.: 127 Rocha, R. C.: 1 Rombaldo Jr, C.: 40 S. Barros, L.: 181 Sacramento, V.: 1 Santana de Oliveira, A.: 60 Santos, J.: 54 Santos, M.: 247 Schneider, C.: 193 Sena, H. T.: 193, 205 Signoretti, A.: 139 Silva, H.: 199 Silva, I.: 199 Silva, I. S.: 145 Silva, L. S.: 14 Silva, L. C.: 90 Silva, L. F.: 127 Silva, S.: 164 Silva, S.: 247 Silvestre, F.: 54 Soares, H.: 164 Sousa, M. A.: 235 Souza, A.: 115 Tullyo Campos, M.: 121 V. Barros, C.: 181 Vargas, R. R.: 33 Vasconcelos Batista, T.: 66, 235 Vieira, M.: 241

5 ConBus: Uma Arquitetura de Middleware para Provisão de Contexto em Dispositivos Móveis Marcio Pereira de Sá 1, Vagner Sacramento 1, Ricardo Rocha 1 1 Instituto de Informática Universidade Federal de Goiás (UFG) Caixa Postal Goiânia GO Brazil Abstract. Ubiquitous Computing has became a reality and this just was possible due to the popularization of mobile devices such as PDAs and smartphones. Mobile applications can be more useful if they use information about their execution environment such as location and power level of their mobile devices. However, to develop such applications is a hard task mainly due to the diversity of sensors which can interact with applications. In this work, it is proposed an middleware architecture to facilitate the development these applications. Resumo. A Computação Ubíqua tem se tornado uma realidade e isto só foi possível devido à popularização de dispositivos móveis, como PDAs e smartphones. Aplicações móveis podem ser mais úteis se utilizarem informações sobre seu ambiente de execução, como a localização e o nível de energia de seus dispositivos móveis. Entretanto, devenvolver tais aplicações é uma tarefa difícil principalmente devido à diversidade de sensores que podem interagir com as aplicações. Neste trabalho, é proposto uma arquitetura de middleware para facilitar o desenvolvimento de tais aplicações. 1. Introdução A computação ubíqua/pervasiva, idealizada por Mark Weiser [Weiser 1991], na década de 80, está se tornando a cada dia uma realidade, e muito disso se deve à grande evolução da computação móvel, devido, principalmente, à popularização dos dispositivos móveis, tais como PDAs e smartphones, que possibilitam desenvolver aplicações ubíquas inovadoras. Na maioria das vezes, pode ser desejável que essas aplicações tenham a capacidade de perceber e reagir a mudanças do ambiente no qual estão inseridas. Por exemplo, mudanças de localização, alterações no nível de energia dos dispositivos móveis, bem como, na agenda de compromissos de seus usuários, dentre outras. Todas essas informações são denominadas informações de contexto. As aplicações podem fazer uso dessas informações para adaptar seu comportamento de acordo com o contexto corrente, sem a intervenção explícita dos usuários, tornando tais aplicações mais úteis e inteligentes. De fato, o uso da sensibilidade ao contexto oferece muitas oportunidades para a criação de aplicações mais adaptadas ao ambiente móvel e ubíquo, porém há também muitos desafios para desenvolvê-las. Dentre estes desafios estão a grande diversidade de informações contextuais (localização dos usuários, luminosidade ambiente, uso de CPU e memória, qualidade da rede sem fio e muitas outras) e a abundância de tecnologias de sensoriamento, como, por exemplo, vários modelos de sensores de temperatura, cada um com uma interface de acesso própria ou ainda diferentes APIs para acesso a agendas de compromissos de usuários hospedadas na Web. 1

6 Devido a essa diversidade de informações de contexto e à abundância de tecnologias de sensoriamento, atualmente, um dos principais empecilhos para o desenvolvimento de tais aplicações é a complexidade em desenvolver novos módulos de sensoriamento de contexto ou reutilizar os existentes desenvolvidos por diferentes grupos de trabalho. Isso ocorre devido à falta de padronização das interfaces de acesso ao contexto fornecidas por cada módulo de sensoriamento e também pela falta de padronização na representação das informações contextuais coletadas por estes. Estes problemas dificultam ou, até mesmo, inviabilizam a reutilização de módulos de sensoriamento existentes, pois o desenvolvedor teria que entender a interface para acesso aos dados de contexto de cada sensor (físico ou lógico), e lidar possivelmente com diferentes representações das informações de contexto. Neste trabalho, o termo sensor é empregado com um significado mais amplo, indicando qualquer dispositivo físico (hardware) ou lógico (software) capaz de coletar alguma informação contextual relevante para melhorar a execução de aplicações, bem como facilitar a interação dessas aplicações com seus usuários. Desse modo, são considerados sensores os dispositivos que coletam dados do ambiente (temperatura, pressão, umidade, luminosidade, etc), do usuário (agenda de compromissos, preferências, pessoas co-localizadas, dentre outras) e, ainda, dados relativos ao próprio ambiente computacional (nível de bateria, uso de CPU e memória, qualidade da rede sem fio, tamanho, orientação e resolução da tela, e muitas outras.). Por outro lado, o termo módulo de sensoriamento de um determinado sensor, indica a interface de software que permite às aplicações ou a qualquer outro software obter as informações contextuais coletadas pelo sensor correspondente. Os módulos de sensoriamento são, portanto, os intermediadores entre os sensores propriamente ditos e as aplicações que utilizam seus dados. Com o propósito de lidar com tais desafios, este trabalho propõe uma arquitetura de provisão de contexto, denominada ConBus (Context Bus), que provê um middleware com serviços de coleta, processamento e disponibilização de informações contextuais para aplicações sensíveis ao contexto em dispositivos móveis, facilitando o trabalho dos desenvolvedores dessas aplicações. Este trabalho encontra-se assim organizado: na Seção 2, são apresentados alguns trabalhos correlatos à proposta deste artigo. A arquitetura ConBus é discutida em detalhes na Seção 3. Finalmente, a Seção 4 discute alguns trabalhos futuros visando à melhoria dessa arquitetura e, ainda, apresenta as considerações finais sobre o presente artigo. 2. Trabalhos Correlatos Módulos de sensoriamento são elementos comuns a qualquer arquitetura de middleware para computação sensível ao contexto. Entretanto, poucos sistemas de middleware oferecem abstrações específicas para facilitar o desenvolvimento e integração desses módulos. Esta tarefa envolve problemas como distribuição do sensor (local, remoto ou distribuído), descoberta do sensor (dinâmica ou estática), carregamento e desconexão do módulo de sensoriamento. Context Toolkit [Dey et al. 2001], CFN/Solar [Chen et al. 2004] e Contory [Riva 2006] são os exemplos mais representativos de sistemas de middleware que oferecem abstrações para tratar a integração de módulos de sensoriamento. Context Toolkit [Dey et al. 2001] propõe o conceito de Context Widget: um componente de software que implementa a abstração de acesso a um módulo de sensoriamento, responsável por prover informações contextuais sobre uma entidade particu- 2

7 lar. Context Toolkit oferece ainda abstrações que permitem implementar a composição de widgets, que representem a agregação de informações contextuais. CFN/Solar [Chen et al. 2004] provê um mecanismo distribuído de composição de sensores, formando uma rede de sensores distribuídos que agreguem informações contextuais e as distribuam eficientemente para aplicações executando em diferentes pontos de uma rede. Dois sistemas de middleware, em particular, provêem acesso eficiente de módulos de sensoriamento em dispositivos móveis: Hydrogen e Contory. Contory [Riva 2006] provê às aplicações transparência de distribuição do mecanismo de provisão de contexto, podendo o módulo de sensoriamento ser local, remoto ou ad hoc (em outro dispositivo móvel). Hydrogen [Hofer et al. 2003], por outro lado, não oferece abstrações específicas que facilitem o desenvolvimento de módulos de sensoriamento, cabendo ao desenvolvedor a integração do módulo nos mecanismos do middleware. A preocupação fundamental desses e outros sistemas é facilitar o desenvolvimento das aplicações e o acesso aos módulos de sensoriamento. Tipicamente, eles levam em consideração que tais módulos já estão pré-carregados ou que outro desenvolvedor já se encarregou de prover os módulos e adequá-los ao middleware. O desenvolvimento e a implantação de módulos de sensoriamento requerem, entretanto, mecanismos e abstrações específicas que facilitem a sua integração com o middleware de computação sensível ao contexto e o seu posterior reconhecimento pelas aplicações. A complexidade no desenvolvimento desses módulos é ainda maior quando eles provêem contextos lógicos, resultado da composição de outros módulos de sensoriamento. Além disso, uma solução de middleware precisa ainda ser adequada às limitações dos dispositivos móveis no qual as aplicações estarão executando. 3. Arquitetura ConBus O ConBus propõe uma arquitetura completa para o desenvolvimento de aplicações sensíveis ao contexto, desde a coleta, processamento até a disponibilização de contexto às aplicações. Conforme ilustrado na Figura 1, esta arquitetura é constituída por três camadas: Camada de Sensores, Middleware ConBus e Camada de Aplicação. Application Layer Application 1 Application 2... Application N ConBus Middleware Communication Controller Context Interpreter X Context Manager Context Interpreter Y Framework OSGi... ConUnit 1 ConUnit 2 ConUnit M Sensor Layer Wireless Network Sensor Web Personal Schedule... GPS Receiver Figure 1. A arquitetura ConBus - Modelo Geral Camada de Sensores A Camada de Sensores (Sensor Layer) ilustrada na Figura 1 é constituída por todas as fontes de contexto (sensores) que fornecem informações ao middleware ConBus. Cada 3

8 sensor é conectado ao Middleware ConBus através de um módulo de acoplamento e padronização denominado ConUnit, especialmente desenvolvido para cada tipo de sensor. O uso de ConUnits permite aos programadores desenvolver novos módulos de sensoriamento e, também, reutilizar módulos já desenvolvidos, a Subseção 3.4 detalha melhor esse componente Middleware ConBus O Middleware ConBus é a camada intermediária que gerencia todas as informações contextuais coletadas pelas fontes de contexto da Camada de Sensores e que, posteriormente, são fornecidas a todas as aplicações sensíveis ao contexto que fazem uso das mesmas. Esta camada é composta pelos seguintes componentes: O Gerenciador de Contexto (Context Manager), responsável pelo controle de todos os recursos oferecidos pelo Middleware, ou seja, o controle de todas as informações coletadas pelos sensores acoplados ao ConBus, bem como a responsabilidade de disponibilizá-las adequadamente às aplicações sensíveis ao contexto. Além do Gerenciador de Contexto, há também os ConUnits (Unidades de Contexto) que interligam, de forma padronizada, as fontes de contexto ao ConBus (veja a Subseção 3.4); outros componentes importantes são os Interpretadores de Contexto (Context Interpreters), que realizam tarefas importantes para a arquitetura, inferindo novas informações de contexto a partir de dados de contexto de mais baixo nível. Por exemplo, pode-se desenvolver um interpretador específico que, a partir das coordenadas geográficas (latitude e longitude) coletadas por um receptor GPS, pode inferir se um determinado usuário ou dispositivo encontra-se ou não em uma dada sala de um edifício. Além dos componentes citados anteriormente, há ainda o Framework OSGi [Alliance. 2009] cuja função é permitir o acoplamento de novos ConUnits e Interpretadores de Contexto ao Context Manager. O OSGi permite ainda que ConUnits ou Interpretadores de Contexto sejam instalados, desistalados, iniciados, desligados, e até, atualizados dinamicamente sem a necessidade de reiniciar a execucão de todo o Middleware ConBus. Isto permite que o próprio ConBus seja sensível ao contexto e, sempre que necessário, possa instalar ou desistalar, iniciar ou desligar ConUnits ou Interpretadores de Contexto, visando poupar recursos computacionais, como, baixo nível de energia, alto uso de CPU e memória, etc.). Além disso, pode-se realizar, remotamente e de forma automatizada, atualizações em ConUnits ou Interpretadores de Contexto Camada de Aplicação Todas as aplicações sensíveis ao contexto que utilizam as informações contextuais fornecidas pelo middleware ConBus fazem parte da Camada de Aplicação (Application Layer). Para usufruir das informações de contexto providas pelo ConBus, uma aplicação necessita apenas conhecer a URL (neste caso, da instância do middleware ConBus que está sendo executada no dispositivo móvel correspondente e, em seguida, invocar os métodos desejados com os devidos parâmetros oferecidos pela interface de acesso ao contexto, usando, para isso, interfaces síncronas e assíncronas providas pela API das Aplicações (Application API). Esta API define um Web Service local baseado em REST [Portal 2009], através do qual as aplicações podem enviar requisições para a instância do ConBus que se encontra em execução. A comunicação síncrona ocorre da seguinte forma: como dito anteriormente, o ConBus exporta um Web Service local (i.e., associado ao endereço localhost) em uma 4

9 porta pré-definida (a padrão é 8585) para o qual as aplicações podem enviar requisições utilizando o comando GET e informar, como parâmetros, o nome da variável de contexto na qual está interessada (LOCATION, TEMPERATURE, ENERGYLEVEL, etc.) e a entidade a qual essa variável está relacionada (ex. CARLOS14352, SALA113, NokiaE , etc.). Como resposta, recebem a informação de contexto correspondente, representada em um formato XML predefinido.a comunicação assíncrona acontece de forma semelhante, porém, deve-se enviar requisições utilizando-se o comando POST, seguido pela palavra Assinc e informando, em seguida, o nome da variável de contexto desejada juntamente com uma expressão que contém uma condição ou restrição e, ainda, o nome da entidade a qual essa variável está relacionada (por exemplo, ENERGYLEVEL 25%, iphone2132) para que a instância do ConBus em execução envie as informações contextuais das quais a aplicação está interessada. Este serviço assíncrono local provê muitos benefícios para as aplicações e dispositivos móveis, pois desacopla a aplicação do mecanismo de coleta/provisão de contexto e provê economia de energia dado que a aplicação não precisa fazer polling para consultar o estado das variáveis contextuais para, então, disparar uma reação ou adaptação. Nota-se que, apesar da instância do ConBus e as aplicações estarem executando localmente no mesmo dispositivo móvel, a comunicação entre eles ocorrerá via um Web Service local; isto foi proposto para tornar o uso do Con- Bus independente da linguagem na qual a aplicação foi desenvolvida Arquitetura do ConUnit Pelo fato de ser o módulo responsável pela interação com os sensores (fontes de contexto), os ConUnits, cuja arquitetura é ilustrada na Figura 2, são o elo entre estas fontes de contexto e o ConBus. Um ConUnit é constituído por duas partes principais: O Sensor Communicator é a parte dependente de sensor e, por isso, o programador do ConUnit correspondente deverá implementar uma interface Java denominada Interface de Conversão de Dados de Contexto (Context Data Conversion Interface); é através da implementação dessa interface que será realizada a conversão dos dados específicos de cada sensor para uma forma padronizada, de acordo com o modelo de contexto do ConBus. O ConBus Communicator é a parte independente de sensor, sua função pricipal é acoplar a Sensor Communicator ao restante do middleware. ConBus Communicator Sensor Communicator Synchronous Controller ConUnit Manager Asynchronous Controller Context Data Conversion Interface ConUnit Sensor Implementation Figure 2. ConUnit - Estrutura Interna. 4. Trabalhos Futuros e Considerações Finais Para facilitar o desenvolvimento de aplicações móveis sensíveis ao contexto, foi proposto, neste trabalho, a arquitetura ConBus. Esta oferece uma camada de abstração para o desenvolvimento de aplicações móveis sensíveis ao contexto que trata de pontos fundamentais que podem representar um grande empecilho para o desenvolvimento de aplicações do 5

10 gênero, tais como: i) criação de módulos de sensoriamento padronizados; ii) reutilização de módulos de sensoriamento desenvolvidos por terceiros e iii) representação dos dados de contexto independentemente do sensor utilizado. Como já há uma implementação do middleware ConBus desenvolvida com algumas aplicações de teste, o próximo passo será a realização de avaliações qualitativas e quantitativas relacionadas à arquitetura e ao desenvolvimento de aplicações sensíveis ao contexto que utilizam seus serviços, permitindo analisar mais apropriadamente seus benefícios e carências. Pretende-se ainda integrar o ConBus, como uma possível fonte de contexto, a outras arquiteturas de provisão de contexto de uso mais geral, tais como MoCA [Sacramento et al. 2004], ECORA [Padovitz et al. 2008], SOCAM [Gu et al. 2005], dentre outras. References Alliance., O. (2009). Osgi - the dynamic module system for java. disponível em: pesquisado em 11/10/2009. Chen, G., Li, M., and Kotz, D. (2004). Design and implementation of a large-scale context fusion network. In Mobile and Ubiquitous Systems: Networking and Services, MOBIQUITOUS The First Annual International Conference on, pages Dey, A., Salber, D., and Abowd, G. (2001). A conceptual framework and a toolkit for supporting the rapid prototyping of context-aware applications. Human-Computer Interaction Journal (HCI), 16(2-4): Gu, T., Pung, H. K., and Zhang, D. Q. (2005). A service-oriented middleware for building context-aware services. Journal of Network and Computer Applications, 28(1):1 18. Hofer, T., Schwinger, W., Pichler, M., Leonhartsberger, G., Altmann, J., and Retschitzegger, W. (2003). Context-awareness on mobile devices - the hydrogen approach. In System Sciences, Proceedings of the 36th Annual Hawaii International Conference on. Padovitz, A., Loke, S. W., and Zaslavsky, A. (2008). The ecora framework: A hybrid architecture for context-oriented pervasive computing. Pervasive Mob. Comput., 4(2): Portal, M. C. (2009). Rest. disponível em: pesquisado em 11/10/2009. Riva, O. (2006). Contory: A middleware for the provisioning of context information on smart phones. In ACM/IFIP/USENIX 7th International Middleware Conference (Middleware 06), Melbourne (Australia). Sacramento, V., Endler, M., Rubinsztejn, H. K., Lima, L. S., Goncalves, K., Nascimento, F. N., and Bueno, G. A. (2004). Moca: A middleware for developing collaborative applications for mobile users. IEEE Distributed Systems Online, 5(10):2. Weiser, M. (1991). The computer for the twenty-first century. Scientific American, pages

11 Uma Ontologia sobre Aprendizagem Colaborativa Apoiada por Computador Laysa Mabel de Oliveira Fontes 1, Francisco Milton Mendes Neto 1,2, Alexandre Ádames Alves Pontes 2 1 Laboratório de Engenharia de Software - LES Bacharelado em Ciência da Computação 2 Mestrado Acadêmico em Ciência da Computação - MCC Departamento de Ciências Exatas e Naturais (DCEN) Universidade Federal Rural do Semi-Árido (UFERSA) BR Km 47 Bairro Pres. Costa e Silva CEP Mossoró - RN Abstract. The absence of mechanisms that enable the standardization of concepts related to CSCL (Computer-Supported Collaborative Learning) makes much harder the common and shared comprehension about this domain. In an attempt of to organize the concepts related to this domain in a structured and formalized way, while also trying to facilitate the access to knowledge about this domain, we propose an ontology that fulfills requirements of abstraction and significance of the main related concepts. Resumo. A ausência mecanismos que tornem possível a padronização ou uniformização dos conceitos relacionados à Aprendizagem Colaborativa Apoiada por Computador dificulta a compreensão comum e compartilhada sobre este domínio. Na tentativa de organizar conceitos relacionados com este domínio de modo estruturado e formalizado e buscando facilitar o acesso rápido ao conhecimento sobre o presente domínio, foi proposta uma ontologia que preenche requisitos de abstração e significação dos principais conceitos relacionados. 1. Introdução O suporte informatizado à aprendizagem colaborativa é chamado de Aprendizagem Colaborativa Apoiada por Computador, do inglês Computer-Supported Collaborative Learning - CSCL) [Dimitracopoulou 2005]. Com a popularização dos cursos a distância e o crescimento das redes e internet, tornou-se comum o uso de computadores em rede para prover a aprendizagem colaborativa entre estudantes geograficamente distribuídos. Os sistemas que implementam a aprendizagem colaborativa desta forma precisam incluir mecanismos de cooperação e comunicação para que o processo de aprendizagem possa ser efetuado com qualidade, além disso, tais sistemas devem possuir mecanismos para criação de grupos e formas de acompanhamento pelos facilitadores (professores). No entanto, a ausência de padronização ou uniformização dos conceitos relacionados à Aprendizagem Colaborativa Apoiada por Computador dificulta a compreensão comum e compartilhada sobre este domínio. Não existe um mecanismo que torne possível a coleta em tempo hábil da informação realmente necessária para apoiar a tomada de decisão durante a resolução de problemas, assim como não existe um mecanismo que torne possível o entendimento comum e compartilhado sobre este domínio. Nesse sentido, a 7

12 representação de conhecimento através de ontologias constitui-se numa alternativa para resolver os problemas associados à falta de padronização e semântica referentes à Aprendizagem Colaborativa Apoiada por Computador. A partir destas considerações, objetivando representar o domínio Aprendizagem Colaborativa Apoiada por Computador de modo estruturado e formalizado e buscando facilitar o acesso rápido a informações sobre o presente domínio, foi proposta uma ontologia que preenche requisitos de abstração e significação dos conceitos. A utilização de ontologia na modelagem de um domínio permite compor uma estrutura de conceitos que define as regras que regulam a combinação e relação entre termos para viabilizar o entendimento comum e compartilhado do domínio de conhecimento, de forma que o mesmo possa ser compreendido e explorado tanto por pessoas como por computadores. Este artigo está estruturado da seguinte forma: a Seção 2 discute os trabalhos relacionados; na Seção 3, descreve-se a ontologia do domínio Aprendizagem Colaborativa Apoiada por Computador. Finalmente, nossas considerações finais são apresentadas na Seção Trabalhos Relacionados As ontologias são usadas para diversos propósitos em ambientes de aprendizagem, contudo uma grande aplicação desta tecnologia é na área de personalização do ambiente de ensino-aprendizagem. Isto é feito levando-se em consideração características únicas de cada estudante. Este comportamento do ambiente é desejável, pois ele pode adaptar-se aos estilos de aprendizado de cada estudante. Em [Gascuena et al. 2006], é elaborada uma ontologia de domínio para personalização de materiais em relação ao estilo de aprendizagem do estudante. Em [Min et al. 2008], é proposto um framework para adaptação em ambientes de aprendizagem. Neste trabalho, dois modelos ontológicos são construídos: um modelo de conhecimento e um modelo do aprendiz, sendo que no modelo do aprendiz é informado o objetivo do estudante e no modelo de conhecimento são gravadas informações relacionadas a este objetivo. Ainda no modelo do estudante, são armazenados estilos de aprendizado, atividades de aprendizado e avaliações. Portanto, com base no modelo do estudante construído através de uma ontologia, o sistema irá se adaptar de forma a cumprir os requisitos do estudante. Em [Gomes et al. 2006], é mostrado um modelo usado para personalização do ambiente de acordo com o monitoramento do estudante. Inicialmente o estudante interage com o sistema através de uma interface que, posteriormente, será adaptada de acordo com suas caractéristicas particulares. Em [Gladun et al. 2009], é mostrado o uso de ontologias de domínio para controlar e avaliar o estudante concernente à aquisição do conhecimento. Assim, uma ontologia de domínio é construída pelo próprio estudante e esta é comparada com outra de referência. Através dos erros encontrados, é possível avaliar o nível de aquisição do conhecimento pelo estudante. Em [Bittencourt et al. 2006], é descrita uma ontologia para construção de ambientes interativos de aprendizagem. São modelados, através de uma ontologia, diversos conceitos de um ambiente de aprendizagem, tais como, modelo do estudante, o qual representa o estudante que será ensinado; modelo pedagógico, que se refere às estratégias para aprendizagem; modelo de colaboração, que define a forma de colaboração no ambiente; e modelo de domínio, que representa as informações que serão relevantes ao ensino, ou seja, referentes ao que será ensinado. 8

13 Com exceção do trabalho de [Bittencourt et al. 2006], todos os trabalhos apresentados nesta seção diferem da proposta apresentada neste artigo por usarem ontologias que representam apenas um aspecto particular do domínio (ex. perfil do estudante) para resolver um problema específico, como, por exemplo, personalização do ambiente de ensinoaprendizagem e de materiais de estudo (conteúdos) de acordo com as características dos estudantes, avaliação dos estudantes em relação à aquisição de conhecimentos, e assim por diante. Já a ontologia proposta em [Bittencourt et al. 2006] difere da ontologia apresentada neste trabalho por modelar relacionamentos entre conceitos pertinentes a todo e qualquer ambiente interativo de aprendizagem e não conceitos relativos à modalidade de ensino-aprendizagem Aprendizagem Colaborativa Apoiada por Computador, como é o caso do presente trabalho. 3. Ontologia da Aprendizagem Colaborativa Apoiada por Computador Inicialmente foi feita uma análise do domínio Aprendizagem Colaborativa Apoiada por Computador, onde foi realizado um levantamento, com base na literatura, dos termos importantes e relevantes para o domínio. Feito isso, foi possível representar formalmente a ontologia de maneira específica, possibilitando o processamento e a abrangência do conhecimento não só por humanos, mais também por máquinas. Isso foi possível através do uso de uma linguagem específica para a criação de ontologias e de uma ferramenta que permite sistematizar e integrar as especificações definidas à linguagem utilizada Descrição das Tecnologias de Desenvolvimento No desenvolvimento da ontologia proposta neste trabalho, foi utilizada a linguagem OWL [Dean et al. 2004]. Esta linguagem de descrição de ontologia foi escolhida por ela apresentar características que tornam a ontologia mais robusta. A linguagem OWL apresenta também recursos adicionais não suportados por outras linguagens, como, por exemplo, sub-linguagens incrementais projetadas para serem usadas por diferentes comunidades de implementadores e usuários. A ferramenta selecionada para a modelagem da ontologia foi a Protégé [Knublauch et al. 2004], pois essa ferramenta permite sistematizar e integrar as especificações definidas à linguagem utilizada, além de oferecer recursos interessantes e necessários para o presente trabalho Estruturação da Ontologia As ontologias não apresentam sempre a mesma estrutura, mas existem características e componentes básicos comuns presentes em grande parte delas [Brólio et al. 2006]. A ontologia proposta neste trabalho possui a seguinte estrutura: Classes e/ou Subclasses, Propriedades e Axiomas. Classes e/ou subclasses: Abrange um conjunto de classes e uma hierarquia entre essas classes, ou seja, uma taxonomia. Podemos citar, como exemplo de taxonomia, a seguinte propriedade da ontologia proposta: a classe Facilitador é uma subclasse da classe Usuario. Propriedades: Na ontologia proposta neste trabalho, foram definidos dois tipos de propriedades: objectproperty e Datatype. Propriedades do tipo objectproperty têm o papel de qualificar ou relacionar classes. Já as propriedades do tipo Datatype constituem campos que podem ser instanciados. Axiomas: Axiomas modelam sentenças que são sempre verdadeiras. A criação de axiomas é feita através de definições formais. 9

14 3.3. Principais Classes Identificadas Fazendo uso da análise do domínio Aprendizagem Colaborativa Apoiada por Computador, foram definidas 6 (seis) classes (Ambientes de Suporte, Ferramentas Tecnológicas, Modalidades de Ensino, Modelos Educacionais, Tipos de Interação e Usuários), com o intuito de representar os conceitos gerais. A partir dos conceitos gerais foram definidas e agrupadas suas especificidades, ou seja, suas 94 (noventa e quatro) subclasses. Por exemplo, para representar os termos mais específicos da classe Ambientes de Suporte foram definidas 11 (onze) subclasses. Do mesmo modo, para as classes Ferramentas Tecnológicas, Modalidades de Ensino, Modelos Educacionais, Tipos de Interação e Usuários foram definidas 35, 32, 7, 4 e 5 subclasses, respectivamente. Dentre todos os conceitos especificados, para efeitos didáticos e devido ao espaço limitado neste artigo, optamos em dar uma ênfase maior a classe Facilitador, por essa ser uma classe que possui características importantes na ontologia. A Figura 1 ilustra o desenvolvimento da classe Facilitador na ferramenta Protégé. Figura 1. Representação da classe Facilitador na ferramenta Protégé Na hierarquia apresentada na figura, observamos que toda classe é parte de uma classe principal, denominada pela ferramenta Protégé como Thing. Uma subclasse herda as propriedades de sua superclasse determinando, por exemplo, que a classe Facilitador herda todas as propriedades (enderecoeletronico, matricula, nomedousuario e senha) da superclasse Usuário. Além disso, a classe Facilitador apresenta características próprias, como areadeatuacao, e propriedades, que determinam funções exercidas pelo Facilitador. Como exemplo, podemos citar as propriedades orienta e publicaas. Mais detalhes sobre as propriedades que compõem a ontologia serão vistas na próxima subseção. O campo Equivalent Classes, mostrado na Figura 1, é usado para definir formalmente equivalência entre classes. Na ontologia proposta, foi definida a equivalência entre as classes Facilitador e Professor, consequentemente as duas classes possuem as mesmas características. Para especificação das atividade exercidas pelo Facilitador em um ambiente de aprendizagem colaborativa apoiada por computador, foram construídos axiomas em OWL. A Figura 2, apresenta um trecho de código em OWL em que foi feito uso da propriedade mincardinality, oferecida pela linguagem, para construirmos o axioma que 10

15 especifica que Facilitador orienta zero ou mais trabalhos. Como os axiomas são definidos através de propriedades, criamos um axioma para a propriedade orienta. Observando a Figura 1, vimos que foi possível definir a seguinte restrinção: Facilitador pode orientar no mínimo 0 Trabalho. Essa restrição se fez necessária porque em determinados momentos um Facilitador pode não estar alocado a trabalho algum. Figura 2. Definição de um axioma em OWL Por último, na Figura 1, apresentamos o campo Disjoint Classes, usado para definir as classes que estão em um mesmo nível hierárquico de uma determinada classe. Na Figura 1, temos todas as classes que estão no mesmo nível da classe Facilitador. A Figura 3 ilustra o código OWL referente a propriedade Disjoint. Figura 3. Representação das classes Disjoints à classe Facilitador em OWL Similarmente ao procedimento apresentado anteriormente, foram desenvolvidas todas as outras classes que compõem o domínio Especificação das Propriedades das Classes As propriedades de cada classe da ontologia foram especificadas à medida em que as classes foram sendo definidas ou reutilizadas. A ontologia resultante possui 273 propriedades do tipo objectproperty e 25 propriedades do tipo Datatype. Para representar uma propriedade do tipo objectproperty ou Datatype, é necessário a definição do domínio da propriedade (domain) e da classe a qual se aplica a propriedade (range). Uma propriedade deve ser declarada como objectproperty quando essa tem o papel de qualificar ou relacionar classes. Podemos citar, como exemplo do tipo objectproperty, a propriedade orienta, que tem como domínio a classe Facilitador e como range a classe Trabalho. Atribuímos também o valor Inverse Properties às propriedades orienta e é orientado por, implicando que orienta é uma propriedade inversa da propriedade é orientado por e vice-versa. O Trecho de código OWL referente a propriedade orienta é mostrado na Figura 4. Propriedades do tipo Datatype constituem os atributos de uma classe que podem ser instanciados através, por exemplo, do preenchimento de campos em um formulário de entrada de dados. Neste tipo de propriedade, é necessário definir o domínio a qual ela 11

16 Figura 4. Representação da propriedade orienta do tipo objectproperty em OWL pertence e a range que, diferentemente do tipo objectproperty, não mais será uma classe, mas um tipo de dado (ex. date, string, boolean, int, double, entre outros). Podemos citar, como exemplo de propriedade do tipo Datatype, a propriedade nome do usuário, que tem como domínio a classe Usuário e como range o tipo string. O desenvolvimento de todas as outras propriedades que compõem a ontologia seguiram o mesmo procedimento apresentado anteriormente Principais Vantagens da Ontologia Proposta O uso da ontologia proposta torna possível, entre outras coisas, definir uma infra-estrutura para integrar sistemas inteligentes ao nível conceitual do domínio [Manhães 2006]. A ontologia sobre o domínio Aprendizagem Colaborativa Apoiada por Computador proposta neste trabalho apresenta as seguintes vantagens: Colaboração: possibilita o compartilhamento do conhecimento entre os membros interdisciplinares de uma equipe. Esta ontologia pode ser aplicada, por exemplo, no processamento de linguagem natural, onde a ontologia pode auxiliar a elucidação de ambigüidades de compreensão existentes no domínio. Interoperação: facilita a integração da informação, especialmente em aplicações distribuídas. A ontologia proposta oferece uma padronização do conhecimento de forma que possibilita a interoperação de aplicações distribuídas. Informação: pode ser usada como fonte de consulta e de referência do domínio. Esta ontologia pode ser aplicada, por exempolo, na Gestão do Conhecimento [Bjornson and Dingsoyr 2008], já que ela fornece a estrutura básica sobre a qual se constroem bases de conhecimentos. Modelagem: por ser representada por blocos estruturados, pode ser utilizada na modelagem de conhecimento de sistemas especialistas. Reuso: permite que domínios de conhecimento sejam reutilizados. 4. Conclusão A fim de prover um maior esclarecimento sobre o domínio da Aprendizagem Colaborativa Apoiada por Computador, não encontrado nos trabalhos pesquisados na literatura, é proposta neste artigo uma ontologia que modela os relacionamentos entre os conceitos deste domínio. A ontologia proposta tem como diferencial sua abrangência, uma vez que foram contemplados os principais (1) termos relevantes ao domínio, (2) tipos de ambientes computacionais de aprendizagem, (3) modelos educacionais que podem ser aplicados, (4) tipos de interações presentes, (5) modalidades de ensino que podem ser utilizadas em cada ambiente computacional, entre outros conceitos. A ontologia proposta também apresenta o detalhamento das principais ferramentas tecnológicas presentes nos principais ambientes de apoio, mostrando suas finalidades e por quem podem ser utilizadas. Finalmente, a ontologia proposta nesse trabalho provê informação semântica sobre restrições, conceitos e relacionamentos entre entidades do domínio Aprendizagem Colaborativa Apoiada por Computador, servindo como uma ferramenta de consulta de conhecimentos sobre este domínio, que poderá ser utilizada em diferentes contextos. 12

17 Referências Bittencourt, I., Bezerra, C., Nunes, C., Costa, E., de Oliveira, R., Tadeu, M., and da Silva, A. (2006). Ontologia para construção de ambientes interativos de aprendizagem. XVII Simpósio Brasileiro de Informática na Educação, SBIE, Brasília, pages Bjornson, F. O. and Dingsoyr, T. (2008). Knowledge management in software engineering: A systematic review of studied concepts, findings and research methods used. Inf. Softw. Technol., 50(11): Brólio, M., Omar, N., Frango, I., and Pimentel, E. (2006). Modelagem de um Ambiente de Apoio à Avaliação Continuada Construído sob Ontologia. Nuevas ideas en Informática Educativa, 2: Dean, M., Schreiber, G., Bechhofer, S., Van Harmelen, F., Hendler, J., Horrocks, I., McGuinness, D., Patel-Schneider, P., and Stein, L. (2004). OWL web ontology language reference. W3C recommendation, 10. Dimitracopoulou, A. (2005). Designing collaborative learning systems: current trends & future research agenda. In Proceedings of th 2005 conference on Computer support for collaborative learning: learning 2005: the next 10 years!, pages International Society of the Learning Sciences. Gascuena, J., Fernandez-Caballero, A., and Gonzalez, P. (2006). Domain ontology for personalized e-learning in educational systems. Advanced Learning Technologies, Sixth International Conference on, pages Gladun, A., Rogushina, J., Garcı a Sanchez, F., Martínez-Béjar, R., and Fernández-Breis, J. (2009). An application of intelligent techniques and semantic web technologies in e-learning environments. Expert Systems With Applications, 36(2P1): Gomes, P., Antunes, B., Rodrigues, L., Santos, A., Barbeira, J., and Carvalho, R. (2006). Using Ontologies for elearning Personalization. In 3rd ELearning Conference-Computer Science Education, Coimbra, Portugal. Knublauch, H., Fergerson, R., Noy, N., and Musen, M. (2004). The protege owl plugin: An open development environment for semantic web applications. Lecture Notes in Computer Science, pages Manhães, Alfredo Luiz Pessanha, S. N. e. F. O. L. M. (2006). Ontologias aplicadas ao desenvolvimento de sigs: Estudo de caso sobre zoneamento municipal. Congresso Brasileiro de Cadastro Técnico Multifinalitário UFSC Florianópolis. Min, W., Wei, C., and Lei, C. (2008). Research of ontology-based adaptive learning system. Computational Intelligence and Design, ISCID 08. International Symposium on, 2:

18 Utilização do ESB em sistema de monitoramento de ovinos e bovinos confinados: uma abordagem didática Juciara Nepomuceno de Souza, Kleber Padovani de Souza, Leonardo Souza Silva 1 Universidade Católica Dom Bosco Av. Tamandaré, 6000, Jardim Seminário Campo Grande, MS {padovani e Resumo. O agronegócio é um setor que vem avançando significativamente no que se refere à de tecnologia da informação. Esse fato deve-se, principalmente, a necessidade do setor em acompanhar o intenso processo de globalização. Nesse contexto, os sistemas de informação tomam cada vez mais espaço na rotina desse setor e a exigência por flexibilidade em suas funcionalidades tornou-se evidente. Neste trabalho é proposto que se realize a modelagem de um sistema voltado para o confinamento de ovinos e bovinos, atividade bem difundida nesse setor e na qual os sistemas de informação possuem grande valia ao automatizar determinados processos. Além disso, pretende-se tornar o fluxo de informações mais ágil e seguro, utilizando o ESB. Com a aplicação desses conceitos, anseia-se modelar um sistema que esteja apto a acompanhar de forma menos custosa e mais eficiente as constantes mudanças provenientes do crescimento econômico. 1. Introdução Tomando como referência a acirrada competição corporativa, proveniente do intenso processo de globalização sofrido nos últimos anos, é válido ressaltar que a demanda por sistemas de informações flexíveis está em visível ascensão[channabasavaiah et al. 2004]. Dessa forma, na atual conjuntura, restringir o fluxo de informações a qualquer tecnologia significa retrogradar de maneira considerável os processos empresariais[cunha et al. 2007]. Haja vista o intenso processo de informatização, diversos setores da economia vêm crescendo devido à utilização desses sistemas de informação no auxilio às tomadas de decisão. No que diz respeito ao agronegócio, existe um interesse ainda maior por ser um setor em ascensão quando se fala de tecnologia da informação. Uma prática bastante difundida nesse setor é a de confinamento de rebanhos, que consiste em realizar o manejo de animais, de maneira que se obtenha o máximo de ganho. Para que seja possível uma avaliação consistente do processo, é necessário que haja um monitoramento rígido dos rebanhos, além do registro dos dados obtidos periodicamente. Nesse caso, os tipos de animais podem diferir, todavia, existem semelhanças entre os tipos de informações obtidas. Ao combinar sistemas de informação a esse cenário, a SOA (Service Oriented Architeture), como uma abordagem organizacional, toma espaço ao propor um novo conceito à visão estrutural tradicional de sistemas, em que o forte acoplamento é uma característica marcante. Dessa forma, surge a possibilidade de contribuir para a melhoria da 14

19 performance no desenvolvimento empresarial, proporcionando maior flexibilidade entre os processos[lira 2008]. SOA é uma aborgem referente à estrutura dos sistemas corporativos, caracterizada pela utilização de serviços que representam as devidas funcionalidades. O objetivo da utilização dessa arquitetura é possibilitar maior dinamização aos sistemas, independente de linguagem ou plataforma, fazendo com que haja interoperabilidade entre quaisquer aplicações. Essa abordagem também faz uso de conceitos presentes em outras tecnologias que condizem com seus princípios estruturais, um exemplo é o ESB[Grossi 2005]. O ESB (Enterprise Service Bus) é uma das infraestruturas utilizadas na aplicação dessa arquitetura, um barramento de grande valia nesse contexto, pois permite a comunicação entre as aplicações sem que a distinção entre as tecnologias empregadas seja um impedimento. Dessa maneira, esse barramento provê a interoperabilidade necessária para que as estruturas organizacionais que o utilizam mantenham um bom desempenho em relação às arquiteturas tradicionais[martins 2005]. A partir desses aspectos introdutórios, com a finalidade de auxiliar no processo de monitoramento de animais em confinamento, este trabalho propõe fazer uso de conceitos da arquitetura SOA, aplicando a infraestrutura de integração ESB. Dessa maneira, pretende-se avaliar as consequências obtidas através da utilização dessa estrutura, bem como dispor o processo de desenvolvimento para fins didáticos. 2. Arquitetura Orientada a Serviços - SOA A SOA (Service Oriented Achitecture) surgiu da busca por sistemas dinâmicos capazes de interagir com as funcionalidades de outras aplicações, reutilizando componentes já implementados, o que possibilita a redução de tempo e custo[machado 2004]. Os objetivos dessa abordagem são similares a outras arquiteturas, contudo, o ponto crucial que difere esse modelo dos outros é a utilização do serviço como unidade básica de funcionamento[pardal 2006]. Segundo OASIS[OASIS 2006], um serviço é a forma de permitir o acesso a uma ou mais funcionalidades, obedecendo às especificações contidas na descrição do serviço. Além da facilidade em termos de integração, é possível citar algumas vantagens do uso dessa arquitetura, como a fácil adaptabilidade das aplicações às mudanças evolutivas e a rapidez e praticidade ao criar novos processos a partir de serviços existentes [Grossi 2005]. Sendo assim, devido ao baixo acoplamento, ou seja, a maior independência dos serviços em relação às tecnologias utilizadas, é possível desenvolver uma aplicação dinâmica e flexível. Nesse cenário, a utilização de infraestruturas capazes de proporcionar a dinamização requerida é de suma importância, uma vez que na prática é preciso utilizar ferramentas que se enquadrem a uma arquitetura orientada a serviços, para um funcionamento satisfatório. Nesse ponto, entra a aplicação do ESB que, resumidamente, trata-se de um mecanismo que proporciona de forma segura a integração de serviços[garcia et al. 2008] ESB - Enterprise Service Bus O ESB é tratado como um barramento que provê uma camada de abstração, a qual possibilita o fluxo de informações entre aplicações, independente de tecnologia. Esse bar- 15

20 ramento proporciona a ligação entre o provimento e consumo de serviços. Também é responsável pelo registro e publicação de serviços, conversão de dados e protocolos, segurança no roteamento de dados, entre outros[garcia et al. 2008, Josuttis 2007]. Segundo Justtis [Josuttis 2007], uma vantagem de manter um mediador que realiza o redirecionamento entre o fornecedor e consumidor de serviços é que, caso ocorra uma falha na comunicação, o processo não será perdido, já que essa camada intermediária tem a função de invocar um serviço que seja adequado conforme a requisição. Ou seja, como vários sistemas podem prover um determinado serviço, caso um deles, falhe o ESB encaminhará o solicitante a outro sistema. Esse processo pode ser ilustrado pela Figura 1. Figura 1. Esquema de funcionamento do ESB Dessa forma, ao combinar um sistema baseado em serviços à utilização do ESB para gerenciar o tráfego de serviços, ampliam-se as possibilidades para que sejam agregadas a esse sistema novas funcionalidade ou que as existentes possam ser alteradas conforme a necessidade, sem maiores alterações no restante da aplicação. 3. Estudo de Caso O setor do agronegócio vem passando por um processo de constante crescimento. Devido a essa ampliação, a utilização de mecanismos que assegurem a confiabilidade dos dados tem suma importância. Por esse motivo, os sistemas de informação vêm tomando cada vez mais espaço no cotidiano de diversas atividades desse setor econômico. É importante ressaltar que certamente, a partir da ascenção desse setor, os sistemas de informação direcionados ao agronegócio, independetemente da atividade, passaram por alterações em suas funcionalidades e até mesmo adição de outras. Desse modo, quando se trata de uma aplicação tradicional, as modificações geralmente são custosas e demoradas. A fim de solucionar esse problema e facilitar o manuseio das funcionalidades, é possível que uma estrutura baseada a serviços seja aplicada. Neste estudo de caso, a atividade abordada é a de monitoramento de ovinos e bovinos confinados. Para que a execução dessa atividade seja realizada de forma satisfatória, é necessário que os dados sejam registrados de forma confiável. Por esse motivo, a utilização de um sistema de informação é importante, pois pode auxiliar na confiabilidade do fluxo de informações desde a entrada dos dados até o seu registro em banco de dados. Após a observação da atividade de confinamento de rebanhos, em particular ovinos e bovinos, foi possível perceber semelhanças em várias rotinas. Essa percepção foi 16

21 alcançada após o levantamento de requisitos tanto para o monitoramento de ovinos quanto ao de bovinos. Mesmo tratando-se de dois sistemas distintos para o gerenciamento de atividades, as funcionalidades mostram-se bem semelhantes. Pode-se citar, por exemplo, os cadastros de confinamentos e animais e os relatórios analíticos, como o de consumo alimentar em determinado período. Com base nos conceitos estudados, é válido dizer que as semelhanças entre as funcionalidades possibilitam que sejam tratadas como serviços. Dessa forma, sistemas com propósitos diferentes podem fazer uso de um mesmo recurso[neves 2008]. Um caso que possibilita uma visão nítida dessa vantagem é o de uma propriedade que trabalhe com mais de um tipo de rebanho em confinamento. Os sistemas em questão não necessitarão repetir funcionalidades comuns, já que as mesmas estarão disponibilizadas em forma de serviços. Para a integração dos serviços, foi definida a utilização do ESB como infraestrutura, cuja aplicação é comumente vista em ambientes corporativos[lira 2008]. Com sua aplicação neste estudo de caso, estima-se também observar o comportamento desse barramento, já que trata-se de sistemas de menor volume. Esse barramento fará a integração entre o fornecimento de serviços de acordo com as requisições. Como mencionado anteriormente, esse é um ramo em pleno crescimento, que normalmente resulta em alterações em algumas regras de negócio, bem como o acréscimo de outras. Por esse motivo, também serão realizados nesse estudo de caso mudanças e adição de funcionalidades para o monitoramento dos animais em confinamento. Dessa forma, será permitido uma melhor percepção das características resultantes em estruturar esse tipo de sistema, de forma a torná-lo orientado a serviços combinado a utilização de um barramento que centralize o fluxo de informações. 4. Desenvolvimento Ao implementar um sistema utilizando um ESB, é necessário que alguns pontos sejam abordados. Um deles é sobre a decisão de quais ferramentas utilizar. Ao realizar uma observação minuciosa referente ao estudo de caso, foi possível destacar algumas características relevantes para a escolha das tecnologias adequadas Estudo Técnico Por se tratar de um sistema com fluxo de informações baixo em relação às aplicações corporativas, foi estabelecido que uma ferramenta constituída pelas funcionalidades básicas de um ESB poderia ser utilizada de maneira satisfatória. Dessa forma, o JBoss ESB versão 4.6 foi adotado como o barramento desse trabalho, pois além de garantir confiabilidade ao direcionar as requisições aos devidos fornecedores é uma solução gratuita, reduzindo dessa forma, o custo dessa estruturação. Além do JBoss ESB, o Eclipse Ganymede 3.4 foi selecionado como ambiente de desenvolvimento, pela falicidade de integração com o ESB. Após realizada a interação entre as duas ferramentas, obteve-se uma interface amigável ao se criar um novo projeto ESB. 17

22 A fim de auxiliar a melhor compreensão do desenvolvimento, é válido conceituar alguns componentes da ferramenta, como o arquivo jboss-esb.xml obtido após a criação de um projeto ESB. Nesse arquivo são definidas algumas tags necessárias para que haja uma comunicação correta entre os dados. Os Providers são tags que determinam os protocolos em que os eventos podem ocorrer. Já as tags referentes aos Services, definem as funcionalidades disponíveis no barramento. Os Services possuem estruturas internas, as tags Actions e Listeners, a quais possibilitam uma forte ligação com o Provider. Isso ocorre pois a partir dos Listeners e possível que uma chamada do Provider seja compreendida pela tag Services e por consequência, uma Action é ativada, conforme a solicitação recebida. O JbossESB possui várias Actions prontas, o que facilita tanto o desenvolvimento quanto o estudo de sua estrutura de sua implementação Aplicação ao Estudo de Caso A partir da experiência técnica obtida, se fez necessário definir as funcionalidadas de cada serviço utilizado, bem como suas descrições. Dessa maneira, foi definido o serviço de cadastro de confinamento, que, ao ser invocado, armazena no banco de dados as informações recebidas, tais como nome, rebanho, tipo de ração e intervalo de refeição. O outro serviço descrito é referente ao cadastro de rebanho, o qual apenas recebe e grava um nome e a uma descrição no mesmo banco de dados. As funcionalidades citadas foram implementadas em classes distintas, na linguagem de programacão Java. Para realizar a configuracão do ESB, foi utilizada a interface gráfica do JBoss ESB na ferramenta Eclipse. Após a criação de um novo ESB, o protocolo de escuta utilizado nos Providers foi o JMS Provider. Para incluir a funcionalidade propriamente dita, foi adicionado um novo Service, informando o nome, categoria e descricão do serviço, dados importantes para o momento em que o ESB realiza o direcionamento da requisicão. Como mencionado anteriormente, os Services possuem estrutura interna definida, composta pelos Listeners e Actions. Ao adicionar um novo serviço, é preciso que esses dois elementos sejam declarados. Neste estudo de caso, para adicionar os serviços de cadastro definidos anteriormente, foi necessário declarar o Listener de acordo com a configuração do Provider, pois essas tags são as responsáveis por realizar a ligação entre a chamada do serviço e a execução da requisição. Na Action, é definida a implementação pertinente ao devido serviço, tal como a classe responsável pelo cadastro de confinamentos neste estudo. Nesse contexto, a principal tarefa incumbida ao ESB nesse ambiente foi bem realizada, já que essa avaliação introdutória, diz respeito apenas à confiabilidade no direcionamento das requisições aos devidos serviços. 5. Conclusão A aplicação de uma estrutura baseada em serviços ao tipo de sistema abordado, foi uma maneira satisfatória encontrada para facilitar possíveis alterações decorrentes do processo de ascensão do setor. Ao aplicar o ESB a esse ambiente, foi possível destacar principalmente a boa performance desse barramento no que se refere ao direcionamento de uma requisição ao 18

23 devido serviço. Algumas características desse barramento não foram exploradas de forma a se obter resultados consistentes, por exemplo o roteamento inteligente. Um dos motivos desse fato deve-se ao baixo fluxo de informações, já que, nesse momento, o objetivo era verificar a confiabilidade da utilização desse barramento e os impactos sofridos pela sua utilização. A utilização do ESB proveu a centralização dos serviços. Dessa forma, após os experimentos realizados, pode-se afirmar que ao utilizar esse tipo de estrutura aborda, a atividade de confinamento pode ter um considerável ganho principalmente em termos de tempo, visto que essa é uma atividade em constante evolução e suscetível à mudanças. 6. Trabalhos Futuros Para continuidade desse estudo de caso, almeja-se implementar o restante dos serviços necessários para um sistema completo e robusto. Posteriormente, pretende-se estudar outros tipos de confinamento para ampliar a possibilidade de integração nessa atividade. Com isso, pretente-se avaliar de forma criteriosa outros aspectos da utilização desse barramento a esse tipo sistema. Finalmente, após concluídas essas etapas, será proposta a implantação dessa estrutura em um ambiente de produção, para avaliar seu desempenho com um fluxo real de informações. 7. Agradecimentos Os autores agradecem ao apoio recebido de pesquisadores do Grupo de Pesquisa em Engenharia e Computação da Universidade Católica Dom Bosco, GPEC/UCDB, e da Universidade Federal de Mato Grosso do Sul, UFMS. Um dos autores recebeu apoio financeiro da Coordenação de Aperfeiçoamento de Pessoal de Nível Superior, CAPES. Referências Channabasavaiah, K., Holley, K., and Jr., E. M. T. (2004). Migrating to a service-oriented architecture. IBM. Cunha, M., Jr, M. S., Barros, H. S., Calheiros, G., and Torres, W. (2007). Desafios de integração de sistemas: Roadmap, evolução tecnológica e impactos organizacionais. XXVII Encontro Nacional de Engenharia de Produção. Garcia, L. A., Matias, T. F. M., and Garcia, T. R. (2008). Suporte da arquitetura orientada a serviços na integração de sistemas médicos. Dissertação de Graduação - Universidade Federal de Itajubá - Minas Gerais - Brasil. Grossi, B. E. (2005). Estudo do modelo de computação orientada a serviços e sua aplicação a um sistema de mineração de dados. Dissertação de Pós-Graduação - Universidade Federal de Minas Gerais - Minas Gerais - Brasil. Josuttis, N. M. (2007). SOA in Practice. O Reilly Media. Lira, C. T. A. (2008). Utilização de arquitetura orientada a serviços em pequenos negócios. Trabalho de Conclusão de Curso - UFPE - Pernanbuco - Brasil. Machado, J. C. (2004). Um estudo sobre o desenvolvimento orientado a serviços. Dissertação de Mestrado - Puc-Rio - Rio de Janeiro - Brasil. 19

24 Martins, V. M. M. (2005). Integração de sistemas de informação: Perspectivas, normas e abordagens. Tese de Mestrado - Universidade do Minho - Guimarães - Portugal. Neves, B. R. (2008). A aplicação do conceito soa utilizando software open source mule esb. Trabalho de Conclusão de Curso - Faculdade de Tecnologia de Americana - Americana - SP - Brasil. OASIS (2006). Oasis - reference model for service oriented architecture. Pardal, M. F. L. (2006). Segurança de aplicações empresariais em arquitecturas de serviços. Tese de Mestrado - Universidade Técnica de Lisboa - Lisboa - Portugal. 20

25 Uma análise comparativa do frameowrk JQuery com outras ferramentas para desenvolvimento de páginas web interativas. Autor: Pablo Bemher Silva Lima Orientador: Prof. MsC. Raul Benites Paradeda Faculdade de Excelência Educacional do Rio Grande do Norte - FATERN Rua Doutor Hernani Hugo Gomes, 90 - Capim Macio - CEP: Natal/RN Resumo A análise comparativa com o Framework JQuery relata o estudo deste bem como suas, características, aplicação prática e seu uso conforme as normas estabelecidas pela W3C. Este estudo visa esclarecer as principais questões que envolvem o desenvolvimento de aplicações web mais dinâmicas e interativas, tendo como foco principal uma análise comparativa em vários aspectos entre o JQuery e diferentes tecnologias que permitem uma maior interatividade do usuário com a página. Palavras-chave: interatividade, produtividade, web. 1. Introdução A Word Wide Web (WWW) foi criada em 1988 como forma de troca de documentos entre cientistas, anos mais tarde a Web passou a ser utilizada como forma de se informar sobre fatos diversos, hoje em dia já é capaz de fazer compras, vendas procurar empregos, entre outras coisas. Inicialmente as páginas eram totalmente estáticas e textuais, com pouquíssimas imagens sendo necessário conhecimento em linguagens de marcação para se fazer qualquer tipo de atualização ou manutenção nestas páginas, tais como HTML (Hyper Text Markup Language). Com o passar dos tempos a internet foi ficando mais rápida e se popularizando cada vez mais. Surgiram novas tecnologias que permitiam desenvolver páginas dinâmicas, e interfaces mais bem apresentadas. A Web ainda carecia de tecnologias que permitissem além de uma interface bem apresentada e páginas dinâmicas, precisava também ser mais interativa, com este propósito, surge em 1998 o JavaScript. Em 2005 John Resig, um norte-americano, profundo conhecedor da linguagem JavaScript criou o framework JQuery, uma tecnologia que proporciona um alto grau de interatividade através de efeitos de impacto visual, compatível com a maioria os dispositivos e navegadores existentes atualmente. O principal intuito de John Resig ao criar o JQuery foi de simplificar a forma como se adiciona interatividade na web mantendo as páginas acessíveis. Fazendo uma perspectiva sobre os avanços da web é provável idealizar as páginas e aplicações web sendo cada vez mais interativas e dinâmicas como também é possível imaginar a web sendo cada vez mais acessada por meio de dispositivos portáteis, tais como celulares. 21

26 Por esse motivo, este trabalho irá apresentar uma análise comparativa entre o JQuery com outras existentes. O artigo está disposto em nove seções. Na seção dois é descrito a definição do Framework JQuery, na três algumas das principais características e finalidades. A seção quatro apresenta as conformidades do JQuery com os padrões que regem a web. Após, é feita a explanação do uso do framework em questão. Na seção seis, são apresentadas as tecnologias aplacadas na análise comparativa bem com uma breve descrição de cada uma. A seção sete apresenta as comparações realizadas. A seção oito apresenta os resultados obtidos nas análises realizadas. A Seção oito apresenta os resultados finais de todas as comparações desempenhadas. Por fim, a conclusão justificando o crescendo uso do framework JQuery. 2. Definição JQuery é um framework escrito sobre a linguagem JavaScript disponibilizado de forma gratuito e aberto, ou seja, qualquer um pode fazer uso deste framework tanto para fins pessoais, comerciais ou acadêmicos sem precisar pagar nada [1]. Para que seja possível entender o conceito de JQuery é necessário saber que um Framework é definido como um ambiente de trabalho. Este termo é utilizado para designar uma aplicação ou conjunto de aplicações que servem de suporte ao desenvolvimento de software num determinado contexto [2]. 3. Características A Principal característica do JQuery é que ele roda no lado cliente, não sendo encarregada de trazer ou postar informações no servidor, para esta tarefa existe uma série de linguagens, entre elas o Java, Php, Asp, entre outras. Outra característica que deve ser levada em consideração é a possibilidade de adicionar novas funcionalidades através do uso de plugins, tornando-o ainda mais expansível. Estes plugins podem ser escritos ou adicionados ao código com finalidades diversas desde efeitos visuais na página, ou até mesmo o controle de dados via Ajax (acrônimo em língua inglesa de Asynchronous JavaScript And XML) fazendo assim menos requisições ao servidor. Outras características do framework são citadas abaixo: Utiliza seletores CSS (Cascading Style Sheets), para localizar elementos da estrutura de marcação HTML da página; É independente do navegador que o usuário estiver utilizando a página será exibida de uma só forma; Não é necessária a construção de loops para localização de elementos no código; Admite programação encadeada, ou seja, cada método retorna um objeto. Acessa e manipula o DOM (Document Object Model), do inglês Modelo de Objetos de Documentos [1]. Tais características fazem deste framework ser bastante compacto e ao mesmo tempo poderoso. 4. O uso do framework JQuery Para fazer uso do framework não é necessário nenhum tipo de software específico. Trata-se apenas de um arquivo de texto no formato JavaScript (salvo na extensão. js,) [3]. Acessando o site oficial do JQuery (http://jquery.com) é possível fazer o download do arquivo a ser utilizado. Na área de downloads existem diferentes arquivos do framework e um liink para um documento contendo um relatório das principais modificações na 22

27 versão atual. Para cada versão são criados três arquivos todos eles contém basicamente o mesmo conteúdo, diferenciando na compressão de cada arquivo. Independente da versão ou tamanho escolhido, para fazer uso adequado do framework JQuery é necessário na seção head da página HTML fazer chamada do JQuery a ser carregado pelo navegador através do seguinte código: <script type= text/javascript src= \JQuery.js > </script> 5. Análise Comparativa 5.1. Tecnologias Aplicadas As tecnologias listadas a seguir foram escolhidas por serem atualmente as mais utilizadas na web como ferramentas de interatividade, são elas: Adobe Flash: JavaScript tradicional; Framework Prototype JS; Framework Mootools; Adobe Flash O Flash é um Software mantido pela Adobe que o comprou da antiga proprietária a Macromedia. Criado inicialmente com a finalidade de gerar animações nas páginas, após algumas anos na sua versão Flash MX já era possível adicionar interatividade com usuário nas páginas através de uma linguagem de programação nativa do Flash a ActionScript [4] JavaScript O JavaScript foi criado em 1998 pela Netscape mantenedora de um antigo navegador intitulado com o nome da empresa Netscape browser, o JavaScript foi criado com a intenção de processar dados no navegador do cliente tornando o acesso mais rápido fazendo menos requisições ao servidor, inicialmente o JavaScript só funcionava no Netscape aos poucos à medida que foi sendo aderido, os demais navegadores criaram plugins ou novas versões com suporte ao JavaScript Framework Prototype JS O Framework prototype foi o primeiro framework a ser escrito sobre a linguagem JavaScript. Muitos desenvolvedores acostumados com JavaScript passaram a aderir o Prototype JS por perceberem que estavam diante de uma tecnologia muito mais simples, produtiva e acessível. Foi criado em 2005 com o objetivo de facilitar desenvolvimento de aplicações ricas de interatividade [6] Framework Mootools Framework Mootools é o framework mais moderno escrito sobre a linguagem JavaScript, surgiu pouco depois do JQuery, com o propósito de acessar e manipular o DOM de forma mais completa e funcional tornando as páginas mais interativas [7]. 23

28 6. Metodologia utilizada Para que seja possível comparar o JQuery com as demais tecnologias aplicadas é necessário que seja adotado uma série de parâmetros padrões de comparação. Desta forma, os parâmetros de comparações realizadas foram: Consumo de banda: este parâmetro tem como finalidade analisar quais tecnologias exigem mais tráfego da rede. Acessibilidade: este parâmetro visa comparar o grau de acessibilidade entre as aplicações geradas com o JQuery e com as demais tecnologias aplicadas, bem como as recomendações por parte da W3C. Curva de Aprendizado: este parâmetro visa comparar o aprendizado de cada uma das tecnologias aplicadas, assim como, o grau de dificuldade encontrado em cada tecnologia. Um ponto fundamental e decisivo para determinada tecnologia ser aceita no mercado é a curva de aprendizado, é ela que define o tempo que cada desenvolvedor toma para se adaptar a nova tecnologia. Produtividade: Neste ponto será analisado o nível de dificuldade em se trabalhar com cada uma das tecnologias testadas. Produtividade está diretamente relacionada com a curva de aprendizado, se uma ferramenta é de fácil aprendizado conseqüentemente é de fácil[6]. Complexidade jamais será requisito no desenvolvimento de aplicações, por este motivo é que as linguagens de programação de maneira geral tem se tornado cada vez mais produtivas. Comunidade: Neste parâmetro será avaliada a popularidade de cada tecnologia aplicada. De nada adianta uma tecnologia ser produtiva e de fácil aprendizado se dificilmente serão encontradas referências na internet [7] Consumo de Banda Nas análises realizadas apontam o JQuery o Framework Prototype JS, Framework Mootools e o JavaScript tradicional atingindo a nota máxima por se tratarem de tecnologias com baixo índice de consumo de. O Flash atingiu a menor nota por saber que as aplicações geradas através do Flash normalmente ficam com um maior volume de dados, consumindo mais tráfego da rede Acessibilidade Comparando as tecnologias aplicadas em acessibilidade o JQuery e o Mootools saem na frente ambos são os mais acessíveis aos navegadores e dispositivos atualmente o prototype js apesar de bastante acessível apresenta algumas diferençar com alguns browser s, o JavaScript também não obteve boa pontuação por se tratar de tecnologia proprietária de uma empresa que desenvolve um navegador, cada navegador interpreta de forma diferenciada o que pode tornar inacessível a alguns navegadores. Das tecnologias aplicadas o Flash é a menos acessível pelo fato de exigir a instalação de plugin específico e por ser totalmente fechado aos desenvolvedores e motores de buscas Curva de Aprendizado Em se tratando de programação, é comum considerar a linguagem menor e menos complexa mais fácil de se aprender, o JQuery e o Mootools saem na frente mais uma vez atingindo a nota máxima por serem extremamente fáceis de se aprender sem exigir 24

29 declaração de variáveis ou comandos lógico. O Prototype requer uma curva de aprendizado média o que leva o prototype JS a atingir a nota dois o JavaScript atingiu a menor nota junto com o flash, para que seja possível escrever códigos em JavaScript é necessário um amplo conhecimento em lógica de programação, no caso do flash é necessário além de conhecimento no próprio flash conhecimento em XML e na linguagem nativa do flash a ActionScript Produtividade No parâmetro produtividade o JQuery consegue atingir a maior nota 3, o Mootools também se apresenta de forma bastante produtiva porém em alguns casos é necessário um pouco mais de detalhes que o JQuery, outra vantagem do JQuery é a existência de plugins para algumas IDE com recursos como auto-complete e color-code o que torna o trabalho ainda mais produtivo. O prototype js consegue ser produtivo mas não o suficiente para atingir a maior nota o código normalmente não fica concentrado numa área só o que obriga o desenvolvedor a escrever em partes diferentes e até mesmo embutido no HTML. O JavaScript tradicional atingiu a média um por exigir mais raciocino lógico por parte do desenvolvedor, o Flash atingiu a média 1 por exigir um trabalho mais maciço em outras tecnologias como ActionScript e XML Comunidade Para testar a popularidade de cada uma das tecnologias aplicadas foi utilizado gráficos do Google Trends, ferramenta do Google que faz medição de cada termo pesquisado quanto ao volume de dados indexados e um histórico do avanço de cada uma das tecnologias. Figura1: Gráfico de Popularidade entre as tecnologias testadas O Gráfico mostra a popularidade do JavaScript (em vermelho) apesar da recessão que vem sofrendo ainda é a mais popular entre as tecnologias testadas o que leva a nota 3. O JQuery (em azul) vem logo em seguida com seu volume cada vez mais crescente de desenvolvedores, nota 2, a linguagem ActionScript apesar de ser a tecnologia mais antiga entre as demais testadas apresenta uma comunidade pouco significante o que faz desta tecnologia alcançar a média 1. Os frameworks Prototype e Mootools apesar de eficientes são os menos populares ambos contam com uma pequena comunidade de desenvolvedores, o que faz com que estes atinjam a média de 1 ponto. 7. Resultado da Análise comparativa 25

30 Figura 2: Tabela apresentando os resultados Após analisar as tecnologias aplicadas é possível chegar a um resultado mais exato sobre a pontuação de cada tecnologia em cada parâmetro analisado. A Tabela abaixo mostra um somatório dos pontos obtidos por cada uma das tecnologias em cada um dos parâmetros. 8. Conclusão Todo desenvolvedor ao se deparar com algum tipo de aplicação a ser desenvolvida pensa em ser o mais rápido possível, muitas vezes esse pensamento afasta os desenvolvedores de fazer uso de tecnologias interativas como o JQuery. O que estes desenvolvedores não sabem é que através do JQuery é possível gerar páginas muito mais interessantes aos olhos dos usuários sem ter que escrever longos códigos e com uma curva de aprendizado muito menor do que se imagina. Interatividade tem sido cada vez mais freqüente na web e a tendência é que venha a ser requisito para maioria das aplicações, outra tendência a ser levada em consideração é a de que os acessos a web tem sido cada vez mais feita por meio de aparelhos portáteis como celulares, o que torna ainda mais viável o uso do JQuery sobre outras tecnologias. A baixa curva de aprendizado, alto nível de produtividade aliado ao crescente volume de conteúdo disponível na internet e total acessibilidade, fazem do JQuery a melhor opção entre as tecnologias testadas. Referências: [1] Silva, Maurício Samy Livro: JQuery A Biblioteca do Programador JavaScript. Edição 1, Editora: Novatec, ano: 2008 ; [2]Macedo, Marcelo da Silva Livro: Construindo sites adotando padrões web. Edição: 1, Editora: Ciência Moderna, Ano: [3]Resig, John Site: Acessado em 13/05/2009 [4]Diesel, Felipe Site: Acessado em 08 de maio de 2009; [5] Bibeault, Bear e Katz Yehuda Livro: JQuery em ação. Edição 1. Editora Alta Books, Ano: 2009; [6]Greff, Julio Site: Acessado em: 08 de maio de [7]Magno, Alexandro - Site: Acessado em: 09 de maio de

31 Roteamento em Algoritmos IA-RWA em Redes Ópticas Limitadas por Dispersão de Modo de Polarização Alexsandra F. Gomes 1, C. E. M. Fernandes 1,V. A. P. Oliveira 1, Iguatemi E. Fonseca 1 1 Departamente de Ciências Exatas e Naturais - Universidade Federal Rural do Semi-Árido (UFERSA) Mossoró RN Brasil Abstract. This paper presents a proposal of RWA algorithm that use routing techniques for providing Quality of Service in an optical network impaired by Polarization Mode Dispersion (PMD). The results of numerical simulations show that an improvement in performance of network can be achieved if alternative routes are used. Resumo. Este artigo apresenta uma proposta de algoritmo RWA com a utilização de técnicas de roteamento para provimento de Qualidade de Serviço em uma rede óptica dinâmica limitada pelo efeito de Dispersão de Modo de Polarização (PMD). Os resultados das simulações numéricas indicam que uma melhora no desempenho da rede pode ser conseguida se rotas alternativas são utilizadas. 1. Introdução Caso o tráfego continue crescendo no ritmo atual, com o surgimento e consolidação aplicações como vídeo sob demanda, já que a infra-estrutura óptica usada atualmente para esta transmissão são os sistemas SDH/SONET, que utilizam conversão eletro-óptica (O-E-O Optical-to-Eletrical-to-Optical), o esquema de eletrônica tradicional usada nos roteadores no núcleo da rede pode ser tornar um limitante para o crescimento da internet [1], [2]. Redes Ópticas Transparentes (TON Transparent Optical Networks) usando Multiplexagem por Divisão em Comprimento de Onda (WDM Wavelength Division Multiplexing) têm sido encarado como uma estratégia interessante para resolver ambos os problemas [3], [4]. A distribuição do tráfego na rede tem relação direta com o projeto e desenvolvimento de eficientes algoritmos de Alocação de Rota e de Comprimento de Onda (RWA Routing and Wavelength Assignment) utilizados pela Gerência da Rede Óptica para melhorar a alocação dos recursos na rede [6]. Recentemente, algoritmos mais sofisticados, denominados RWA conscientes de limitações da camada física (IA-RWA Impairments Aware RWA), que levam em conta os efeitos da camada física têm sido estudados [7] [17]. O objetivo deste trabalho é apontar que o uso de estratégias simples de roteamento pode melhorar sensivelmente o desempenho dos algoritmos IA-RWA`s. Para isso é apresentada uma estratégia de roteamento baseada no algoritmo de Yen que é testada em uma TON sobre a influência do efeito de PMD, que é um efeito inerente à escolha da rota pelos IA-RWA`s. O restante deste artigo está organizado da seguinte forma. Na Seção 2 a PMD e os parâmetros que podem impactar em uma TON são apresentados. A Seção 3 mostra a proposta de um algoritmo IA-RWA com uma estratégia de roteamento baseada no algoritmo de Yen. Na Seção 4 são discutidos os resultados das simulações numéricas e a Seção 5 traz as conclusões e proposta de trabalhos futuros. 27

32 2. Dispersão de Modo de Polarização A energia do sinal óptico em um dado comprimento de onda se propagando por uma fibra óptica é dividida em dois modos de polarização, que devido às características da fibra, viajam com velocidades de propagação ligeiramente diferentes entre si. Além disso, fatores externos como mudanças de temperatura do ambiente e tensão do cabo durante a instalação, também fazem com que a distribuição da energia do sinal nos modos de propagação varie suavemente com o tempo [6]. Esse fenômeno se traduz em um efeito dispersivo na fibra, chamado de Dispersão de Modo de Polarização (PMD) e causa uma penalidade de potência nos sinais que se propagam pela fibra. A norma ITU G Optical interfaces for single channel STM-64, STM-256 and other SDH systems with optical amplifiers - define que 1dB deve ser a penalidade máxima da degradação do sinal óptico para que uma determinada rota tenha uma transmissão considerada de qualidade. A penalidade, em db, ocasionada pelo PMD em uma fibra pode ser estimada por [19] [20] Em que: T é o período ou tempo de bit, dado por 2 ( t) Penalidade ( db) 26.. γ (1 γ ) 2 T. (1) T 1 B =, B é a taxa de transmissão, dada em bps; t = DPMD L é o atraso médio diferencial entre os dois modos de polarização em um enlace com comprimento L km; e γ é a fração da potência lançada em cada modo de polarização. D PMD é o parâmetro de PMD da fibra óptica, o qual é fornecido pelo fabricante e dado em ps km. Este parâmetro indica o quanto uma fibra é sensível ao efeito de PMD. 3. Algoritmo RWA Proposto 3.1. Algoritmo RWA-distância Algoritmos RWA tradicionais bloqueiam requisições em redes dinâmicas baseados somente na restrição de continuidade de comprimento de onda [21] e foi dessa forma que o algoritmo RWA-distância foi implementado neste trabalho. Como nenhuma limitação da camada física é levada em conta no processo de admissão de conexões, os algoritmos RWA-distância poderiam também ser denominados de PMD-Cegos [25]. Para o processo de escolha da rota, o algoritmo de Yen é utilizado para encontrar as k-ésimas melhores rotas [22], onde o comprimento em km de um dado enlace (ou, a distância entre dois nós vizinhos quaisquer da rede) é definido como o seu custo. O algoritmo First-Fit [23] [24] é usado como estratégia de alocação de comprimento de onda Algoritmo RWA-PMD O Algoritmo RWA-PMD proposto neste trabalho avalia a probabilidade de bloqueio das conexões, não só quanto à disponibilidade ou não de rota e comprimento de onda, como também mediante uma métrica de QoS pré-estabelecida. Como o objetivo do trabalho é estudar o impacto de estratégias de roteamento sobre o desempenho da rede, o efeito de PMD, que é um efeito inerente à escolha da rota na rede, foi avaliado e escolhido como métrica de QoS. A Figura 1 apresenta o fluxograma do algoritmo proposto neste trabalho. Depois de gerada a requisição da conexão, de acordo com o estado atual da rede, o que configura um roteamento adaptativo [18], o algoritmo de Yen procura dentre todas as possibilidades as 28

33 k-ésimas melhores rotas entre a origem e o destino de acordo com o custo, definido de acordo com (1) e (2). Após a execução do algoritmo de roteamento, elege-se portanto, dentre o conjunto total de rotas na rede, um subconjunto contendo as k rotas com menor penalidade imposta pelo PMD. Dentre o subconjunto das k melhores rotas, o critério de QoS óptico é testado e as rotas que atendem a este critério são escolhidas como rotas candidatas à alocação. A disponibilidade comprimento de onda nas rotas candidatas é verificada a seguir usando-se o algoritmo First-Fit e então se decide pela admissão ou bloqueio da conexão. Enfim, perceba que, da forma que foi implementado o algoritmo RWA-PMD, no caso da rota de menor custo já estar em uso, com todos os comprimentos de onda ocupados ou mesmo não atendendo o QoS exigido, é possível que a segunda melhor rota seja utilizada para estabelecer a conexão e dessa forma obter um melhor desempenho da rede Ambiente de Simulação Através de um ambiente de simulação estruturado, utilizando a linguagem de programação C, foi simulado um cenário dinâmico, no qual foram geradas requisições de conexões que possuem um padrão de tráfego uniforme entre os nós da rede e seguem uma distribuição poissoniana, tendo duração com distribuição exponencial (média = 1s). A Rede Óptica utilizada é transparente, ou seja não possui conversão eletro-óptica, e possui 19 nós, com todos os enlaces bidirecionais. Amplificadores ópticos ideais para compensar as perdas dos L km de fibra conectando dois nós adjacentes são aplicados, sendo que L varia entre 80 e 240 km. São usados um conjunto de W=12 comprimentos de onda em uma rede óptica sem conversão de comprimento de onda. A topologia da rede simulada é ilustrada na Figura 2. Foram feitas simulações numéricas para as taxas de transmissão de 2,5, 10 e 40 Gbps. Foi considerado também três modalidades de fibra óptica para os enlaces, de acordo com o componente D PMD, onde fibras mais antigas possuem o valor desse coeficiente mais alto e as de fabricação mais recente mais baixo, demonstrando uma menor influência do PMD [6]. Dessa forma, foi considerado o valor de DPMD = 0,2 ps km para as fibras de fabricação mais recente e DPMD = 1,8 ps km para as de fabricação mais antigas. No caso de enlaces mistos, igualmente utilizados, o simulador atribui DPMD = 0,2 ps km para 50% dos enlaces da rede e DPMD = 1,8 ps km para a outra metade. Requisições de conexões que possuem penalidade devido ao PMD maior que 1 db são bloqueadas por não atender ao critério de QoS exigido. Também foi considerado o tamanho, ou seja, quantidade de saltos (hops), de cada conexão. A partir desses parâmetros, a quantidade de conexões rejeitadas dentre o número total de pedidos de conexões que chegam na rede óptica é a Probabilidade de Bloqueio da rede. Figura 1. Fluxograma do algoritmo RWA-PMD Figura 2. Rede utilizada nas simulações 29

34 4. Resultados 4.1. Impacto do efeito PMD A Figura 3 mostra a probabilidade de bloqueio para os algoritmos RWA-PMD e RWAdistância numa rede com fibras mistas e operando a taxa de transmissão de 2,5 Gbps. Como esperado, quando se considera apenas a distância entre origem e destino como custo para o cálculo da rota, ou seja quando a rede opera com o algoritmo RWA-distância, o bloqueio é menor, já que considerando o PMD, a probabilidade de bloqueio aumenta justamente pelo não atendimento do QoS estipulado (penalidade < 1dB), o que é diretamente proporcional ao aumento do tráfego. Perceba também que quando o algoritmo RWA-PMD opera com uma rota alternativa, ou seja com k=2, a probabilidade de bloqueio apresenta uma melhora da ordem de 25% para tráfego alto e médio. Como pode ser visto na Figuras 4, para uma baixa taxa de transmissão (2,5 Gbps), as redes que possuem fibras homogêneas, ou seja, todos os enlaces tendo o mesmo DPMD, tem um melhor desempenho, até 19% de bloqueio. Enquanto a rede com fibra mista pode ter a probabilidade de bloqueio chegando até 38% com a mesma taxa. Para uma taxa de transmissão de 10 Gbps, as fibras mistas ainda possuem as maiores probabilidades de bloqueio (também em torno de 38%) quando se trata do tráfego de 100 Erlangs, porém as fibras mais sensíveis ao efeito do PMD possuem uma probabilidade de bloqueio na casa dos 27% mesmo quando o tráfego é de apenas 20 Erlangs. Provavelmente, isto se deve a composição das rotas que possuem enlaces com fibras mistas, que favorecem a formação de conexões mais longas e que por isso, têm maior probabilidade de bloqueio tanto devido a continuidade de comprimento de onda quanto à qualidade de serviço, já que o valor da penalidade é cumulativo e proporcional ao comprimento da rota. O bloqueio considerando a quantidade de hops está ilustrado na Fig Impacto da Estratégia de Roteamento Como pode ser visto também na Figura 4, o uso de uma rota alternativa na rede melhora o seu desempenho em cerca de 45% para redes com fibras ópticas com DPMD = 0, 2 ps km ; cerca de 40% para redes com fibras com D PMD = 1,8 ps km operando na taxa de 2,5 Gbps e cerca de 15% na taxa de 10 Gbps; e em torno de 15% para redes com fibras mistas operando nas taxas de 2,5 e 10 Gbps. Há exceção para os casos onde a rede opera a altas taxa de transmissão, como por exemplo 40 Gbps, pois praticamente não existe melhora no desempenho da rede, o que está de acordo com (2), já que a penalidade introduzida pelo PMD cresce com o quadrado da taxa de transmissão. Figura 3. Probabilidade de bloqueio x Tráfego (em Er). Rede com fibras mista. 30

35 Figura 4. Comparação da probabilidade de bloqueio para fibra de D PMD = 0,2, misto e 1,8 em taxas de transmissão de 2,5, 10 e 40 Gbps, respetivamente. Utilizando-se 1 ou 2 rotas. Ainda pode-se verificar que a utilização de fibras de fabricação mais recente, que têm uma menor sensibilidade aos efeitos do PMD, possuem uma melhora considerável na probabilidade de bloqueio, levando os índices a menos de 20% em qualquer taxa de transmissão ou quantidade de rotas utilizadas. B=10Gbps - Fibra Mista - 100Er Probabilidade de Bloqueio 10,00% 8,00% 6,00% 4,00% 2,00% 0,00% Hops Figura 5. Probabilidade de Bloqueio considerando a quantidade de hops para 10 Gbps, fibra mista e tráfego de 100 Erlangs. 5. Conclusão A PMD pode trazer sérios problemas no que diz respeito a QoS na transmissão através de redes ópticas, porém esses transtornos podem ser melhorados através de algumas alternativas que verificamos através dos experimentos desse trabalho. No caso das redes que possuem fibras com D PMD mais alto, uma maneira para melhorar de forma relevante a probabilidade de bloqueio das conexões é utilizar um tipo roteamento que faça uso de uma ou mais rotas alternativas e assim assegurar maior número de requisições de conexão atendidas. Finalmente, é importante lembrar que existem inúmeros outros efeitos que comprometem a qualidade do sinal óptico no decorrer da rota, o que também torna uma proposta de continuidade deste estudo, injetar outros efeitos simultaneamente com o PMD. 6. Referências [1] H. Harai, Optical Packet & Path Integration for Energy Savings toward New Generation Network, in Proc. IEEE SAINT 2008, pp , August

36 [2] M. L. F. Abbade, J. D. Marconi, R. L. Cassiolato, V. Ishizuca, I. E. Fonseca, and H. L. Fragnito, Field- Trial Evaluation of Cross-Layer Effect Caused by All-Optical Wavelength Converters on IP Network Applications, aceito para o IEEE/OSA J. Ligthwave Technology que será publicado em junho/2009. [3] I. Tomkos, S. Azodolmolky, D. Klonidis, M. Aggelou, M. Margariti, Dynamic impairment aware networking for transparent mesh optical networks: Activities of EU project DICONET, in Proc. 10 th IEEE ICTON 2008, pp. 6 12, June [4] M. Yuang, I. Chao, Bird Lo, P. Tien, W. J. Chen, Yu-min Lin, S. S. W. Lee, and Ching-yun Chien, HOPSMAN: An Experimental Testbed System for a 10-Gb/s Optical Packet-Switched WDM Metro Ring Network, IEEE Communications Magazine, vol. 47, pp , July [5] R. Ramaswami, K.N. Sivarajan, Optical networks: a practical perspective, Academic Press, [6] R. Ramaswami, Optical Networking Technologies: What Worked and What Didn t, IEEE Communications Magazine, pp , Sept [7] B. Ramamurthy, et al., Impact of transmission impairments on the teletraffic performance of wavelengthrouted optical networks, IEEE/OSA J. Ligthwave Technology, vol. 10. pp , Oct [8] J. F. Martins-Filho, C. J. A. Bastos-Filho, E. A. J. Arantes, S. C. Oliveira, L. D. Coelho, J. P. G. Oliveira, R. G. Dante, E. Fontana, F. D. Nunes, Novel Routing Algorithm for Transparent Optical Networks Based on Noise Figure and Amplifier, in Proc. IEEE IMOC2003, Sept [9] T. Deng, S. Subramaniam, Source Power Management in Transparent Wavelength-Routed Mesh Networks, in Proc. IEEE ICC 04, Jun [10] M. A. C. Lima, A.F.R. Araújo, A.C César, "Agregação Dinâmica de Tráfego em Redes Ópticas WDM Utilizando Algoritmo Genético", in Proc. MOMAG'04, Aug [11] I. E. Fonseca, M. R. N. Ribeiro, R. C. Almeida Jr., and H. Waldman, "Preserving Global Optical QoS in FWM Impaired Dynamic Networks", IEE Electronics Letters, Vol. 40, pp , Feb [12] I. E. Fonseca, M. R. N. Ribeiro, R. C. Almeida Jr., and H. Waldman, "Meeting Optical QoS in Dynamic Networks with Reduced Complexity", in Proc. IEEE ECOC'04, Sept [13] Raul C. Almeida Jr., Divanilson R. Campelo, Adolfo V. T. Cartaxo, Kenneth M. Guild, and Helio Waldman, Efficient Wavelength Assignment Policy for XPM-Impaired WDM Networks, IEEE Communication Letters, vol. 12, pp , Oct [14] U. S. P. Filho, M. R. N. Ribeiro, C. P. Maioli, M. Freitas, and I. E. Fonseca, Cost functions for cac/rwa in dynamic optical networks under gvd, spm and xpm, Journal of Microwave and Optoelectronics, vol. 6, pp , jun [15] P. Kulkarni, et al., Benefits of Q-factor based routing in WDM metro networks, in Proc. ECOC 2005, Glasgow, U.K., Sept [16] M. Ali, L. Tancevski, "Impact of Polarization-Mode Dispersion on the Design of Wavelength-Routed Networks", IEEE Photonics Technology Letters, Vol. 14, pp , May [17] R. Martinez, C. Pinart, J. Comellas, G. Junyent, Routing Issues in Transparent Optical Networks, in Proc. IEEE ICTON 2006, Jun [18] B. Mukherjee, Optical WDM Networks, Springer optical networks series, [19] C. D. Poole, R. W. Tkach, A. R. Chraplyvy, and D. A. Fishman, Fading in Lightwave Systems Due to Polarization-Mode Dispersion, IEEE Photonics Technology Letters, Vol. 3, pp , May [20] X. Liu, C. Xie, and A. J. van Wijngaarden, Multichannel PMD Mitigation and Outage Reduction Through FEC With Sub-Burst-Error-Correction Period PMD Scrambling, IEEE Photonics Technology Letters, Vol. 16, pp , Sept [21] R. Ramaswami, K.N Sivarajan, Routing and Wavelength Assignment in All-optical Networks, IEEE/ACM Transactions on Networking, Vol. 3, Oct [22] J. Yen, Finding the k shortest loopless paths in a network, Management Science, vol. 17, pp , July [23] I. Chlamtac, A. Ganz, G. Karmi, Lightpath communication: na approach to high bandwidth optical WAN s, IEEE/ACM Transactions on Communications, Vol. 40, [24] H. Zang, J. P. Jue, and B. Mukherjee, A Review of Routing and Wavelength Assignment Approaches for Wavelength-Routed Optical WDM Networks, SPIE Optical Network Magazine, Vol. 1, pp , Dec [25] I. E. Fonseca, Uma abordagem para Aprovisionamento e Diferenciação de QoS Óptico na Presença de FWM em Redes Ópticas Transparentes, Tese de Doutorado, FEEC/Unicamp, Abril

37 Clusterização de Dados Coletados do Exame de Glicemia Usando o Algoritmo Fuzzy C-Means Intervalar Rogério R. de Vargas 1, Benjamín R. C. Bedregal 1, Macilon A. Costa Neto 2 1 Programa de Pós-Graduação em Sistemas e Computação, DIMAp, UFRN Lagoa Nova Natal, RN - Brazil 2 Universidade Federal do Acre, UFAC Rio Branco, AC Brazil Abstract. Clustering algorithms for unsupervised pattern recognition fulfilling a key role for the exploratory data analysis. One of the most used algorithms in the group of data points is the fuzzy c-means. Thus, is proposed an interval extension of the fuzzy c-means algorithm (IFCM) that allows data entry and the membership degree are intervals. Thus enabling, represent data with no conversion of data to spot interval. Shown is the result of a simulation with the algorithm IFCM for a sample interval of 150 data, grouping them into three clusters. Resumo. Os algoritmos de clusterização consiste de uma abordagem não supervisionada de reconhecimento de padrões que cumprem um papel fundamental para a análise exploratória de dados. Um dos algoritmos mais utilizados na clusterização de dados pontuais é o Fuzzy C-Means. Diante disso, é proposta uma extensão intervalar desse algoritmo (IFCM) que permite que a entrada dos dados e o grau de pertinḙncia sejam intervalos. Permitindo assim, representar os dados sem nenhuma conversão dos dados intervalares para pontuais. É mostrado o resultado de uma simulação com o algoritmo IFCM para uma amostra de 150 dados intervalares, agrupando-os em trḙs clusters. 1. Introdução Diabetes mellitus é um distúrbio metabólico determinado geneticamente, associado com deficiência absoluta ou relativa de insulina e que na sua manifestação clínica completa é caracterizado por alterações metabólicas, complicações vasculares e neuropáticas [Maia and Campos 2005]. A auto-monitorização da glicemia é uma conquista muito importante, pois permite maior flexibilidade no tratamento do diabetes, independentemente se tipo 1 ou 2. No mercado existe diversos equipamentos de monitoração da glicemia que podem ser operados pelo próprio paciente. Entretanto, esses equipamentos possuem um erro associado na medição (calibragem) que pode influir em uma análise mais aprofundada. Nos métodos de clusterização (ou agrupamento) hard, os clusters são uma partição no sentido matemático dos dados. Assim, cada ponto no conjunto de dados pertence a Bolsista de Doutorado Capes 33

38 exatamente um cluster. Já clusterização fuzzy, tem a sua partição baseada na ideia de funções de pertinência expressa por um grau de pertinência referente a um cluster, isto é, os algoritmos fuzzy associam um dado a todos os clusters através da variação do grau de pertinência do dado em cada cluster. Em [Carvalho 2007] foi proposto também uma extensão intervalar do algoritmo fuzzy c-means, onde cada dado de entrada é um intervalo. Para calcular a distância de cada ponto a um determinado cluster (de intervalo) é usado uma adaptação da distância Euclidiana. Na finalidade de validar o método proposto, foi realizado vários testes em conjuntos de dados intervalares, um consistindo na classificação de carros por determinada característica e outro pela variação da temperatura em diversas cidades. Em diversas pesquisas utilizando dados intervalares, como por exemplo descrito em [Carvalho 2007] e [Zhang et al. 2007], são propostas adaptações no algoritmo fuzzy c-means para lidar com dados intervalares. Porém os algoritmo propostos por estes trabalhos, usam graus de pertinências pontuais. Em [Bock 2000] e [Sato and J. 2006] têm também a entrada de dados como intervalos, porém estes não consideram o grau de pertinência como intervalos. Representar o conjunto de dados como intervalos consiste em delimitar os erros ocasionados por estimativas de medições, de simplificações, modelagem, por falha humana ou pelo instrumento de medição. Um dos objetivos deste trabalho é apresentar uma forma de clusterização para os valores amostrais que consideram os erros contidos. Então a entrada dos dados são valores intervalares. Desta forma, julga-se que a classificação de cada elemento a um determinado cluster (o grau de pertença) também seja um intervalo. 2. O algoritmo IFCM Entre os diversos algoritmos de clusterização existentes, este trabalho deter-se-á a intervalização do algoritmo proposto por [Dunn 1973] e [Bezdek 1981] chamado fuzzy c-means (FCM). O algoritmo para clusterização de dados intervalares, denominado Interval Fuzzy C-Means (IFCM), aqui proposto, baseia-se na estrutura do FCM em [Cox 2005]. O IFCM tenta de encontrar conjuntos nos dados minimizando uma função objetiva mostrada na equação (1): J = n c µ m ij d I (X i ; C j ) 2 (1) i=1 j=1 onde: n é o número de dados intervalares; c é o número de clusters considerados no algoritmo, o qual deve ser decidido antes da execução; m é um fator de fuzziness (um valor maior do que 1) 1 ; 1 Só consideramos valores racionais para não complicar o cálculo das equações (1), (2) e (3). Uma vez que na prática são usados m racionais. 34

39 X i é o i-ésimo dado intervalar; C j é o centro (intervalo) do j-ésimo cluster; d I (X i ; C j ) é a distância intervalar entre X i e C j ; A entrada do algoritmo são n dados intervalares, o número de cluster c e o valor m. Suas etapas são: 1. Inicialize µ com subintervalos de [0; 1] aleatórios associados a cada par (dados/clusters) tais que para cada par dados/cluster (X i ; j) e a j µ i,j temos que existem a k µ i,k para todo k {1,..., j 1, j + 1,...,c} satisfazendo c a k = 1 k=1 2. calcule o centro do cluster j da seguinte maneira: n C j = i=1 n i=1 µ m ijx i µ m ij (2) 3. calcule um valor inicial (um intervalo de dado) para J usando a equação (1) 4. calcule a tabela de função de pertinência fuzzy intervalar conforme mostrado na equação (3) µ ij = ( c ( k=1 1 d I (X i ;C j ) ) 1 m 1 1 d I (X i ; C k ) ) 1 m 1 (3) 5. retornar a etapa 2 até que uma condição de parada seja alcançada. Algumas condições de parada possíveis são: Um número de iterações pré-fixado for executado, e pode-se considerar que o algoritmo conseguiu agrupar os dados; o usuário informa um valor de parada ǫ > 0, e se d I (J U ; J A ) [ǫ; ǫ] então pára, onde J A é a função objetiva (equação (1)) calculada da iteração anterior e J U é a função objetiva da última iteração. 3. Aplicação e Resultados Aparelhos medidores de glicemia como o Accu-Chek Aviva/ Compact Plus fabricado pela Roche R, possui um erro de calibragem associado ao aparelho em torno de ±10% [Roche 2009]. 35

40 Uma aplicação deste algoritmo que tem por objetivo agrupar dados e reconhecer padrões pode ser dado em uma clínica especializada em diabetes, que deseja conhecer o padrão de pacientes A implementação do algoritmo foi realizada na linguagem de programação C++ (compilador g++ 4.4), no sistema operacional Linux (Ubuntu 9.04) e utilizou-se a biblioteca C-XSC (versão 2.2) [Hofschuster and Krämer 2003], disponível em xsc.de. A entrada de dados foi simulada como se fosse obtida dos aparelhos medidores de glicemia, com um erro de calibragem associado ao equipamento em 10% do valor pontual.. Foram 150 dados intervalares distintos, dividido-os em cinco grupos. Satisfazendo a etapa 1 do algoritmo, gerou-se 150 graus de pertinência para cada cluster. As especificações desses dados são mostrados na tabela 1. Tabela 1. Entrada de dados GRUPO GLICEMIA ENTRE (mg/dl) AMOSTRA G1 [40; 64, 9] 15 G2 [65; 74, 9] 20 G3 [75; 94] 60 G4 [94, 1; 104] 25 G5 [104, 1; 300] 30 Os parâmetros de entrada foram 150 dados, 3 clusters, m = 1, 25 e ǫ = 0, 01. Nessa simulação de cento e cinquenta dados intervalares o diâmetro desses intervalos é no máximo quinze, variando aleatóriamente esses dados entre o intervalo [40; 300] mg/dl, é mostrado a seguir, os resultados obtidos com o algoritmo IFCM. Observe que o nível glicêmico na figura 1(a) referente o intervalo [200; 300] mg/dl possuem o grau de pertinência próximo de um. E nível glicêmico abaixo de 175 mg/dl, tendem a ter um grau de pertinência praticamente zero. 1 CLUSTER 1 1 CLUSTER grau de pertinencia grau de pertinencia GLICEMIA (mg/dl) GLICEMIA (mg/dl) (a) Cluster 1 (b) Cluster 2 Figura 1. Agrupamento dos Clusters Analisando o cluster 2 na figura 1(b), tem-se que dados intervalares entre [50; 80] mg/dl possuem o grau de pertinência quase um. O nível glicêmico entre [90; 120] mg/dl, possui o grau de pertinência entre [0, 8; 1]. E por fim, a figura 2(a) mostra os dados glicêmicos no cluster 3. 36

41 1 0.9 CLUSTER CLUSTER 1 CLUSTER 2 CLUSTER grau de pertinencia grau de pertinencia GLICEMIA (mg/dl) GLICEMIA (mg/dl) (a) Cluster 3 (b) Todos os Clusters Figura 2. Agrupamento dos Clusters O intervalo de dados no cluster 3 entre [110; 190] mg/dl, o grau de pertinência esta entre [0, 75; 1] e valores glicêmicos não contidos nesse intervalo tendem a ter um baixo grau de pertinência. O resultado final englobando os três clusters é mostrado na figura 2(b). Neste exemplo em que os dados foram simulados, obteve-se uma boa separação do agrupamento. Em nenhum dos casos um elemento pertence tanto a um cluster quanto a outro. Uma discussão mais abrangente pode ser dada utilizando o conceito de α corte [Yang et al. 2008], no qual este permite cortar os dados expostos dado algum grau de pertinência, seja com intervalos degenerados ou não. Se for utilizado algum α corte linear acima de 0, 7 algum dado poderá ser desprezado, ocasionando que um elemento não pertença a nenhum cluster. Usando um α corte abaixo de 0, 3 certamente nesta simulação causará diversas intersecções. Neste exemplo específico, caso fosse optado pela utilização do α corte, um bom parâmetro para esta aplicação seria em torno de 0, 5. Com α corte em 0, 5 é gerado uma partição na base de dados, ou seja, cada dado intervalar pertence a exatamente um cluster. Observe que isso pode ser encarado como uma clusterização crisp da base. Porém, isso não significa que o α corte particione qualquer base de dados intervalares. O sistema convergiu após 38 iterações e o tempo de processamento foram de 4 minutos e 25 segundos. 4. Conclusões A análise de cluster não é um processo realizado em apenas uma execução. Em muitas circunstâncias, é necessário uma série de tentativas e repetições. Ainda, não há um critério universal e efetivo para guiar a seleção de atributos e de algoritmos de clusterização. Critérios de validação provêm impressões sobre a qualidade dos clusters, mas como escolher este mesmo critério é ainda um problema que requer mais esforços [Jr Cavalcanti 2006]. O contexto deste trabalho esta inserido na abordagem simbólica da análise de dados (SDA - Symbolic Data Analysis) relacionada com métodos para a extração de conhecimentos em grandes bases de dados. O principal objetivo da SDA é desenvolver métodos 37

42 para o tratamento de dados mais complexos como intervalos. Neste contexto, vários pesquisadores [Carvalho 2007][Zhang et al. 2007] [Bock 2000] e [Sato and J. 2006] vêm trabalhando no sentido de estabelecer e aplicar metodologias na clusterização de dados intervalares. Este trabalho também pretende ser um aporte para essa área. Uma das propriedades da abordagem proposta é respeitar o princípio da corretude, no sentido de [Hickey et al. 1999], ou seja, se considerasse qualquer valor pontual entre os seus respectivos valores (intervalares) como dado de entrada e grau de pertinência, usando o algoritmo pontual fuzzy c-means, o agrupamento resultante estaria contido no intervalo apresentado pelo IFCM. Neste trabalho estudou-se outros algoritmos de clusterização para a entrada de dados intervalares. Então a vantagem é que neste algoritmo fuzzy c-means consideram graus de pertinências intervalares propiciando conhecer ainda mais a imprecisão nos dados de entrada. O grande trunfo deste algoritmo é sempre manter os dados de entrada e operações com intervalos e quando necessário calcular a distância de cada ponto ao centro de cada cluster, usar uma métrica intervalar em vez de usar uma métrica pontual como a distância Euclidiana. O algoritmo Interval Fuzzy C-Means proposto neste artigo, houve a aplicação de duas técnicas: a matemática intervalar e a teoria dos conjuntos fuzzy. Desta forma, é possível tratar os dados de entrada imprecisos em resultados com funções de pertinências intervalares. Referências Bezdek, J. (1981). Pattern Recognition with Fuzzy Objective Function Algorithms. Kluwer Academic Publishers, Norwell, MA, USA. Bock, H. (2000). Analysis of Symbolic Data: Exploratory Methods for Extracting Statistical Information from Complex Data. Springer-Verlag New York, Inc., Secaucus, NJ, USA. Carvalho, F. (2007). Fuzzy C-Means Clustering Methods for Symbolic Interval Data. Pattern Recogn. Lett., 28(4): Cox, E. (2005). Fuzzy Modeling and Genetic Algorithms For Data Mining and Exploration. Morgan Kaufmann, San Francisco. Dunn, J. (1973). A Fuzzy Relative of the ISODATA Process and Its Use in Detecting Compact Well-Separated Clusters. Journal of Cybernetics, 3: Hickey, T., Ju, Q., and Emden, M. (1999). Interval Arithmetic: from Principles to Implementation. Journal of the ACM, 48: Hofschuster, W. and Krämer, W. (2003). C-XSC A C++ Library for extended Scientific Computing. In Numerical Software with Result Verification: International Dagstuhl Seminar, Dagstuhl, pages Springer. Jr Cavalcanti, N. (2006). Clusterização baseada em algoritmos fuzzy. Master s thesis, Universidade Federal de Pernambuco, Recife, Brasil. Maia, C. and Campos, C. (2005). Diabetes Mellitus as Etiological Factor of Hearing Loss. Rev. Bras. Otorrinolaringol., 71(2). 38

43 Roche (2009). Diabetes faq - roche portugal. Acesso em 10 março de Sato, M. and J., L. (2006). Innovations in Fuzzy Clustering: Theory and Applications (Studies in Fuzziness and Soft Computing). Springer-Verlag, Berlin, Heidelberg. Yang, M.-S., Wu, K.-L., Hsieh, J.-N., and Yu, J. (2008). Alpha-cut implemented fuzzy clustering algorithms and switching regressions. Systems, Man, and Cybernetics, Part B: Cybernetics, IEEE Transactions on, 38(3): Zhang, W., Hu, H., and Liu, W. (2007). Rules Extraction of Interval Type-2 Fuzzy Logic System Based on Fuzzy c-means Clustering. Fuzzy Systems and Knowledge Discovery, Fourth International Conference on, 2:

44 Banco de Dados Objeto-Relacional: comparação do suporte oferecido por SGBDs para a persistência de objetos Carlos A. R. Junior, Thiago Rais de Castro, Solange N. Alves de Souza Escola Politécnica da Universidade de São Paulo (EP-USP) R. Prof. Luciano Gualberto, trav. 3, n o São Paulo SP Brazil Abstract. This article presents a model which describes the features to support the object concepts in the SQL:2003 standard. This model was based in the ontology was proposed to allow to understand the standard SQL:2003 more easily. This model also is used to guide exposition of the features in the SQL:2003 and in the Oracle 11g and PostgreSQL 8.4 DBMS. This approach give more complete view and better comprehension of the existing features in Object-Relational DBMS (ORDBMS), allowing its use in a lot of the real application. In the end, a study of case is used to compare the SQL:2003 standard and the previous ORDBMS. Resumo. Neste artigo uma ontologia, proposta para facilitar o entendimento da especificação SQL:2003, é usada como base para a apresentação de um modelo que descreve as características voltadas para o suporte de objetos na SQL:2003. Este modelo também é usado para guiar a apresentação dessas características tanto na SQL:2003 quanto nas versões dos SGBDs Oracle 11g e PostgreSQL 8.4. Esta abordagem permite uma estruturação mais lógica, uma visão mais completa e o entendimento mais fácil das características existentes nos SGBDOR, permitindo seu real uso em muitas aplicações reais. Ao final, um estudo de caso permite a comparação da especificação SQL:2003 e dos SGBDORs utilizados. 1. Introdução Sistemas Gerenciadores de Banco de Dados Relacionais (SGBDR) mostraram-se pouco eficientes para o suporte às aplicações que envolvem a manipulação de dados complexos como aplicações científicas e médicas, de informações geográficas, dentre outras. Para suprir esta necessidade esforços foram empregados ao longo dos anos e culminaram na especificação da SQL:99 (ANSI/ISO/IEC 9075-x:1999) - revisão do padrão SQL:92 (base de SGBDRs). A especificação da SQL: 1999 foi impulsionada por vários SGBDs existentes que apresentavam algum grau de extensão para manipulação de objetos. A SQL:2003 (ANSI/ISO/IEC 9075:2003), revisão da SQL:99, define um conjunto de elementos ou recursos para a especificação de objetos dentro de banco de dados. Os SGBDs atuais que implementam a SQL:2003 ou parte dela são nomeados Sistemas Gerenciadores de Banco de Dados Objeto-Relacional (SGBDOR). Embora os recursos para manipulação de objetos já estejam disponibilizados por esses SGBDs, existe uma tendência em se utilizar apenas a parte relacional do padrão. Além disso, não existe uniformidade dos recursos implementados nestes SGBDs e nem em relação à 40

45 especificação SQL:2003. Informações sobre esses recursos e seus inter-relacionamentos precisam ser difundidas. Por outro lado, os artigos que apresentam as novas características da norma, o fazem de maneira dispersa, sem a preocupação em mostrar a interdependência existente entre essas características. Além disso, poucos trabalhos mostram como esses recursos estão disponibilizados em SGBDs existentes. Diferente dos demais, este artigo utiliza um modelo de classes UML, o qual foi baseado na ontologia proposta por Calero et al. (2005). O modelo aqui apresentado fornece uma visão geral dos elementos existentes para a definição de esquemas de objetos e seus inter-relacionamentos. Esta abordagem permite uma estruturação mais lógica, uma visão mais completa e o entendimento mais fácil das características existentes nos SGBDOR, permitindo seu real uso em muitas aplicações reais. O estudo de caso auxilia a compreensão para o uso desses elementos. Este trabalho apresenta também os recursos disponíveis para o suporte de objetos nos SGBDs Oracle 11g release 1 e PostgreSQL 8.4. Outros trabalhos correlatos apresentaram o suporte oferecido por versões não atuais de SGBDOR e/ou basearam-se na especificação SQL: Trabalhos Correlatos No artigo de Eisenberg et al. (2004) são apresentadas algumas das novas funcionalidades da SQL:2003 relacionadas com a parte relacional do padrão. O Artigo não descreve como esses recursos estão disponibilizados em SGBDs existentes. A SQL:2003 é implementada de forma diferente entre os fabricantes de SGBDs, e há recursos disponibilizados em determinados SGBDs que não estão presentes em outros. Por conta disso, se faz necessário a investigação, não apenas dos novos elementos da SQL:2003, como também da forma de como estão implementados em SGBDs existentes. Em Pardede et al. (2004) é discutido de forma isolada os aspectos da SQL:2003 referentes a parte orientada a objetos. Essa abordagem torna difícil a abstração do conceito associado a cada elemento e sua interdependência. Por outro lado, o universo relacional é bem difundido e sua implementação nos SGBDs em uso é quase que homogênea. Para que os novos recursos associados ao paradigma de orientação a objetos sejam largamente utilizados é preciso entender num primeiro momento que elementos existem, seus inter-relacionamentos e como estão disponíveis nos SGBDs. Posteriormente novos dados associados ao desempenho, por exemplo, serão também necessários. Em Marcos, et al. (2003), Cavero, et al. (2001) e Vara, et al. (2007) é proposto uma extensão do diagrama de classes da UML para o Projeto Conceitual em BDORs. Nestes trabalhos discutem-se maneiras de se fazer o mapeamento de objetos e seus relacionamentos do diagrama de classes para a SQL:1999. Apesar do esforço por parte dos pesquisadores em discutir a parte OR do padrão, a fim de difundir suas vantagens e propor novos modelos para representá-la conceitualmente, ainda são necessários trabalhos para não apenas apresentar os recursos existentes na norma, mas fazê-lo de forma estruturada, mostrando o significado desses recursos, como estão interrelacionados e como podem ser utilizados. Além disso, devido às diferenças de implementação é necessário mostrar como esses recursos, caso existam, estão disponíveis em SGBDs existentes. 41

46 3. SQL:2003 Para apresentar os elementos da SQL:2003 que fornecem o suporte a especificação de um BDOR, a ontologia desenvolvida por Calero et al. (2005) foi utilizada. Tal ontologia utiliza um diagrama de classes e regras expressas em OCL (Object Constraint Language) para permitir o entendimento dos elementos da linguagem e seus interrelacionamentos, bem como o entendimento das diversas divisões da norma ISO/IEC 9075: No presente artigo apenas parte dos elementos dessa ontologia é utilizada. A figura 1 mostra um diagrama de classes UML que tem como base o definido por Calero et al (2005). O diagrama da figura 1 é mais conciso, fornecendo uma visão geral dos elementos da linguagem SQL:2003 para o suporte de objetos. Conforme os conceitos são apresentados, realiza-se um comparativo entre as versões mais recentes dos gerenciadores Postgres 8.4 e Oracle 11g com objetivo de difundir a forma com que esses recursos são definidos. Figure 1. Diagrama de Classes UML apresentado os elementos da SQL:2003 e seus inter-relacionamentos para suporte a BDOR Ainda figura 1, foram omitidas algumas associações, classes, além das regras expressas em OCL presentes na ontologia, pois o objetivo é usar um modelo que explique os elementos ou recursos existentes na norma e guie a apresentação estruturada e completa dos elementos da SQL:2003 para suporte a definição de esquemas objeto relacionais. Similarmente à ontologia, o diagrama de classes da figura 1 está dividido em duas sub-hierarquias, uma que traz os tipos de dados e outra, os tipos de objetos que podem ser definidos. Algumas classes (por exemplo, tipos Pré-Definidos, Restrição, Domínio, Tabelas Transientes e Derivadas) em cada uma das sub-hierarquias não são detalhadas neste artigo, pois apresentam nenhum, ou pouco acréscimo em relação às versões antigas da norma e não influenciam a definição de um esquema de objetos Tipo de Dado Os Tipos de Dados são classificados em três classes principais: Tipo Pré-Definido, Tipo Construído e Tipo Definido pelo Usuário (User Defined Type - UDT). Conforme figura 1, os tipos construídos consistem em: tipos atômicos, como o REF, tipos complexos, como ROW, ou ainda coleções, como ARRAY e MULTISET. Um Row é uma estrutura composta por um ou mais campos. A tabela 1 traz a definição de cada um desses tipos na SQL:2003 e como estão implementados nos SGBDs Oracle e PostgreSQL. Um Tipo Definido pelo Usuário pode ser da categoria Tipo Distinto ou Tipo Estruturado. Um Tipo Estruturado é composto por um ou mais atributos, pode gerar 42

47 hierarquias supertipo-subtipo, além disso podem ser definidos Métodos para manipular o Tipo Estruturado a que se refere. Um Tipo Estruturado pode ser utilizada para definir uma tabela tipada, ou para especificar o domínio de campos de uma tabela base (tabelas definidas por uma <definição de tabela>, similar a versões anteriores da norma) ou de uma tabela tipada (item 3.2.2). Um Tipo Estruturado no Oracle 11g é similar à norma. No PostgreSQL 8.4, como na norma, um Tipo Estruturado é composto por um ou mais atributos. Este tipo pode ser utilizado para definir domínios de colunas de tabelas. Table 1. Tipo Construído Tipos SQL:2003 ORACLE PostegreSQL um valor REF é o valor de uma possui um tipo REF que é referência para uma tupla em uma usado para referenciar um REF não suporta. tabela Tipada (a tupla é derivada objeto através do seu OID de um tipo estruturado). (Object Identifier) ROW ARRAY MULTISET 3.2. Objeto consiste de uma seqüência de campos, onde cada campo é definido pelo par (<nome_campo>, <tipo_de_dado>) consiste de uma coleção de elementos do mesmo tipo de dado. Cada elemento está associado a uma posição ordinal. A cardinalidade determina o número máximo de elementos na coleção. consiste de uma coleção de elementos de mesmo tipo de dado. Os elementos não estão associados a uma posição ordinal. até versão atual do Oracle (11g release 1) não existe o tipo ROW. existe o tipo VARRAY. Quando um objeto do tipo VARRAY é definido, deve-se explicitar sua cardinalidade, no entanto seus campos são alocados dinamicamente. não possui o tipo MULTISET. não existe o tipo ROW existe o tipo Array, É posível definir array bidimensional. não possui o tipo Multiset. De acordo com a figura 1, um Objeto pode ser classificado em uma das seguintes classes: Tabela, Restrição, Domínio e UDT. A classe Tabela (figura 1) pode ser especializada nas classes Transiente, Derivada e Tabela Base (tabelas persistentes ou temporárias definidas a partir de uma <definição de tabela> - similar as versões antigas da norma). Uma tabela é composta por uma ou mais colunas. Uma Tabela Tipada é definida por um Tipo Estruturado, ou seja, as linhas de uma Tabela Tipada são derivadas de um Tipo estruturado. Tabelas tipadas podem ser especializadas; para que uma tabela tipada possa estender outra tabela tipada, os tipos estruturados associados a essas tabelas devem pertencer à mesma hierarquia de especialização. Por exemplo, seja TT 1 uma tabela tipada associada ao tipo estruturado TE 1 e TT 2 uma tabela tipada associada ao tipo estruturado TE 2. A tabela tipada TT 1 poderá estender a TT 2 se, e somente se, TE 2 for supertipo direto do TE 1, ou seja, TE 2 deve aparecer na cláusula de generalização presente na especificação de TE 1. No Oracle 11g uma tabela Tipada é definida a partir de um tipo Estruturado, similar a norma. O Postgre 8.4 não oferece suporte a tabelas tipadas. 43

48 3.3. Herança Na SQL:2003 relacionamentos de herança podem ser definidos entre tipos Tipos Estruturados, Tipos ROW e entre Tabelas. Na herança de tabelas, não apenas a estrutura como na herança de tipos, mas também os dados e restrições sobre os dados são herdados. No Oracle não existe herança de tabelas. Neste, um tipo estruturado pode estender outro tipo estruturado. Tabelas tipadas podem ser definidas a partir de tipos na hieraquia, ou seja, criam-se os tipos de dados já definindo a hierarquia, na seqüência criam-se tabelas a partir dos tipos definidos. Pode-se incluir à definição da tabela restrições (constraints) e especificar valores default, contudo cabe ressaltar que essas restrições não são herdadas por tabelas definidas por uma extensão de um tipo estruturado, já que não existe herança de tabela. O PostgreSQL 8.4 permite herança apenas entre tabelas, sendo possível também herança múltipla entre tabelas. Na herança de tabelas, dados também são herdados, porém restrições não o são. Registros inseridos numa subtabela podem ser acessados via a supertabela que a originou. Um problema observado, como as restrições não são herdadas, pode acontecer de ser inserido um ou mais registros na subtabela com valores iguais para as colunas que definem a chave primária da supertabela. Neste caso, ao acessar os dados da supertabela será possível se deparar com mais de um registro contendo valores iguais para as colunas que constituem a chave-primária. 4. Estudo de Caso Figura 2 Modelo de classes UML para parte de uma aplicação hospitalar A figura 2 apresenta o modelo de classes UML e os respectivos códigos em SQL gerados, para melhor visualização, para parte do modelo. Este mostra a representação simplificada de internações de pacientes. Nesta, pacientes internados podem ocupar 44

49 leitos diferentes durante a estadia, sendo necessário o registrado do momento de início e fim da ocupação do leito para que o mesmo possa ser ocupado por outras internações em momentos diferentes. Todo paciente para ser internado precisa ter um registro hospitalar (rh) e se o paciente for menor de idade registra-se também um responsável. O Oracle, como na norma, suporta a definição de tabelas a partir de tipos, permitindo a reutilização de código. Além disso, a definição de um tipo não determina a definição de tabelas daquele tipo (ex. classe Pessoa). Outro destaque, o suporte ao tipo REF elimina a necessidade de junções. Apesar de não possuir o tipo Multiset, é possível criar tabelas aninhadas através da cláusula NESTED TABLE. O PostgreSQL não possui o tipo REF. Assim, é necessário especificar chaves estrangeiras para representar associações, agregações e composições. Como também não é possível a definição de tabelas de tipos, foi necessário criar a tabela Pessoa (figura 2). Neste artigo, devido a limitação de espaço, apresenta-se apenas o código para o mapeamento dos objetos do modelo de classes na base de dados considerando a SQL:2003 e os SGBDs Oracle e PostgreSQL. 5. Comentários e Conclusões Este trabalho preocupou-se em apresentar as características da SQL:2003 juntamente com um comparativo entre os SGBDs Oracle e o PostgreSQL com relação ao suporte fornecido à SQL:2003. Observou-se que, comparado ao PostgreSQL, o Oracle permite um mapeamento para a base de dados mais próximo ao do modelo de classes, diminuindo o descasamento de impedância que existe para o modelo relacional. Cabe ressaltar que o MS SQL Server, versão 2008, também está sendo avaliado. Contudo não foi possível finalizar essa pesquisa, de modo a poder incluir seus resultados em tempo de finalização deste artigo. 6. Referências Calero, C., Ruiz, F., Baroni, A., Brito, F. e Piattini, M. (2005) An Ontological Approach to Describe the SQL:2003 Object-Relational Features. Journal of Computer Standards & Interfaces - Elsevier. Eisenberg, A., J. Melton, K. Kulkarni, J. Michels e Zemke, F. (2004) SQL:2003 Has Been Published. SIGMOD Record. Pardede, E., Taniar, D. e Rahayu, J. W. (2004) New SQL Standard For Object- Relational Database Applications. Institute of Electrical and Electronics Engineers, Inc. Eisenberg, A.; Melton, J.(1999) SQL:1999, formerly known as SQL3. SIGMOD RECORD. Marcos, E.; Vela, B.; Cavero, J. M. (2003) A Methodological Approach for Object- Relational Database Design using UML. Software and Systems Modeling. Cavero, J. M.; Marcos, E.; Vela, B. (2001) Extending UML for Object-Relational Database Design. Lecture Notes in Computer Science, pp Vara, J. M.; Vela, B.; Cavero, J. M.; Marcos, E. (2007) Model Transformation for Object-Relational Database Development. Proceedings of the 2007 ACM symposium on Applied computing, pp

50 Abordagem com interação entre as camadas de aplicação, roteamento e MAC para redes de sensores sem fio Edsongley Varela de Almeida 1 Weliana Benevides Ramalho 1 Marcelo Sampaio Alencar 1 Iguatemi Eduardo da Fonseca 1 1 Universidade Do Estado do Rio Grande do Norte UERN Universidade Federal da Região do Semi-Árido UFERSA Mossoró, RN Brasil Abstract. Resumo. Este artigo apresenta uma proposta de protocolo de rede com relacionamento entre camadas(cross-layer) abrangendo as camadas MAC(Medium Access Control), roteamento e aplicação para redes de sensores sem fio(rssf). O protocolo proposto utiliza o esquema TDMA(Time Division Multiple Access) com intervalos de tempo de tamanho variáveis em conjunto com protocolo de roteamento por vetor de distância para operacionalizar do nós da rede, com o relacionamento com a camada de aplicação. Simulações numéricas apontam resultados significativos reduzindo o atraso fim-a-fim, o atraso médio da rede, como também favorecendo a escalabilidade da rede. 1. Introdução As redes de sensores sem fio (RSSF) são um tipo particular de rede nas quais pequenos dispositivos dotados de capacidades de sensoriamento e um transmissor de curto alcance, obtêm dados do meio ambiente e cooperam entre si usando comunicação multihop [Santi 2006] para encaminhar dados coletados a uma unidade central de processamento. As RSSFs são usadas de várias formas diferentes para monitorar lugares ou regiões onde a presença humana é impossibilitada ou indesejada. Sendo formadas por uma grande quantidade de nós, que possuem algumas reservas de energia. Geralmente são alimentados com pequenas baterias, têm pouca memória, e capacidade de processamento [Karl and Willig 2005]. Possuem limitações que impõem a essas redes a necessdade de que suas aplicações e protocolos seja otimizados para melhor utilizar seus recursos. Parte dos protocolos propostos para otimizar os recursos da rede são baseados em uma arquitetura de protocolos em camadas, a qual pode ser chamada de arquitetura tradicional [Santi 2006]. Por isso, são estudados para as RSSFs a criação ou melhoramento de protocolos que minimizem a utilização dos recursos dos nós, visto que protocolos tradicionais não são adequados [de Morais Cordeiro and Agrawal 2006]. Enquanto a arquitetura 46

51 em camadas pode conseguir alto desempenho analisando-as individualmente, ela não é otimizada para melhorar o desempenho da rede ao usar a energia e a taxa de transferência dos nós [Melodia et al. 2006] e reduzir a ineficiência causada pela sobreposição de camadas e adequar ao data-centric das RSSFs, entre outros fatores [Melodia et al. 2006]. Outros documentos estudam a interação entre camadas e mostram que o serviço da rede pode ser melhorado pela interação entre camadas. Esses trabalhos incluem aspectos como os impactos da camada física na camada de roteamento [Mahalik 2007, Zuniga and Krishnamachari 2004], e a interdependência da camada MAC e roteamento. Entre as camadas envolvidas, as camadas MAC e roteamento são as que mais foram exploradas [Mahalik 2007, Zuniga and Krishnamachari 2004, Ruzzelli et al. 2008, Van Hoesel et al. 2004, Li et al. 2008, Melodia et al. 2006, Cui 2005, Madan et al. 2005, Cui et al. 2005, Jurdak 2007, Zhao and Sun 2007, Ruzzelli et al. 2008] e conseguindo resultados favoráveis. Outras combinações envolvem MAC, transporte, controle de topologia e gerenciamento de energia [Mahalik 2007, Melodia et al. 2006, Jurdak 2007, Zhao and Sun 2007]. Dentre eles, em especial [Cui 2005, Li et al. 2008, Madan et al. 2005, Cui et al. 2005,Van Hoesel et al. 2004] mostram como protocolos de roteamento e protocolos MAC podem ser interligados. Embora os algoritmos cross-layer propostos pelos autores minimizem o consumo de energia nos nós, há outras métricas que devem ser observadas ao usar um protocolo de rede, tais como o atraso na camada de rede, interferência na camada MAC/Física. Além disso, a maioria destes trabalhos focaram seus estudos nas camadas de rede, no entanto, em RSSF a aplicação tem forte influência no design da rede. O objetivo deste trabalho é propor uma arquitetura cross-layer envolvendo as camadas de aplicação, roteamento e MAC. O relacionamento entre as camadas MAC e roteamento é feito com completa união de funcionalidades e a camada de aplicação é integrada também por compartilhamento de informações. Além disso, são analisados os impactos dessas interações sobre o atraso médio da informação da origem ao destino por meio de simulações numéricas. O restante do artigo está organizado como a seguir: a Seção 2 descreve a arquitetura de componentes envolvida no cenário de rede estudado, e como é feita a interação entre as camadas. Na Seção 3 são mostrados os resultados obtidos nas simulações. As conclusões e trabalhos futuros são apresentados na Seção Arquitetura A aplicação e os dados são a parte mais importante na construção de uma RSSF. Os nós são projetados para servirem ao propósito de prover informação. Neste trabalho divide-se as funcionalidades de um nó em duas categorias: arquitetura do nó, representando características do nó que influenciam nos dados gerados, e a arquitetura de rede representando os protocolos Arquitetura do nó Considera-se que o consumo de energia no nó sink pode ser desprezado e além disso esse nó nao gera informação na rede. Todos os outros nós geram informação e podem ser utilizados para encaminhar dados para o sink. 47

52 Pode-se dividir as tarefas executadas pelos nós em três categorias principais: estados dos nós, tarefas da aplicação e tarefas de rede. Todas as tarefas podem ser vistas na Figura 1. Os estados dos nós representam o modo de operação em que um determinado nó pode ser encontrado na rede. Pode-se dizer que há apenas três estados: Ativo No estado ativo o nó está ligado e executa tarefas diversas sejam de rede ou da aplicação, todos os circuitos estão ligados. Por isso, não deve permanecer nesse estado pois se trata do estado de maior consumo de energia, no entanto não pode ser evitado. Então, o nó deve de tempos em tempos mudar para um estado de menor consumo. A essa periodicidade dá-se o nome de ciclo de trabalho; Dormência Todos os nós devem permanecer neste estado a maior parte do tempo, pois representa o estado em que a energia é conservada. Inativo Estado em que o nó tem toda sua energia gasta e não mais pode ser aproveitado devendo ser descartado. Por se tratar de um estado em que o nó se torna inutilizado, foi excluído da Figura 1. As tarefas de aplicação representam os estados em que pode-se encontrar uma aplicação, as duas principais são: Ler dados do sensor e agregar dados(opcional). As tarefas de rede distribuem os dados obtidos, no caso de RSSFs realizam o trabalho de comunicação entre os nós, sendo que se representa essas tarefas como pertencentes a qualquer camada de rede. As tarefas de rede são basicamente os estados de TX(Transmissão), RX(Recepção) e Dormência(Sem tráfego). Dessa forma, de acordo com estados citados, pode-se afirmar que o ciclo de trabalho do nó deve ser o mais longo possível e dentro das limitações impostas pela aplicação. Então, afirma-se que o relacionamento entre as tarefas de rede e as tarefas de aplicação em conjunto com os estados de um nó de forma organizada evita desperdício de energia causado por instantes de tempo em que o nó permanece no estado ativo e ocioso, ou o desperdício causado por mudanças de estado desnecessárias. Estados do nó Estado Ativo Tarefas da Aplicação Lendo dados do Sensor Agregação (Opcional) RX Tarefas de Rede Roteamento e MAC Dormência do rádio Estado de dormência Portanto, a forma otimizada de economizar energia baseia-se em um desenvolvimento Figura 1. Arquitetura do nó. conjunto das camadas de aplicação, roteamento e MAC, como forma de evitar o consumo desnecessário que há quando se usa a tradicional arquitetura em camadas Arquitetura de rede: camadas MAC e roteamento Neste trabalho apresenta-se uma abordagem cross-layer, envolvendo as camadas de aplicação, roteamento e MAC, usada para melhorar a qualidade de serviço oferecida pelas tarefas de rede mostradas na Figura 1. Nessa abordagem é usado um esquema TDMA com intervalos de tempo variáveis. As motivações para a proposta desse esquema são baseadas em observações feitas em típicas topologias de rede para RSSFs. TX 48

53 0 1 2 EPOCA'09 - Escola Potiguar de Computação e suas Aplicações Nó Sink {... } N-2 Nós atuando como encaminhadores Nó na borda da rede N-1 Figura 2. A topologia String. Figura 3. Cenário das ligações entre os nós Sink A rede pode ser segmentada para simplificar a análise de cada caminho de roteamento. Por exemplo, o caminho formado pelos nós hipotéticos Sink Estes nós formam um caminho conhecido com topologia string, mostrado na Figura 2. Com essas duas topologias é possível observar que: nós próximos ao sink necessitam trafegar mais dados do que nós distantes, pois são usados como roteadores para os outros nós; devem estar no modo Ativo por mais tempo, ou seja, ter um ciclo de trabalho menor; são afetados por níveis de interferência maiores e um algoritmo do tipo vetor de distância pode ser utilizado para formar os caminhos de roteamento. Na abordagem proposta usa-se um modelo TDMA como meio para evitar interferência entre nós vizinhos. Contudo propõe-se a utilização de um modelo TDMA com intervalos de tempo de tamanhos variáveis para que nós mais próximos do sink tenham tempos maiores do que nós afastados. E além disso, o tamanho do intervalo de tempo é usado como peso pelo algoritmo de roteamento para formar rotas. Mais especificamente propõe-se que o tamanho do intervalo de tempo t seja distribuída de forma ordenada para que seja maior nos nós vizinhos ao sink e seja decrescente conforme a distância deste em número de saltos, ou hops, indicando assim o quão distante um nó está do sink. A cada nó, como por exemplo na topologia string, do tamanho do intervalo de tempo t, é subtraído um valor d representando a existência de mais um salto na comunicação deste nó. O valor d pode ser calculado como n(b/p) < d < c/m, (1) Em que: n é o número máximo de nós esperado em cada segmento de rede, ou seja, organizando a rede como árvore n é o número de nós de galho; b é a taxa de transferência entre dois nós; p é o tamanho máximo do pacote de dados; c é o tamanho máximo do ciclo TDMA; e m é o número máximo de vizinhos que um nó pode aceitar rotear dados. Como exemplo, na topologia formada pelos nós Sink na Figura 2 é possível ter o cenário mostrado na Figura 3. Portanto, no algoritmo proposto as camadas MAC e roteamento devem ser unidas em uma só, o que é conhecido como desenvolvimento conjunto por completa união de funcionalidades Arquitetura de rede: relacionamentos com a camada de aplicação Nos protocolos de rede pode-se ver o relacionamento entre cross-layer, mas a aplicação é também ser relacionada com as camadas de MAC e roteamento. Esse relacionamento é mostrado na Figura 4 que ilustra o ciclo de trabalho da aplicação, diferente do ciclo das camadas de rede e MAC. Isto tem impacto importante no atraso, que desde que a 49

54 Figura 4. Comparação entre ciclos de trabalho da aplicação e de rede. Figura 5. Tarefas de aplicação sincronizadas com as de rede. informação foi gerada até o tempo no qual ela chega ao seu destino. É importante notar que podem haver vários períodos em que os nós mudam seu estado para Ativo, para tarefas da aplicação e para as tarefas de rede. Por isso, na abordagem proposta, a camada de aplicação é sincronizada com as camadas de roteamento e MAC de modo que antes de executar as tarefas de TX/RX a aplicação realiza suas atividades e somente então são executadas as tarefas de rede. Então, o ciclo de trabalho proposto fica como, por exemplo, na Figura 5. Neste caso a aplicação flexibiliza seus tempos de execução de tarefas para se adaptar ao melhor tempo, no qual as outras camadas também estarão prontas a executar, aproveitando assim um único tempo em que o nó permanece Ativo. 3. Resultados Para avaliar o modelo proposto é implementado o algoritmo usando o simulador de eventos discretos OMNET++ [omn 2009] com o Mobility Framework. Nessas simulações numéricas obtêm-se o atraso e a escalabilidade como parâmetros de avaliação dos resultados. Nas simulações, todos os nós,exceto o sink, são fontes de eventos que são gerados por períodos regulares, chamados de periodicidades. Após gerado um evento, a aplicação encaminha imediatamente os dados a serem transmitidos. Nas simulações é usado os seguintes parâmetros: Tempo total de simulação: 360 segundos; Periodicidade: 4 segundos; Simula-se um radio transmissor de b = 25kbps; Número de saltos na rede variando de 3 a 12 saltos, organizados em uma topologia String; Tamanho de pacotes da camada de aplicação de p = 64bits; Número máximo de nós em um segmento de rede n = 15; Número máximo de vizinhos que um nó poderá rotear m = 5; Tamanho de um ciclo TDMA c = 2.1 segundos; Para comparar com o modelo proposto também é implementada uma abordagem de MAC baseada em TDMA e roteamento baseado em vetor de distância, chamado de tradicional, porém sem nenhuma interação entre camadas e com os mesmos parâmetros de simulação. Os resultados mostram um ganho perceptível no atraso e sem perder a escalabilidade, conforme mostrado na próxima Sub-seção. Nas simulações realizadas não se considera a sincronização entre os nós, assumese que todos os nós têm o mesmo clock. 50

55 Figura 6. Atraso em uma rede de 6 hops sem interação entre camadas. Figura 7. Atraso em uma rede de 6 hops com interação entre camadas Análise do atraso Dentro do modelo de rede descrito, obtiveram-se resultados que auxiliam a validar a abordagem proposta. O primeiro resultado a ser analisado é o crescimento do atraso conforme o nó distancia-se do nó sink. Na Figura 6, que mostra o atraso médio dos nós usando a abordagem tradicional, e Figura 7, que é baseada nos resultados obtidos com a abordagem apresentada. Pode-se então comparar os resultados. Nota-se que os resultados sugerem que a utilização da abordagem com interação entre camadas diminui o atraso. Acredita-se que o atraso médio na abordagem com relacionamento entre camadas é diminuído por causa do desenvolvimento conjunto com as camadas de rede. Um outro ponto que contribui para os melhores resultados é a configuração dos intervalos de tempo na camada MAC que são organizadas para que nós à distância n + 1, em número de saltos, do nó sink tenham sua oportunidade de transmitir para os próximos saltos, à distância de n, imediatamente antes de que esses nós tenham sua oportunidade de transmitir para os respectivos próximos saltos, à distância n 1. Reduz-se assim o tempo em que uma mensagem passa armazenada em memória antes de ser transmitida Análise da escalabilidade Para analisar a escalabilidade da abordagem proposta, aumenta-se o tamanho da rede para averiguar se os resultados se mantêm estáveis. Para isso, analisa-se simulações com número de saltos variando de 3 a 12 dentro da topologia da rede. Para essa avaliação utiliza-se duas métricas importantes: o atraso médio das mensagens de todos os nós da rede e o atraso dos nós mais distantes do sink. Os resultados são mostrados nas Figuras 8 e 9. Novamente analisando os resultados nota-se que o ganho dado usando a abordagem com interação entre camadas se mantém conforme a rede cresce em número de nós. Isso se deve ao fato que em qualquer ponto da rede um nó à distância n do nó sink, sempre realiza as respectivas tarefas antes do nó n 1. No entanto, como descrito anteriormente na formulação da Desiguladade 1 há uma limitação da quantidade de nós que podem fazer parte da rede e por conseguinte no número máximo de saltos. Contudo, há na literatura algoritmos baseados em clusters que isolam porções da rede formando sub-redes. Todavia, a própria abordagem pode ser 51

56 Figura 8. médio Comparação do atraso Figura 9. Comparação do atraso das mensagens dos nós mais distantes do sink. usada como algoritmo de formação de clusters assimilando que o nó sink neste caso seria um cluster head, tornado assim essa abordagem interessante para a delimitação da área do cluster. 4. Conclusão e trabalhos futuros A arquitetura de protocolos em camadas vem sendo utilizada e com sucesso há tempos na área de redes de computadores. As Redes de Sensores Sem Fio representam um novo paradigma para as redes em geral, pois nesse sub-conjunto de redes protocolos eficientes devem ser usados para suprir as novas necessidades que surgiram. Neste artigo é abordada a construção conjunta de três camadas da pilha de protocolos tradicional. As simulações numéricas realizadas sugerem que o modelo com relacionamento entre camadas apresentado reduz de forma significativa o atraso referente à chegada da informação ao nó sink. Os resultados também sugerem que a composição entre as camadas de aplicação, roteamento e MAC pode melhorar o desempenho da rede não somente em métricas individuais mas também em métricas compostas. O modelo proposto mescla uma variante do protocolo TDMA com um algoritmo de vetor de distância. Um relacionamento mais próximo com a camada de aplicação mostram, em simulações, resultados melhores do que aqueles baseados na arquitetura tradicional. Como trabalhos apontados e não avaliados por esta pesquisa pode-se citar: o estudo desta abordagem como algoritmo para a formação, e delimitação de clusters, assim como também, a formulação de um algoritmo que use a otimização da abordagem com relacionamento entre camadas para o roteamento inter-cluster; estudo de modelos de sincronização visto que o modelo todo requer sincronismo. Referências (2009). OMNet++ community site. Cui, S. (2005). Cross-layer optimization in energy constrained networks. PhD thesis, Stanford University, Stanford, CA. Cui, S., Madan, R., Lall, S., and Goldsmith, A. (2005). Joint routing, MAC, and link layer optimization in sensor networks with energy constraints. In icc 2005, South Korea. 52

57 de Morais Cordeiro, C. and Agrawal, D. P. (2006). Ad Hoc & Sensors Networks Theory and applications. World Scientific. Jurdak, R. (2007). Wireless Ad Hoc and Sensors Networks-A cross-layer design perspective. Springer. Karl, H. and Willig, A. (2005). Protocols and architectures for wireless sensor networks. John Wiley & Sons, University of Paderborn, ALEMANHA. Li, L., Sun, L., Ma, J., and Chen, C. (2008). A receiver-based opportunistic forwarding protocol for mobile sensor networks. In The 28th International Conference on Distributed Computing Systems Workshops, pages Madan, R., Cui, S., Lall, S., and Goldsmith, A. (2005). Cross-layer design for lifetime maximization in interference-limited wireless sensor networks. In IEEE INFOCOM, pages Mahalik, N. P., editor (2007). Sensor Networks and Configuration, Fundamentals, Standards, Plataforms and Applications, chapter Cross-layer Designs. Springer. Melodia, T., Vuran, M. C., and Pompili, D. (2006). The state of the art in cross-layer design for wireless sensor networks. In Lecture Notes in Computer Science, volume 3883/2006, Berlin/Heidelberg. IEEE. Ruzzelli, A. G., O Hare, G. M. P., and Jurdak, R. (2008). MERLIN: Cross-layer integration of MAC and routing for low duty-cycle sensor networks. Ad Hoc Networks, 6(8): Santi, P. (2006). Topology Control in Ad Hoc and Wireless Sensor Networks. John Wiley & Sons, Pisa-Itlia. Van Hoesel, L., Nieberg, T., and Havinga, P. J. M. (2004). Prolonging the lifetime of wireless sensor networks by cross-layer interaction. IEEE Wireless Communications. Zhao, N. and Sun, L. (2007). Research on cross-layer frameworks design in wireless sensor networks. Third International Conference on Wireless and Mobile Communication, pages 50a 50a. Zuniga, M. and Krishnamachari, B. (2004). Analyzing the transitional region in low power wireless links. In First Annual IEEE Communications Society Conference on Sensor and Ad Hoc Communications and Networks, pages IEEE. 53

58 Heterogenous e Camaleão: Gestão e Difusão Contínua do Conhecimento para Desenvolvimento de Softwares em Ambientes Heterogêneos Fábio Ribeiro Silvestre*, Girlene de Oliveira Barreto**, Joseane Pereira Santos** *Serviço Federal de Processamento de Dados (SERPRO) Cep: Salvador BA Brasil **Centro Universitário da Bahia (FIB) Cep: Salvador, BA Brasil Abstract. Software Engineering has always played an important role in organizations since its objective is to guarantee software quality. However, there is still little availability or inefficiency in software developing tools which can automatically guarantee structural or semantic quality of the final product. The "Heterogenous" application and "Camaleão" framework bring a proposal for automatic control of software structures using continued management and diffusion of knowledge. Doing so they guarantee that geographically dispersed teams can exchange knowledge and keep the same developing standards. Resumo. A engenharia de software sempre desempenhou um papel muito importante nas organizações com o objetivo de garantir a melhor qualidade do software a ser produzido. Entretanto, observa-se ainda a pouca disponibilidade ou a ineficiência de ferramentas voltadas ao desenvolvimento de software que possam garantir, de forma automatizada, a qualidade estrutural ou semântica do seu produto final. A aplicação Heterogenous e o framework Camaleão trazem uma proposta para o controle automático das estruturas de softwares utilizando a gestão e difusão contínua do conhecimento, garantindo que equipes dispersas geograficamente possam trocar conhecimento e manter seus padrões de desenvolvimento. 1. Introdução A gestão e difusão do conhecimento tecnológico nas empresas e organizações são de grande importância durante a transferência de tecnologias entre equipes de desenvolvimento de software envolvidas neste contexto. A carência de ferramentas para difusão da estrutura de tais tecnologias e a dificuldade de se manter a qualidade do software, com a perda das pessoas que detêm o seu domínio, denotam a necessidade da construção de um ambiente que seja capaz de gerenciar e difundir este conhecimento (Vieira,1993; Prates 2004; Carvalho 2006). Existem algumas premissas da engenharia de software que dizem que o custo para se manter a qualidade de um software mal estruturado é tão alto que às vezes tornase mais viável criar um novo do que manter o atual. Não é incomum o fato de que 54

59 alguns softwares acabem perdendo seus padrões de desenvolvimento ao longo do tempo, devido ao fato do conhecimento sobre a tecnologia utilizada não ter sido armazenado e nem automatizado (Pressman, 2006). Outro fator a ser considerado é a necessidade de desenvolvimento de softwares a curto prazo. A grande demanda por softwares cada vez mais complexos e com prazos cada vez mais curtos tem comprometido o aumento da produtividade do desenvolvedor, o que pode ser solucionado através da construção de softwares utilizando técnicas de reutilização, como por exemplo, o framework, que surgiu para facilitar o reuso de softwares e resolver problemas antes solucionáveis somente através de bibliotecas de procedimento, de funções ou de classes (Landin, 1995; Mattsson, 1996; Johnson, 1998; Pressman, 2006). Atualmente, o investimento em tecnologias de frameworks para desenvolvimento de software utilizando linguagens de programação como PHP, Java ou.net tem sido muito grande, mas muitas empresas não fazem alguns questionamentos que são de grande importância. Alguns frameworks estão se tornando facilmente obsoletos com o tempo, mas muitos outros softwares já foram desenvolvidos com sua utilização. Entretanto, quem garantirá a perpetuação deste conhecimento tecnológico, que é tão novo, por se tratar de uma tecnologia recente (i.e. framework), e ao mesmo tempo tão antigo, já que muitos frameworks estão se tornando obsoletos com o tempo? Quem garantirá a transferência deste sucateamento de tecnologias de frameworks utilizadas dentro da organização? Por isso, é importante que as empresas ou organizações não se preocupem somente com a transferência de conhecimento para as tecnologias velhas, mas que se preparem também para um possível sucateamento das tecnologias novas atualmente utilizadas (Vieira, 1993; Prates, 2004; Carvalho, 2006). A fim de atender tais necessidades, desenvolveu-se o framework Camaleão que tem como propósito a realização da gestão e difusão do conhecimento tecnológico, durante todo o processo de desenvolvimento de software em organizações que utilizem diferentes estruturas de desenvolvimento. Aliado ao Camaleão criou-se também uma aplicação denominada Heterogenous, para conceber o repasse de tecnologias de bancos de dados heterogêneos entre equipes de software distintas, que podem pertencer ou não a um mesmo grupo. As informações sobre o banco de dados, cujos metadados serão lidos para verificação e validação de sua estrutura, deverão ser cadastradas e poderão ser agendadas para uma gestão contínua do conhecimento, onde os indivíduos envolvidos poderão receber relatórios periódicos sobre o desenvolvimento do software construído pela equipe. O objetivo geral destas ferramentas é o de manter a qualidade do software ao longo do tempo, utilizando o framework Camaleão para a difusão contínua e automática do conhecimento, de acordo com as características de desenvolvimento de cada equipe e durante o uso de bancos de dados heterogêneos na construção de softwares de uma organização. As informações sobre o software que estará sendo construído deverão ser armazenadas em um repositório de dados e verificadas periodicamente, garantindo com isso que o desenvolvimento não fuja dos padrões estabelecidos e possibilitando que as 55

60 equipes envolvidas recebam informações sobre o conhecimento técnico e estrutural do software através de s, que serão enviados automaticamente caso ocorra algum desvio. A aplicação Heterogenous foi desenvolvida para gerenciar e difundir o conhecimento, dentro da engenharia de software, para os indivíduos que exercem os papéis de arquiteto de software, administrador de dados e administrador de banco de dados, em ambientes heterogêneos. Pela complexidade das atividades realizadas por cada um dos três papéis descritos acima, decidiu-se iniciar, neste trabalho, a gestão e difusão do conhecimento para o papel exercido pelo administrador de dados, deixando as atividades dos demais papéis como proposta de trabalhos futuros. A idéia da utilização destas ferramentas é também a de fomentar a gestão e difusão do conhecimento através da socialização entre as equipes, além de despertar a análise crítica de cada indivíduo durante o desenvolvimento do software na organização. 2. Gestão do Conhecimento no Heterogenous A gestão do conhecimento no Heterogenous se inicia através de cadastro de usuários, equipes e grupos de desenvolvimento de software e tem como objetivo principal a gestão e difusão do conhecimento tecnológico entre equipes de desenvolvimento de software distintas, principalmente durante o repasse de tecnologia entre elas. Quando uma equipe for desenvolver um determinado software, ela informa ao Heterogenous como esse deve funcionar ou se estruturar, e a partir daí, os seus integrantes começam a receber relatórios de erro, caso fujam da realidade descrita pela própria equipe durante o desenvolvimento do software em questão. A idéia do Heterogenous é fazer com que o produto final seja concebido de forma nova, evitando o seu envelhecimento precoce ao longo do tempo. A grande contribuição do Heterogenous está em fazer com que o conhecimento sobre o desenvolvimento do software não seja esquecido, principalmente quando suas informações estão distribuídas em diversos repositórios ou sistemas de arquivos dentro da organização, possibilitando com que os desenvolvedores de software utilizem suas estruturas de implementação, sem precisar abrir dezenas de documentos. Diante das constantes mudanças tecnológicas e da freqüente troca entre equipes que passam a implementar um mesmo software através de gerações, manter a sobrevivência do mesmo passa a ser uma tarefa, às vezes, muito onerosa para as organizações. Muitas vezes, o custo com a manutenção de um software sem qualidade passa a ser tão alto que é preferível reconstruir o software antigo, do que mantê-lo. Por isso, a aplicação Heterogenous visa manter a qualidade do software desenvolvido, desde a sua concepção e durante o seu ciclo de vida, reduzindo gastos que poderão ser redirecionados para outros fins. Após o cadastro dos grupos, equipes e usuários de software, o Heterogenous disponibilizará uma interface gráfica para cadastro das informações sobre o banco de dados alvo. Este banco de dados irá armazenar os metadados do software construído e geralmente são gerados a partir de ambientes de desenvolvimento de scripts de linguagem de banco de dados. Portanto, o Heterogenous não armazena os metadados 56

61 disponibilizados pelos bancos de dados alvo, ele apenas os recupera para análise, processamento e geração de relatórios de erros e avisos. Umas das informações importantes que devem ser fornecidas ao Heterogenous são os dados sobre a conexão com banco de dados alvo, que serão utilizados para que o framework Camaleão possa se conectar a fim de recuperar e analisar seus metadados (Korth, 1999; Date, 2000). As conexões dos bancos de dados alvo armazenadas estão sempre associadas a uma equipe que possui um conjunto de desenvolvedores de software. Durante a transferência de tecnologia para uma outra equipe distinta, as características previamente definidas são automaticamente repassadas, podendo ser modificadas a qualquer momento. Após a criação da conexão do banco de dados alvo e de sua nomenclatura, deve-se associá-las para que o framework Camaleão possa analisar o padrão criado pela equipe. O Heterogenous também terá a funcionalidade de realizar agendamentos futuros e periódicos para o banco de dados alvo informado, solicitando o dos integrantes das equipes que participam do desenvolvimento do software. A análise dos bancos de dados alvo poderá ser realizada no Heterogenous a qualquer momento ou através de agendamentos, mas o objetivo principal será sempre o de manter as equipes atualizadas com a estrutura de desenvolvimento adotada, desde a equipe que construiu o software até a que o mantém nos dias atuais. Os componentes das equipes poderão receber constantemente relatórios contendo avisos e erros encontrados, mostrando desde desvios estruturais à informações sobre flexibilidade ou portabilidade do produto que está sendo desenvolvido. 3. Conclusão A importância da gestão do conhecimento tem crescido bastante nas empresas como uma forma de manter a informação sempre atualizada e disponível entre seus funcionários. Fomentar a gestão do conhecimento significa também tentar manter o capital intelectual da organização sempre atualizado entre seus integrantes, disseminando o conhecimento, da própria organização, de forma contínua e colaborativa entre seus empregados, durante diversas gerações. Com uma ferramenta de gestão de conhecimento, os chamados especialistas das organizações poderão ser substituídos, de uma forma mais tranquila, sem gerar um alto custo com a transferência de conhecimento, pois o Heterogenous irá gerenciar e difundir constantemente as informações tecnológicas sobre as estruturas de software utilizadas ou desenvolvidas. No Heterogenous, o arquiteto de software, o administrador de dados e o administrador de banco de dados terão boa parte dos seus papéis automatizados, podendo se preocupar com outras questões técnicas e estruturais mais complexas. O alto custo com as revisões por par, que às vezes precisam de muitas análises e validações, é um dos exemplos onde a aplicação Heterogenous irá ajudar bastante, pois as avaliações de desenvolvimento da estrutura e arquitetura de software já estarão automatizadas. 57

62 Com a melhoria da qualidade dos softwares, os analistas de desenvolvimento irão atender de forma mais ágil às solicitações demandadas pelo cliente e o custo total investido pela empresa com a construção ou manutenção de softwares também poderá diminuir consideravelmente. O Heterogenous, através de seus relatórios de erros e avisos, irá estimular a análise crítica das equipes de trabalho, durante o desenvolvimento de software, além de gerar questionamentos sobre as estruturas de softwares definidas, estimulando os integrantes de cada equipe a melhorá-las ou adequá-las constantemente. As conseqüências poderão ser muito positivas, uma vez que as discussões, em prol de estruturas melhores, irão promover a socialização entre os integrantes das equipes, ou até mesmo entre os integrantes de outras equipes, para a busca de novos conhecimentos e experiências. Com a aplicação Heterogenous, através do framework Camaleão, as equipes de desenvolvimento não terão a imposição de nenhum padrão de conhecimento específico para sua estrutura de software, mesmo porque um dos objetivos principais do Camaleão é o de se adaptar facilmente às idéias e estruturas de conhecimento de qualquer equipe de desenvolvimento. 4. Trabalhos Futuros O objetivo do framework Camaleão é o de se adaptar a ambientes heterogêneos, de acordo com a necessidade de cada organização, promovendo a gestão e difusão do conhecimento para melhoria da qualidade durante a implementação de softwares. Neste trabalho, o framework Camaleão e a aplicação Heterogenous se propõem a demonstrar a utilização da gestão e difusão contínua do conhecimento durante o desenvolvimento de softwares utilizando banco de dados heterogêneos. Embora desenvolvido inicialmente para se adaptar a estruturas de bancos de dados heterogêneos, o objetivo é ampliar o escopo atual do Camaleão para se adaptar também a linguagens de programações distintas e a administração de bancos de dados distintos. Como proposta para trabalhos futuros, sugere-se a ampliação do Camaleão para gestão e difusão contínua do conhecimento em estruturas de software (e.g. camadas de softwares, nomes de métodos em camadas de softwares, et al.) utilizando linguagens de programação distintas (i.e. Java, PHP,.Net, et al.). Além disto, propõe-se também a ampliação do Camaleão visando atender a gestão e difusão contínua de conhecimento durante a administração de banco de dados heterogêneos, principalmente no que tange a otimização e alocação de recursos de hardware utilizados durante o desenvolvimento de softwares. A idéia é que o Camaleão, no futuro, possa fazer a gestão e difusão do conhecimento de software em três níveis: Na arquitetura de software, utilizando linguagens de programação heterogêneas (Arquiteto de Software); Na estrutura de desenvolvimento de scripts de bancos de dados heterogêneos, foco deste trabalho (Administrador de Dados); Na administração de bancos de dados heterogêneos (Administrador de Banco de Dados). 58

63 O trabalho atual fez apenas uma abordagem parcial ao software Heterogenous, utilizando o framework Camaleão, onde a gestão e difusão contínua do conhecimento foi focada apenas para a estrutura de desenvolvimento de scripts em banco de dados heterogêneos, buscando diminuir o trabalho exercido pelo administrador de dados, durante o desenvolvimento de softwares. Por se tratar de um trabalho denso e complexo, o desenvolvimento do Camaleão e do Heterogenous focou-se inicialmente no nível de administração de dados, deixando os outros níveis como propostas de desenvolvimento em trabalhos futuros. Referências Carvalho, I. M. de; Mendes, S. P.; Veras, V. M. (Org). Gestão do Conhecimento: uma estratégia empresarial. Brasília, DF: Serpro, Date, C. J. (Ed.) Introdução a Sistemas de Bancos de Dados. Trad. 7a Ed.Americana. Rio de Janeiro: Ed. Campus, Johnson, R.; Foote, B. Designing Reusable Classes. Journal of Object-Oriented Programming, Korth, H. F.; Silberchatz, A.; Sudarshan, S. (Eds.) Sistemas de Bancos de Dados. 3ª Edição. São Paulo: Makron Books, Landin, N.; Niklasson, L. Development of Object-Oriented Frameworks, Mattsson, M. Object-Oriented Frameworks - A survey of methodological issues. Tese de Doutorado. Lund University. Ronneby, Suécia, Prates, Denis Novaes. Knowlegde Management - Expondo e Discutindo a Gestão do Conhecimento. Revista Técnica IPEP, São Paulo, SP, v. 4, n. 2,p , jul./dez Pressman, Roger S. Engenharia de Software 6ª Edição São Paulo: McGraw-Hill, Vieira, Anna da Soledade. Conhecimento como Recurso Estratégico Empresarial. In: Seminário de Integração de Redes da Região Norte, Manaus, 1993 s.l.: s.n.,

64 Um Jogo Eletrônico para a Educação Ambiental Anderson S. de Oliveira 1, Angélica F. de Castro 1, Flávia Estélia S. Coelho 1 1 Grupo de Pesquisa em Informática Aplicada à Educação e ao Meio Ambiente (GRIPEM) - Departamento de Ciências Exatas e Naturais (DCEN) Universidade Federal Rural do Semiárido (UFERSA) BR Km 47 - Bairro Presidente Costa e Silva Mossoró RN Brazil Abstract. This paper proposes a playful alternative for complementing the learning in environmental education. It presents a model for an electronic game where students must apply their knowledge in practical situations in environmental management. Resumo. Este artigo propõe uma alternativa lúdica para complementar o ensino e aprendizagem da educação ambiental através de um jogo eletrônico que confronta os conhecimentos adquiridos pelos alunos à situações práticas de gestão ambiental. 1. Introdução A educação ambiental é de substancial relevância para o desenvolvimento sustentável do Brasil. Nesse sentido, os cidadãos devem ter uma formação que os permita compreender suas responsabilidades e a importância de ações em favor do meio ambiente. Considerando o ensino fundamental e médio, os professores precisam dispor de recursos didáticos que atraiam a atenção dos estudantes, reforçando o exercício do senso de preservação da natureza e da adequada integração entre sociedade e meio ambiente. Um programa de educação ambiental para ser efetivo deve promover simultaneamente, o desenvolvimento do conhecimento, de atitudes e habilidades necessárias à preservação e melhoria da qualidade ambiental. Idealmente, a educação ambiental deve estar contextualizada de acordo com a realidade da comunidade: o Brasil possui um território de extensão continental, que contempla uma variabilidade geográfica e biodiversidade extraordinárias o material didático e de suporte devem levar esses elementos em conta, permitindo aos professores moldarem os desafios propostos aos estudantes, de acordo com as características regionais. O aprendizado adapta-se à experiência de cada estudante. À medida que o estudante avança novas atividades devem incentivá-lo a aplicar o conhecimento adquirido, de maneira a fixar o conteúdo e assim alterar o seu comportamento, de modo positivo. Em resumo, a aprendizagem será mais efetiva se a atividade estiver adaptada às situações da vida real do meio em que vivem estudantes e professor. Neste trabalho, é apresentado o modelo conceitual de um jogo eletrônico voltado ao ensino da educação ambiental no ensino médio. O jogo consiste em uma série de missões que, se cumpridas com sucesso, fazem com que os estudantes acumulem pontos, ao passo que aplicam os conhecimentos adquiridos ao lidarem como problemas específicos. Uma missão pode ser, por exemplo, propor ações para a redução do uso de recursos naturais tais 60

65 como fontes de água e de energia (eletricidade e combustíveis) em uma cidade - tarefa que exige um nível de compreensão básico em termos de preservação do meio ambiente. Os pontos acumulados por cada estudante, em uma ou mais partidas, podem servir de base para avaliação, por parte do professor. Afinal, quanto mais pontos acumulados, mais técnicas e ações benéficas para o meio ambiente o estudante foi capaz de compreender e de aplicar. O jogo é baseado na Internet: os professores podem selecionar cenários e missões que julgarem mais interessantes e relacionados tanto com a paisagem geográfica de sua região, quanto com o nível de escolaridade de seus alunos. Os estudantes, por sua vez, têm um acesso diferenciado: eles controlam um personagem que age administrando um bairro ou até uma cidade ou região inteira. As características próprias do jogo, o definem como uma alternativa complementar de ensino e de verificação de aprendizagem no que se refere ao tema preservação do meio ambiente. Nas seções seguintes, descrevem-se a justificativa e fundamentação da proposta (Seção 2), o modelo conceitual do ambiente para (Seção 3), um exemplo de missão (Seção 4), a indicação de tecnologias computacionais a serem utilizadas (Seção 5) e, por fim, algumas considerações finais (Seção 6). 2. Educação Ambiental e Jogos Educacionais Diante da consolidação do cenário urbano e da influência da tecnologia na sociedade atual, crescem a interferência nos ecossistemas, a redução de recursos naturais e os desequilíbrios ambientais, dadas constantes poluição, contaminação da água, devastação de florestas, entre outras formas de agressão ao meio ambiente. Ao contemplarmos o contexto brasileiro, em 2008, a sétima edição 1 da Pesquisa de Informações Municipais (Munic) apresentou números impactantes: 5040 municípios (90,6%) comunicaram a ocorrência de alterações ambientais. Destas, as queimadas (54,2%), os desmatamentos (53,5%) e o assoreamento de corpos de água (53%) sobressaem-se. São notórios os impactos provenientes de alterações ambientais à qualidade de vida da população e a atividades econômicas primárias. Por outro lado, apenas 33,3% desses municípios dispõem de recursos financeiros específicos para viabilizar ações ambientais, conforme afirma [IBGE 2008]. Em complemento, só 22,6% dos municípios têm Fundo de Meio Ambiente e, desses, somente 36,6% financiaram ações e projetos na área de meio ambiente, nos 12 meses anteriores. Em 2008, apenas 47,6% dos municípios tinham Conselho Municipal de Meio Ambiente (CMMA) - o que revela uma presença insignificante desse tipo de fórum, se comparado a outros conselhos tais como os de Saúde (98%), Assistência Social (93%) e Direitos da Criança e do Adolescente (77%). Sendo ativos, 70,9% dos CMMAs existentes. Um dos principais resultados do Munic diz respeito à constatação de que somente 18,7% dos municípios estão organizados, o suficiente, para enfrentar problemas ambientais, 1 Resultados mais recentes da pesquisa realizada pelo IBGE, até outubro de

66 isto é, possuem alguma estrutura, recursos específicos e fórum que proporcionem a elaboração, instituição e manutenção de políticas públicas ambientais. Diante desses fatos, é visível a necessidade de ações pró-ativas complementares que impulsionem o desenvolvimento sustentável, objetivando a formação de cidadãos conscientes de seu papel e responsabilidades para a gestão de recursos naturais e meio ambiente, a fim de propiciar a subsistência de futuras gerações. Nesse contexto, desde 1965, o termo "Educação Ambiental" vem sendo empregado e se consolidando, pois denota uma forma abrangente de educação baseada em um processo pedagógico participativo permanente, a fim de promover nos cidadãos, consciência crítica sobre problemas ambientais. Consciência essa, fundamentada na capacidade de compreender a origem e a forma de evolução de tais problemas - auxiliando assim, na busca por mudanças de comportamento das pessoas no que se refere ao meio ambiente. Na linha de iniciativas auxiliares, destacam-se os programas e ações da Secretaria de Educação Continuada, Alfabetização e Diversidade do Ministério da Educação (SECAD/MEC) para a Educação Ambiental; e, na área de Tecnologia da Informação, os softwares educativos tornam-se diferenciais significativos. Em particular, jogos educativos têm sido desenvolvidos, sob fomento de políticas públicas tais como o Rede Interativa Virtual de Educação (RIVED) e de propostas inéditas para mídias digitais voltadas para a educação, conforme afirma [Martins e Neves 2009]. Além disso, sabe-se que jogos favorecem a construção e re-organização da memória, atenção, criatividade, imaginação e percepção - o que potencializa o seu uso na educação, segundo [Alves 2005]. Portanto, com base nesses argumentos, os jogos educacionais "eletrônicos" podem ser considerados uma espécie de ferramenta que associam a utilização de mídias integradas (textos, animações, áudios, etc) e de recursos de tecnologia da informação que auxiliam no processo de ensino-aprendizagem. No tocante à Educação Ambiental, favorecem a capacitação de jovens (e futuros adultos) mais conscientes quanto ao uso racional de recursos do meio ambiente e ao desenvolvimento sustentável. Destaca-se, ainda, a utilização de jogos educacionais como alternativas complementares a ações públicas e a limitações enfrentadas em processos educativos tradicionais. 3. Definição do Jogo O jogo permite ao aluno visualizar uma representação de uma cidade em um mapa (que chamaremos também de cenário). A perspectiva do observador é a mesma adotada em jogos clássicos como SimCity e Warcraft. O mapa é o elemento central do jogo, e o jogador pode realizar ações tais como zoom in ou zoom out do mapa, selecionar, inserir ou destruir itens nele representados. Algumas das operações realizadas pelo usuário podem alterar o estado geral do jogo de forma ao fazê-lo receber ou perder pontos: aquelas que favorecem ou prejudicam o meio ambiente, respectivamente. Um mapa, ou cenário, é composto de várias camadas, contendo cada uma, itens do relevo (montanhas, planícies, etc.), da hidrografia (rios, lagos e oceano), da vegetação, e itens antrópicos (construções como ruas, avenidas, prédios, etc.). Essas características serão pré-configuradas no jogo, de acordo com uma das peculiaridades das regiões brasileiras. A Figura 1 apresenta um diagrama de classes simplificado que mostra algumas das principais entidades componentes do modelo do jogo. A maior parte dos atributos e operações foi 62

67 omitida por questão de espaço, porém aqueles listados transmitem a idéia central do modelo. Figura 1 - Diagrama de classes simplificado Inicialmente, o professor deverá selecionar um cenário que represente a realidade da região onde sua escola se situa. Por exemplo, teremos mapas representando cidades da região Amazônica, o Cerrado no Centro-Oeste, as cidades litorâneas e do semiárido no Nordeste, etc. Isto permite aplicar o jogo em uma grande diversidade de escolas em todo o país. O professor seleciona um modelo de mapa pré-existente e o atribui para uma de suas turmas. O jogo permite ainda estabelecer qual aspecto ambiental o professor deseja que seus alunos exercitem. Isto é feito através da determinação de uma missão a ser cumprida. Quanto mais ações relevantes para uma dada missão o aluno realizar, mais pontos ele irá acumular. O número de gestos que o jogador poderá realizar é limitado apenas pelo orçamento dedicado ao meio ambiente: cada demolição de item, como a destruição de uma indústria com grande emissão de gases de efeito estufa, e sua substituição por um parque, terá um reflexo sobre esse orçamento. Os alguns dos principais casos de uso previstos para o jogo estão representados na Figura 2 (a). 4. Exemplo de uma Missão Suponha que um professor tenha selecionado um cenário urbano e atribuído a missão "melhorar a qualidade do ar" para uma de suas turmas. Uma partida se inicia quando um aluno se conecta ao jogo e aceita a missão proposta. A partir desse momento, uma série de possibilidades se apresenta: itens podem ser inseridos através de uma lista de "equipamentos públicos verdes" (novamente, nos moldes do jogo SimCity), tais como parques, estações de tratamento de esgotos, usinas de reciclagem de lixo, ciclovias, etc. Por exemplo, o jogador pode escolher inicialmente a abordagem de diminuir a circulação de veículos automotores, através da inserção de novas estações de metrô nas áreas mais densas em construções da cidade - uma opção extremamente cara - e que promove uma ligeira melhoria da qualidade do ar [Azuaga, 2000]. Alternativamente, o jogador pode escolher aumentar a área verde nos arredores da cidade, ou mesmo substituir itens antrópicos por vegetação, como áreas de reflorestamento, parques, entre outras. O jogo pode ainda oferecer opções de limitar a circulação de certas ruas centrais no mapa somente à circulação de pedestres. 63

68 As interações com o jogador estão representadas no diagrama de seqüência da Figura 2 (b). A partir do evento 5, o jogador pode realizar uma série de ações de navegação no mapa e de operações de inserir e suprimir itens até que seu orçamento tenha se esgotado, ou que o tempo limite estabelecido para a missão (se imposto) tenha acabado. (a) (b) Figura 2 (a) alguns casos de uso do jogo e (b) diagrama de seqüência mostrando a interação do jogador com o sistema 5. Tecnologias Computacionais Utilizadas Uma tecnologia essencial nesse trabalho é o uso de Sistemas de Informações Geográficas (SIGs), que se destacam por armazenar mapas temáticos de uma área associados a uma tabela de dados, efetuando análises complexas, ao integrar dados alfanuméricos com dados geográficos de uma determinada área de estudo, através de um banco de dados georreferenciados. Possuem a capacidade de manipular dados espaciais (cartográficos, cadastrais, sensoriamento remoto e modelos numéricos de terreno) e dados não-espaciais (descritivos ou alfanuméricos), de forma integrada, provendo uma base consistente para análise e consulta [Câmara et al. 1996]. A criação deste jogo nos permitirá testar modelos de avaliação de impacto ambiental associados aos SIG s, por meio de simulações sobre modelos complexos que exigirão o domínio de técnicas de processamento paralelo e distribuídos e da manipulação de grandes massas de dados. O domínio dessas tecnologias é essencial para aumentar a velocidade e a confiabilidade nos resultados obtidos através de simulação. Em virtude da utilização crescente da Internet/Web e de suas características próprias, o jogo proposto baseia-se nesse serviço para disponibilizar um ambiente multimídia interativo online. Assim, é factível atingir estudantes geograficamente dispersos; efetuar a obtenção e a análise de dados a respeito do nível de aprendizagem dos estudantes; e permitir a interação em tempo real [Jungles e Battaiola 2006]. Sendo conveniente a investigação de uma gama de plataformas de desenvolvimento de jogos 64

69 baseados na Web, tais como o Flash, Java e o Silverlight, entre outras, a serem criteriosamente avaliadas com o propósito de garantir a qualidade final do produto e a facilidade de seu desenvolvimento, conforme argumenta [Araújo Jr. e Ramalho 2009]. 6. Conclusões e Perspectivas Espera-se com o desenvolvimento deste trabalho, disponibilizar um jogo que visa complementar o processo de ensino-aprendizagem de estudantes do ensino médio quanto a assuntos relacionados à preservação do meio ambiente e desenvolvimento sustentável. Particularmente, professores e estudantes poderão usufruir dessa alternativa lúdica em suas atividades de ensino e avaliação (para professores) e de aquisição do conhecimento e sua aplicação em contextos práticos (para estudantes). Salienta-se ainda a utilização da tecnologia da informação aplicada em iniciativas educacionais, por meio de assuntos multidisciplinares (computação distribuída, plataformas de desenvolvimento para Web, Sistemas de Informações Geográficas, entre outras tecnologias). Como trabalhos futuros, destacam-se a utilização do jogo proposto como base para pesquisas relacionadas à computação aplicada ao meio ambiente, tais como simulações sobre impacto ambiental, apoiando a tomada de decisões com respeito a problemas naturais e antrópicos. Referências Alves, L. R. G. (2005) Game Over: Jogos Eletrônicos e Violência, Futura. Araújo Jr., M. B. e Ramalho, G. L. (2009) "Um Estudo Comparativo de Tecnologias Web para Games", Trabalho de Graduação, Bacharelado em Ciência da Computação, Universidade Federal de Pernambuco. Azuaga, D. (2000) "Danos Ambientais Causados por Veículos Leves no Brasil", Tese, Universidade Federal do Rio de Janeiro. Câmara G., Casanova M., Hemerly A., Magalhães G. e Medeiros C. (1996). Anatomia de Sistemas de Informações Geográficas, Escola de Computação, IX. IBGE (2008) "Perfil dos Municípios Brasileiros 2008", Instituto Brasileiro de Geografia e Estatística (IBGE), Dezembro. Jungles, R. e Battaiola, A. L (2006) "Análise de Tecnologias para a Implementação de Jogos Web", V Brazilian Symposium on Computer Games and Digital Entertainment (SBGames). Martins, J. M. e Neves, I. B. C. (2009) "Políticas Públicas e o Desenvolvimento de Jogos Eletrônicos para a Educação", 19o Encontro de Pesquisa e Educacional do Norte e Nordeste (EPENN). 65

70 Computação Ubíqua: dos anos 90 ao século XXI Frederico Lopes 1, Jeferson Queiroga 1, Cláudio Lago 2, Thaís Batista 1, Flavia Delicato 1, Paulo Pires 1 1 DIMAp Universidade Federal do Rio Grande do Norte (UFRN) 2 UNP Universidade Potiguar do Rio Grande do Norte {fred.lopes, jefersonqueiroga, claudio.app, fdelicato, Abstract. Since the late 1980s - when the term Ubiquitous Computing was created - until now, this computing paradigm have been studied by many researchers. These studies has resulted in the development of various platforms (middleware and/or frameworks) that are designed to facilitate the development of ubiquitous applications. In this way, this article explores the maturation of ubiquitous computing, through three distinct phases, in view of the mode of development of such applications. The first phase is related to the pre-platform, the second consists in the period in which such platforms began to be proposed in order to facilitate the development of ubiquitous applications. The third phase, which is a current trend, is based in integrated environments, where applications using different platforms without becoming aware of them. Resumo. Desde o final da década de quando o termo Computação Ubíqua foi criado - até hoje, esse paradigma computacional vêm sendo objeto de estudo por muitos pesquisadores. Tais pesquisas tem resultado no desenvolvimento de diversas plataformas (middleware e/ou frameworks) que visam facilitar o desenvolvimento de aplicações ubíquas. Nesse caminho, esse artigo explora o amadurecimento da computação ubíqua, através de três fases distintas, na perspectiva do modo de desenvolvimento de tais aplicações. A primeira fase está relacionada ao período pré-plataformas, a segunda consiste no período em que tais plataformas começaram a serem propostas com o objetivo de facilitar o desenvolvimento de aplicações ubíquas. A terceira fase, que é uma tendência atual, consiste em ambientes integrados, onde as aplicações utilizam diversas plataformas sem tomar conhecimento da existência das mesmas. 1. Introdução O termo Computação Ubíqua foi usado pela primeira vez em [1], onde Mark Weiser apresentou seu conceito. Esse termo, também conhecido como Computação Pervasiva, tenta aproximar a realidade natural de uma sociedade à interação imperceptível e harmoniosa com os dispositivos computacionais. Esse conceito passa o real sentido da palavra, ubíqua, que tem o significado de algo que está ao mesmo tempo e em toda a parte. Algumas das principais premissas de uma aplicação ubíqua são: (i) Os computadores devem estar conectados por uma rede, distribuídos e a acessibilidade transparente; (ii) A interação homem-computador deverá ser invisível; (iii) As aplicações precisam ser sensíveis ao contexto para otimizar suas operações com o ambiente; entre outras. Nos anos iniciais da computação ubíqua, o desenvolvimento das aplicações era uma tarefa árdua uma vez que além dos requisitos funcionais, os requisitos não-funcionais, como acesso à diferentes tipos de sensores e transformação das informações sensoriadas eram de 66

71 responsabilidade dos desenvolvedores das aplicações, conforme explorado na seção 2. Esse fator determinante resultava em aplicações complexas do ponto de vista implementacional e, de um modo geral, resultava em aplicações bem específicas a um determinado domínio e de reusabilidade nula. Com o passar dos anos, vários frameworks e middleware foram surgindo com o intuito principal de facilitar o desenvolvimento dessas aplicações. Essas plataformas, que serão abordadas na seção 3, permitem que as aplicações tenham um maior foco nos requisitos funcionais, porém, a falta de interoperabilidade entre essas plataformas tem criado ilhas isoladas de dispositivos com protocolos não uniformes para prover interoperabilidade entre essas ilhas [2] uma vez que cada plataforma utiliza diferentes protocolos de comunicação e modos de representar as informações. Esse problema está motivando pesquisas com o objetivo de solucionar o problema da não interoperabilidade entre as plataformas de middleware. Propostas de mecanismos para prover esse nível de interoperabilidade têm sido publicadas nos últimos anos e serão abordadas na seção Primeira fase da computação ubíqua A primeira fase da computação ubíqua é marcada pela inexistência de plataformas para computação ubíqua. Desse modo, as aplicações além de implementarem as regras de negócios para as funcionalidades a que se propunha, eram sobrecarregadas pelas responsabilidades de aquisição e processamento das informações do contexto da aplicação. Isso tornava o desenvolvimento das aplicações mais complexo e promovia o acoplamento dessas aplicações às tecnologias de hardware que elas utilizavam. Por exemplo, para uma aplicação que se propunha a reconhecer quem são os indivíduos presentes num determinado ambiente, além de a aplicação ter uma base de dados e algum algoritmo de reconhecimento de pessoas (regras de negócios da aplicação) essas aplicações coletavam dados de sensores específicos de tal modo que se o sensor fosse trocado por outro de outro fabricante ou até mesmo a API do sensor fosse atualizada, a aplicação obrigatoriamente deveria ser atualizada também. Além disso, esse modelo no qual a aplicação estava diretamente ligada aos sensores e atuadores não promovia a reusabilidade das informações coletadas. Desse modo, se duas ou mais aplicações precisassem das mesmas informações adquiridas por um determinado sensor, todas elas deveriam pegar essas informações diretamente do sensor, fazendo que todas elas aplicações implementem a comunicação com esse sensor, tornando mais caro tanto o desenvolvimento quanto a manutenabilidade das mesmas. 3. Middleware para Computação Ubíqua Com o objetivo de fornecer um modelo de programação mais produtivo para os programadores de aplicações ubíquas, várias plataformas de middleware vêm sendo desenvolvidas. Através dessas plataformas de middleware, os desenvolvedores de aplicações ubíquas e consequentemente sensíveis ao contexto podem se preocupar apenas com as regras de negócio, pois as tarefas de aquisição, representação e raciocínio em cima de informações de contexto são de responsabilidade dos middleware para computação ubíqua. Então, boa parte do processamento de informações de contexto é realizada por essas plataformas e reduz-se a complexidade no desenvolvimento requerida para a interação com os sensores que realizam a coleta de informações contextuais. De um modo geral, os mecanismos são capazes de obter as informações de contexto do ambiente, representar essas informações de modo que as aplicações possam entender o significado das mesmas e ainda que raciocinem em cima dessas informações de contexto para que as informações coletadas possam ser transformadas em informações relevantes para as aplicações. A seguir são apresentados alguns exemplos de middleware: 67

72 3.1 Context Toolkit (CT) O framework Context Toolkit [3] foi elaborado para facilitar o projeto e a implementação de aplicações sensíveis ao contexto através da disponibilização de módulos préimplementados, onde uma aplicação é composta por um ou mais desses módulos, que devem ser configurados de acordo com as informações de contexto que cada um é responsável. Os módulos básicos que o CT disponibiliza são: Widget, Aggregator, Interpreter e Service. Cada Widget é responsável por receber o contexto capturado por ume sensor específico e tornar essas informações de contexto disponíveis para outros módulos e/ou aplicações. Aggregators são responsáveis em agrupar informações de contexto provenientes dos Widgets. Interpreters transformam informações de contexto de baixo-nível em informações de alto-nível. Services são responsáveis por representar abstrações de atuadores para executar ações para aplicações. O CT tem uma série de limitações, entre elas as principais são: (i) modelo de contexto utilizado é bastante arcaico, limitando assim o poder dos interpretadores de contexto; (ii) dependência à plataforma Java, onde as aplicações necessariamente devem ser implementadas nessa linguagem; (iii) não possui um mecanismo de tolerância a falhas. 3.2 SOCAM SOCAM [4] é um middleware que optou usar uma abordagem baseada em ontologias e serviços Web para prover as informações de contexto às aplicações. Em sua arquitetura, os Provedores de contexto são responsáveis por obter informações de contexto. Um provedor de contexto pode ser um provedor interno ou provedor externo. Os provedores internos são responsáveis por obter as informações através de sensores enquanto os provedores externos adquirem informações de contexto de fontes externas, como por exemplo, servidores remotos. O Service Locating Service é o repositório de serviços do SOCAM que permite que aplicações localizem diferentes provedores de serviços. O Context Interpreter tem o papel de prover serviços de inferência para processar informação de contexto e ser armazenado em um Context Database. Já os Context-aware Services, são as aplicações que utilizam a infraestrutura SOCAM e seus componentes para ter acesso às informações de contexto. As principais restrições do SOCAM são: (i) não provê suporte a mobilidade de dispositivos; (ii) não provê requisitos de qualidade de serviços, qualidade de contexto e de tolerância a falhas; (iii) não permite que serviços de contexto sejam compostos de forma automática, sendo a própria aplicação responsável por buscar as informações em cada serviço e compô-las. 3.3 MiddleWhere A plataforma MiddleWhere [5] é específica para prover informações de localização a aplicações sensíveis ao contexto, incorporando várias técnicas de sensoriamento de localização, e contém uma máquina de inferências para deduzir a localização com um alto grau de certeza. As principais restrições do MiddleWhere são: (i) é específico para informações de localização, tornando necessário o uso do mesmo em conjunto com alguma outra plataforma de middleware para computação ubíqua para satisfazer as necessidades de aplicações ubíquas mais complexas; (ii) essa plataforma não provê suporte a mobilidade; (iii) não é facilmente extensível; (iv) não contempla tolerância a falhas. 3.4 MUSIC O middleware MUSIC [6] provê suporte a aplicações para ambientes ubíquos com o objetivo de construir aplicações auto-adaptativas de acordo com as necessidades do usuário. 68

73 Para suportar a adaptação das aplicações, o MUSIC oferece composições abstratas como um conjunto de papéis colaborando entre si através de portas, representando assim as funcionalidades providas ou requeridas por um componente. Cada composição abstrata possui planos e cada um desses planos descreve a estrutura interna da composição através de papéis, portas e conexões entre elas. O MUSIC usa ontologias como modelo de contexto. Não obstante seja um middleware já bem mais completo, o MUSIC possui algumas restrições. São elas: (i) o MUSIC não provê mecanismos para conversão de informações de contexto baseados em modelos de contexto que não seja o modelo adotado pelo MUSIC; (ii) não suporta o tratamento de QoC na escolha dos serviços a serem utilizados e sim apenas de QoS, diminuindo a expressividade das aplicações no momento de requisitar informações de contexto. 3.5 Discussão As plataformas de middleware apresentadas acima têm basicamente o mesmo objetivo prover informações de contexto para aplicações ubíquas. Porém, como foi possível observar, elas não atendem a todos os requisitos exigidos para ambientes ubíquos altamente dinâmicos e heterogêneos. Por exemplo, algumas plataformas de middleware focam no tratamento de informações de contexto para prover ciência de contexto, enquanto que outros focam em prover ciência de localização e outros enfatizam no suporte a mobilidade. Desse modo, cada middleware adota sua própria representação de contexto, API para aquisição dessas informações e ainda diferentes tecnologias de comunicação. Para piorar, alguns middleware são específicos de domínio, por exemplo, enquanto que o middleware proposto em [7] é específico para aplicações focadas em casas inteligentes, os propostos em [8] e [9] são específicos para atender as necessidades de aplicações HealthCare. Desse modo, as aplicações ubíquas ainda possuem um forte acoplamento e dependência com os ambientes de middleware específicos subjacentes. Isso gera um problema conceitual uma vez que a computação ubíqua considera ambientes nos quais aplicações devem ser capazes de acessar informações de contexto originadas por diversas infraestruturas subjacentes espalhadas pelo ambiente, de modo que essas aplicações não precisam saber da existência dessas diversas tecnologias de middleware e suas especificidades [10]. A necessidade de lidar com as especificidades de cada plataforma de middleware viola o requisito de transparência e aumenta a complexidade no desenvolvimento das aplicações. 4. Tendências Atuais Para resolver os problemas apontados na seção anterior, alguns trabalhos [3, 11] começaram a apontar para uma solução interessante: a interoperabilidade entre plataformas de middleware para computação ubíqua. Prover interoperabilidade entre diversas plataformas que utilizam diferentes tecnologias sobre vários aspectos implementacionais diretamente entre si é uma tarefa árdua pois para n plataformas a serem integradas é necessário n x (n-1) módulos de integração, onde cada plataforma é interligada com as outras (n-1) plataformas. Desse modo, a estratégia mais viável de se prover essa integração parece ser através de uma infra-estrutura intermediária, que possibilite a integração de todos serviços de contexto existentes, providos por diferentes plataformas de middleware para computação ubíqua. Isso é particularmente importante para usuários móveis onde tipicamente as informações de contexto são disponibilizadas por diferentes ambientes [11]. Desse modo, esse tipo de infraestrutura visa facilitar o desenvolvimento das aplicações, possibilitando o uso de serviços de diversos provedores de forma totalmente transparente e tornando-as 69

74 independente do ambiente de distribuição e manipulação de informação de contexto subjacente. Um requisito essencial para essa infra-estrutura integradora é prover uma variedade de serviços de contexto com o objetivo de suportar múltiplas aplicações ubíquas simultaneamente. Para isso, é necessário que essa infraestrutura possibilite a publicação e descoberta de serviços de contexto em tempo de execução e ofereça um modelo de contexto padronizado. Além desses requisitos básicos, é importante que essa infraestrutura forneça tolerância a falhas para garantir que em caso de falha de algum serviço a aplicação possa utilizar outro equivalente, se possível. É importante ainda prover metadados sobre as informações de contexto, para garantir a qualidade das informações de contexto (QoC) usadas pelas aplicações. Considerando essa problemática, propomos o OpenCOPI (Open COntext Platform Integration), uma plataforma que integra vários middleware para computação ubíqua com o objetivo de prover um serviço de contexto unificado para tais aplicações. A arquitetura do OpenCOPI, detalhada em [12], é baseada em SOA (Service Oriented Architecture) e na tecnologia de Serviços Web, usando padrões e linguagens baseadas em XML. O uso de SOA permite que as funcionalidades sejam providas e consumidas como um conjunto de serviços descritos através de interfaces, independentemente de plataforma. De acordo com a abordagem SOA adotada no OpenCOPI, plataformas de middleware são provedores de serviço que fornecem informações de contexto às aplicações clientes. O OpenCOPI provê: (i) um modelo de contexto unificado e baseado em ontologias, bem como o suporte para converter as várias representações de contexto adotadas pelas diferentes plataformas de middleware. Devido a essa característica, a aplicação precisa conhecer apenas o modelo de contexto unificado; (ii) um mecanismo de composição de serviços que permite a composição de serviços de contexto providos por diferentes middleware para suprir as necessidades das aplicações; (iii) a capacidade de expor todos os middleware de provisão de contexto como serviços Web, sejam ou não baseados nessa tecnologia. No caso de não serem baseados em serviços Web, o OpenCOPI provê mecanismos para conversão. De acordo com a visão da Web Semântica, o modelo de contexto do OpenCOPI é representado como uma ontologia pois oferecem alto grau de formalidade e expressividade, prevenindo interpretações semânticas diferentes de um mesmo conjunto de informações de contexto, isso é, prevenindo ambiguidade. Ontologias também oferecem inferência de contexto, compartilhamento de conhecimento, assim como interoperabilidade de software, permitindo integração transparente de serviços. Desse modo, o uso do OpenCOPI simplifica o desenvolvimento de aplicações ubíquas, provendo o desacoplamento entre as aplicações e os provedores de serviços, permitindo que ambos evoluam de forma independente. Com relação às outras plataformas de integração existentes, as principais vantagens do OpenCOPI, embora existam outras, são o uso de web semântica e composição automática de serviços levando em consideração o QoS e QoC. 5. Considerações Finais Esse artigo propôs a divisão da era da computação ubíqua em três fases. A primeira fase foi marcada por aplicações totalmente dependentes e acopladas ao domínio da aplicação e às tecnologias utilizadas, onde além das regras de negócios, a aplicação também implementava a comunicação com os dispositivos específicos implantados no ambiente (sensores, atuadores, etc). A segunda fase consistiu no uso de plataformas de middleware 70

75 com o objetivo de facilitar o desenvolvimento das aplicações ubíquas através da separação dos requisitos funcionais e não funcionais, permitindo que as aplicações se concentrassem nos requisitos funcionais. Porém as plataformas de middleware, de um modo geral, são específicas de domínio e/ou são restritivas com relação a alguns serviços essenciais para as aplicações ubíquas em razão das tecnologias utilizadas. Isso resulta num cenário nebuloso para aplicações que precisem utilizar informações provenientes de vários middleware, uma vez que essas plataformas não são interoperáveis. Finalmente, a terceira fase promove justamente a interoperabilidade entre essas plataformas de middleware, permitindo que aplicações usem informações provenientes de diversas fontes sem necessariamente conhecer a existência e nem mito menos a API dessas diversas plataformas de middleware. O artigo propôs ainda o OpenCOPI, que é uma plataforma integradora de middleware para computação ubíqua, plataforma essa pertencente a terceira e atual fase da computação ubíqua. O OpenCOPI explora a idéia de serviços Web, fornecendo um conjunto de serviços, cuja descrição é baseada em ontologias, para o desenvolvimento de aplicações ubíquas. Referências [1] Weiser, M. (1991) The computer for the 21st century, Scientific American, pp [2] Nakazawa, J., et al (2006) A Bridging Framework for Universal Interoperability in Pervasive Systems. In ICDCS Lisboa, Portugal. [3] A. Dey and G. Abowd, The Context Toolkit: Aiding the Development of Context- Aware Applications, in Workshop on Software Engineering for Wearable and Pervasive Computing, Limerick, Ireland, June 6, [4] Gu, T., et al. (2005) A Service-Oriented Middleware for Building Context-Aware Services. In Journal of Network and Computer Applications, 28(1):1 18. [5] Ranganathan, A., et al. (2004) Middlewhere: A middleware for location awareness in ubiquitous computing applications. In: H.-A. Jacobsen, editor, Middleware, volume 3231 of Lecture Notes in Computer Science, pages , Springer. [6] Rouvoy, R., et al. (2009) MUSIC: Middleware Support for Self-Adaptation. In Ubiquitous and Service-Oriented Environments. Lecture Notes in Computer Science. Ed. Springer, v. 5525/2009, p , June. [7] Hsu, Jenq-Muh et al. (2007) Ubiquitous Multimedia Information Delivering Service for Smart Home. In MUE Seoul, Korea. [8] Jørgensen, J. B. Coloured Petri Nets in UML-Based Software Development - Designing Middleware for Pervasive Healthcare. In Proc. of the Fourth International Workshop on Practical Use of Coloured Petri Nets and the CPN Tools, Aarhus, Denmark, [9] Gong, P. et al. (2005) An Intelligent Middleware for Dynamic Integration of Heterogeneous Health Care Applications. In MMC. Melbourne, Australia. [10] Hasiotis, T., et al. (2005) Sensation: a Middleware Integration Platform for Pervasive Applications in Wireless Sensor Networks. In European Workshop on Wireless Sensor Networks. Istanbul, Turkey [11] Hesselman, C. et al. (2008) Bridging context management systems for different types of pervasive computing environments. In MOBILWARE Innsbruck, Austria. [12] Lopes, F., et al. (2009) Uma Plataforma baseada em Serviços Web para Integração de Middleware de Contexto. In WEBMEDIA, Fortaleza, Brasil. 71

76 Proposta de Modelo Gerador de Regras de Navegação Adaptativas usando proxy Squid Raphael Araújo e Silva 1, Claudio de Castro Monteiro 2 1 IFaculdade Católica do Tocantins - Av. Teotônio Segurado, 1402 Sul Cj. 01, Cep: Palmas TO Brasil 2 Instituto Federal de Educação, Ciência e Tecnologia do Tocantins - AE 310 Sul, Avenida LO 05, S/N, Plano Diretor Sul, Cep: Palmas TO Brasil Abstract. This article proposes the creation of a software that contains two modules, a collector and a parser, which generates, in a automatic way, with the support of a database management system, content filtering rules for the Squid proxy server, based on information collected from access log files and, moreover, considering the configuration parameters and analysis rules defined by the network administrator. Resumo. Este artigo propõe a criação de um software constituído de dois módulos, um coletor e outro analisador, o qual gere, de forma semiautomática, com o apoio de um sistema gerenciador de banco de dados, regras de filtragem de conteúdo para o servidor proxy Squid com base em informações coletadas de arquivos de registro de acesso e, ainda, considerando os parâmetros de configuração e análise definidos pelo próprio administrador de rede. 1. Introdução Um proxy é uma técnica de rede geral a qual aparece em diversas situações, incluindo firewalls 1. Em geral, um proxy é um processo que se encontra entre um processo cliente e um processo servidor. Para o cliente, o proxy parece ser o servidor; de certa forma, o proxy está se colocando no lugar do servidor. Para o servidor, o proxy parece ser o cliente. Além disso, segundo [2] muitos softwares de serviço proxy provêm meios de negar o acesso à certos endereços de web sites (URLs) em uma lista-negra, proporcionando desta forma uma filtragem de conteúdo baseadas em regras. Este método é usado comumente em ambientes corporativos, porém com o aumento do uso de sistemas operacionais Unix-Like em pequenos negócios e em ambientes domésticos, esta função não está mais restrita à grandes corporações. 2. Daemon Coletor Este módulo consiste em um daemon coletor de dados. O funcionamento deste módulo trata basicamente da leitura das informações de acesso de usuários gerados pelo 1 Roteador programado especialmente para encaminhar pacotes de uma rede para outra e também filtrar pacotes de rede que transitam através dele [5]. 72

77 Squid e gravadas no arquivo access.log e posterior armazenagem no banco de dados (SGBD). O coletor é configurado para extrair informações vindas do log de acesso do Squid bem como obter arquivos do servidor de destino, registrados nas requisições dos usuários, para serem analisados posteriormente. Neste último caso, o coletor apenas armazenará os documentos acessados caso estes sejam legíveis, ou seja, não sejam em formato binário e sim em formato texto padrão. Um exemplo de documentos em formato texto padrão são páginas de web sites escritas em linguagem HTML. A figura 1 demonstra a interação entre o módulo coletor, o proxy Squid e o Sistema Gerenciador de Banco de Dados. 3. Daemon Analisador Figura 1. Diagrama de interação entre coletor, proxy Squid e SGDB O módulo analisador consiste no principal objeto do modelo de implementação, pois é a partir dos procedimentos executados por este que serão geradas as regras de filtragem as quais serão aplicadas ao proxy Squid. Assim como o módulo coletor, este módulo é construído em forma de um daemon, ou seja, suas tarefas são executadas em segundo plano sem a interferência direta do administrador. A princípio, o proxy Squid deve ser configurado de forma a aceitar acessos dos clientes a qualquer espécie de conteúdo. É tarefa do módulo analisador gerar os devidos bloqueios aos conteúdos ditos como impróprios. Com o passar do tempo, a filtragem de conteúdo toma forma de acordo com o perfil de acesso dos usuários da rede. Desta maneira, a manutenção e criação de novas regras passa a ser responsabilidade do módulo analisador e não mais do administrador. Basicamente, este módulo trabalha as informações armazenadas pelo coletor no SGBD como também informações armazenada em possíveis arquivos de texto obtidos dos servidores de destino. Mas para que estas informações possam ser interpretadas de forma a gerar regras de filtragem coerentes, é necessário que o administrador defina grupos de expressões regulares, atribuindo-lhes valores numéricos os quais representam o grau de impropriedade de acordo com as políticas internas do ambiente de rede. O objetivo do grau de impropriedade é definir um direcionamento aos algoritmos de análise durante a criação das regras de filtragem. O grau de impropriedade funciona também como um valor de prioridade de aplicação das expressões e cada grupo nas informações a serem analisadas, ou seja, quanto maior o grau maior antecedência de aplicação terá um determinado grupo durante o processo de análise. A tabela 1, a seguir, demonstra um exemplo de grupo de expressões regulares, seus respectivos graus de impropriedade e o tipo de bloqueio que cada grupo ocasiona: 73

78 Tabela 1. Exemplo de Expressões Regulares no daemon analisador Expressão Regular Grau de Impropriedade Tipo de Bloqueio (S s)(e e)(x x)(o o)*, (P p)(o o)(r r)(n n)(.)* 10 Permanente jogo(s)*, game(s)*, video(game)* 5 Temporário (n horas) bate-papo, chat, blog 1 Temporário (n horas) Além das expressões, o administrador precisa definir outros três parâmetros para geração das regras. Um desses parâmetros é o tipo de regra a ser gerada, o qual pode ser: uma regra de bloqueio temporário, a qual possui um tempo de vigência estabelecido ou uma regra bloqueio permanente a qual não possui tempo de duração definido. O segundo parâmetro trata-se de um threshold, um valor numérico usado como limite de tolerância para que uma regra não seja gerada. O terceio parâmetro, não obrigatório, são expressões regulares as quais são usadas como exceções. Especificamente, estas expressões de exceção ou urls de exceção são combinadas com as URLs dos registros analisados, caso estas se combinem, a análise do registro é ignorada imediatamente e o registro considerado como válido ou não-impróprio. Os algoritmos de análise de posse das informações como as da tabela no exemplo acima, fazem uma varredura no banco de dados verificando se umas das expressões constantes na tabela combinam com os registros cadastradas na base de dados ou com os arquivos previamente obtidos dos servidores, ambas tarefas executadas pelo daemon coletor. Em caso positivo, ou seja, uma expressão foi encontrada para um determinado registro de acesso de um cliente, o módulo analisador incrementa a um acumulador de acessos destinado ao grupo o qual a expressão combinada faz parte. Ao fim de um dado ciclo de análises, o daemon verifica o a quantidade total de acessos feitos por um determinado cliente. Em seguida, para cada grupo o qual foi localizado nos registros de acesso é calculado o percentual de acessos em relação ao total. Caso o percentual resultante alcance o threshold de bloqueio definido pelo administrador, uma regra será gerada para aquele cliente em relação ao grupo e atribuída ao proxy Squid, e este, por sua vez sofre uma reconfiguração para que a nova regra possa entre em funcionamento. A varredura executada pelo daemon analisador, por padrão, é feita enquanto a conexão do usuário está ativa a fim de evitar processamentos desnecessários envolvendo registros de acessos anteriores ao início da conexão em questão. No momento em que a conexão de um dado cliente se encerra o módulo interrompe seu processo de análise para aquele cliente. O processo de análise e geração de regras só será completamente interrompido quando não houver nenhuma conexão de cliente ativa com o proxy Squid. Além deste comportamento padrão, o daemon pode ser forçado a analisar os registros de acesso de todos os clientes mesmo que estes não estejam conectados ao proxy Squid demandando um tempo um pouco maior para a geração de regras de bloqueio. A cada nova geração de regras, o módulo deve verificar se as regras ativas estão em tempo de vigência, caso estas sejam regras de bloqueio temporário. Para as regras de bloqueio permanente, caso seja necessário sua anulação, é dever do administrador removê-las manualmente através da interface de gerenciamento (módulo gerenciador). O diagrama a seguir demonstra tanto o funcionamento básico das entidades da figura 2 como também a interação do daemon analisador com o SGBD e com o proxy 74

79 Squid. Figura 2. Diagrama de interação entre coletor, analisador, proxy Squid e SGBD 4. Módulo Gerenciador O gerenciador consiste no módulo o qual centraliza o controle dos dois módulos descritos anteriormente. A sua implementação não é obrigatória, ou seja, o funcionamento do modelo de software proposto não depende da existência deste último módulo. Mesmo não sendo obrigatório, o uso deste módulo facilita a configuração dos parâmetros de funcionamento dos daemons coletor e analisador, além do monitoramento do estado do proxy Squid e do Sistema Gerenciador de Banco de Dados. O módulo gerenciador também é capaz de manipular as informações armazenadas pelo daemon coletor e administrar as regras geradas pelo daemon analisador, permitindo, por exemplo, que o administrador revogue regras ativas, crie grupos de expressões regulares com um certo valor de impropriedade como também inserir expressões de exceção. Pode-se dizer que este módulo é uma espécie de font-end, ou seja, a interface amigável entre o usuário e os demais módulos e que tem como objetivo disponibilizar e auxiliar de forma mais simples e intuitiva as opções de configuração e execução existentes para cada uma das entidades. A Figura 3 demonstra a interação entre o módulo gerenciador e os demais módulos já descritos. Nota-se que todas as linhas partindo da entidade Gerenciador são tracejadas, isso para representar a não obrigatoriedade da implementação deste módulo. Figura 3. Diagrama de interação entre o gerenciador e os demais módulos 5. Implementação e Resultados Para a execução dos testes de implementação e delineamento dos resultados foi considerado o seguinte cenário: Um ambiente de rede governamental onde são 75

80 proibidos acessos a sites de pornografia, jogos, bate-papo, download de softwares sem registro (ilegais), rede social e de streaming de vídeo e áudio. O acesso a demais sites é liberado desde que estes sejam governamentais, de busca, webmail, ou de qualquer outro tipo de conteúdo dito como apropriado para o modelo de trabalho desempenhado nas instalações órgão. Baseado nos parâmetros de configuração definidos para o ambiente em questão, a política de análise de registros de acessos pelo daemon analisador foi realizada para 10 clientes da rede, escolhidos aleatoriamente. O processo de análise é baseado em ciclos de leitura e possível geração de regras ao final de um determinado tempo. Os valores adotados para quantidade de ciclos, quantidade de registros lidos por ciclo e tempo de geração de regras de bloqueio foram, respectivamente, 1 ciclo, registros, 15 minutos. Ao final de um período de 4 horas de análise, os resultados de um dado cliente foram separados e reunidos na figura 4 para ilustrar o perfil de acesso. Figura 4. Percentual de Acessos para cada grupo num período de 4 horas de análise De acordo com as informações do gráfico, cada categoria de sites obteve um determinado percentual no quantitativo total de acessos do usuário distribuídos em uma linha de tempo dividida em um intervalo médio de 15 minutos. O grupo sites válidos foi o que mais obteve acessos, significando que o cliente manteve um perfil de navegação relativamente correto em relação às regras estabelecidas. Três outros grupos tiveram um percentual de acessos relevante ao ponto de extrapolarem o limiar de não-geração de regras de bloqueio. Os grupos os quais tiveram regras de bloqueio geradas para o cliente em questão foram: porno, redesocial e jogo. Como mostrado no gráfico, o número de acessos para os três grupos citados foi relativamente pequeno em relação ao total, sendo respectivamente, 3% para o grupo porno, 1% para o grupo jogo e 30% para o grupo redesocial. O fator determinante para a geração de regras foi a baixa tolerância de acessos a conteúdos que se encaixavam em um desses três grupos. O software implementado é capaz de eliminar regras anteriormente geradas caso o perfil de acesso do usuário se modifique ao longo do tempo de forma que este se aproxime o máximo possível do permitido sempre obedecendo as faixas de tolerância de cada grupo. Desta forma, o software sempre estará em processo dinâmico e constante de geração de regras, sempre detectando as variações na forma como os usuário 76

81 navegam no internet. 6. Conclusão Com a implementação do presente modelo de software e com base na análise dos resultados obtidos, verificou-se que é possível a aplicação de técnicas de geração automática de regras de bloqueios para o proxy Squid com o auxílio de metodologias estatísticas as quais levam em conta o perfil de acesso de cada usuário e também com o uso das expressões regulares como forma de operação sobre cadeia de caracteres com o intuito identificar padrões de palavras. Mesmo com todos os critérios de análise e parâmetros de configuração informados ao daemon analisador no ínício do processo de análise, notou-se a presença de ruídos nos resultados, ou seja, alguns poucos sites foram bloqueados mesmo não se encaixando num determinado grupo dito como impróprio. Para se contornar esse problema, o administrador tem a opção de inserir as URLs de exceção as quais são usadas para determinar que sites devem ser desconsiderados no processo de análise. Desta maneira, todo e qualquer site que por ventura foi bloqueado erroneamente não será mais indisponibilizado. 7. Trabalhos Futuros Como implementação futura, procura-se diminuir os ruídos em resultados refinando ainda mais o processo de análise dos registros de acessos dos usuários. Além disso, será construído um módulo responsável pela análise especificamente de imagens, usando técnicas de visão computacional apoiadas por redes neurais. Este módulo será um complemento do daemon analisador, que atualmente, efetua a análise apenas de documentos textuais. 8. Referências [1] Wikipedia (2009), Proxy, Janeiro. [2] Wikipedia (2009), Proxy Server, Janeiro. [3] Wikipedia (2008), Daemon (Aplicativo para computadores), Setembro. [4] Wikipedia (2008), Sistema de Gerenciamento de Banco de Dados, Setembro. [5] Peterson, L. L. e Davie B. S. (2004), Redes de computadores: uma abordagem de sistemas, Elsevier. [6] Tanenbaum, A. S. (2003), Sistemas Operacionais Modernos, Prentice Hall. [7] Wessels, D. (2004), Squid: The Definitive Guide, O'Reilly. [8] Heuser, C. A. (2004), Projeto de Banco de Dados, Sagra Luzzatto. 77

82 Estudo da Viabilidade Técnica da Implementação de Referência Ninf G para Computação Distribuída Baseado na ISO/IEC Hedson Rodrigues Lima 1, Ricardo Nascimento Ferreira 1, Cássio Juliano Santiago 1, Flávia Estélia Silva Coelho 2, Yáskara Ygara Menescal Pinto Fernandes 2 1 Universidade Católica de Brasília (UCB) QS 07 Lote 01 EPCT Águas Claras Taguatinga DF CEP Departamento de Ciências Exatas e Naturais (DCEN) Universidade Federal Rural do Semi Árido (UFERSA) BR 110 Km 47 Bairro Presidente Costa e Silva, Mossoró RN CEP Abstract. This paper shows an approach for the feasibility study of the reference implementation of remote procedure calls over computational grids GridRPC, named Ninf G, running on free operational systems. By means of standards, it will be analyzed if the determinated requisites were implemented on a satisfactory manner, generating results that accomplishes the software requirements. Resumo. Este artigo apresenta uma proposta para o estudo de viabilidade da implementação de referência de chamadas a procedimentos remotos em grades computacionais GridRPC, denominada Ninf G, executando sobre sistemas operacionais livres. Através do uso de normas, será analisado se determinados requisitos foram implementados de forma adequada, gerando resultados que atingem os requisitos de software. 1. Introdução A computação em grade baseia se no compartilhamento de recursos dispersos, a fim de reduzir o tempo de execução de programas [Tanaka et. al. 2005]. Visando um ambiente amigável de programação para grades, o OGF (Open Grid Forum) [Working Group 2007] projetou a especificação de implementação do RPC (Remote Procedure Call), denominada GridRPC [Nakada, H., et. al. 2007]. Sendo o Ninf G (Network based Information Library for high performance computing over Globus), uma implementação de referência do GridRPC baseada no Globus [Globus 2009]. Verificou se, após pesquisa, a escassez de estudos de viabilidade técnica e de benchmarks publicados a respeito do Ninf G. Dadas suas funcionalidades e os aspectos de qualidade de software, este trabalho propõe a análise de sua viabilidade técnica baseada na Norma ISO/IEC

83 Na seção 2, os fundamentos de GridRPC e Ninf G são expostos; na seção 3, exibem se a proposta de estudo da viabilidade técnica e os resultados obtidos em um ambiente de testes específico; e, na seção 4, algumas considerações finais. 2. A Arquitetura GridRPC e o Middleware Ninf G Desenvolver (ou adaptar) uma aplicação para grades, requer APIs complexas. Nesse sentido, o Ninf G fornece facilidades para a execução, tratando a heterogeneidade do ambiente e fornecendo uma API para o desenvolvimento de aplicações [Ninf 2009]. O Ninf G compreende um Cliente, um Servidor que invoca executáveis remotos, constituído por um stub, um IDL (Interface Definition Language) e bibliotecas; Executáveis Remotos que efetuam a computação propriamente dita; e Sistemas de Informação que permitem acionar o executável remoto para a tarefa a ser realizada. 3. Proposta de Estudo da Viabilidade Técnica do Ninf G 3.1 Metodologia Utilizada Um processo de avaliação de software aliado à definição de requisitos de qualidade formam um modelo eficaz [Boas 2005]. As Normas ISO/IEC 9126 (Qualidade de Produtos de Engenharia de Software) e a (Avaliação de Produtos de Software) formaram a referência de avaliação [Norma 2001], cujo processo, é mostrado a seguir Estabelecer Requisitos de Avaliação Uma vez que o Ninf G é um middleware, os processos de avaliação de software devem ser adaptados. Por exemplo, não há como analisar por exemplo, a 'conformidade' com requisitos (afinal, não há levantamento de requisitos para middlewares). A Norma agrupa os atributos em funcionalidade, confiabilidade, usabilidade, eficiência, manutenibilidade e portabilidade. Com isso, elaboraram se listas de verificação adaptadas, a fim de conterem os atributos sob análise, a descrição da qualidade interna, o método de teste, os resultados obtidos e uma avaliação para o item Especificar a Avaliação Para a avaliação do Ninf G não foram definidas métricas, apenas níveis de pontuação, uma vez que a idéia é verificar o seu comportamento, sob critérios de avaliação de qualidade e pontuá los, visando de estabelecer critérios para julgamento da qualidade. Seguindo a sugestão da Norma, a cada um dos atributos foram atribuídos pesos, que representam a sua importância na nota da categoria. Por exemplo, para funcionalidade, a operacionalidade representa 40% da nota. Como a funcionalidade é formada por outros atributos, para obter o valor da pontuação, calcula se a média ponderada entre os sub itens, considerando o seu peso. O peso atribuído foi proposto em função da importância do atributo para o contexto de grades computacionais (vide 3.2) Projetar a Avaliação Projetou se um plano de avaliação embutido na lista de verificação (vide 3.3.2) usando um campo que define os meios usados para simular uma dada situação. 79

84 3.1.4 Executar a Avaliação Foram executados os testes, para coletar o comportamento de cada atributo selecionado. 3.2 Atributos de Avaliação Na avaliação foram extraídos atributos de qualidade interna a ele adaptáveis (Tabela 1). Tabela 1: Características de Qualidade Interna e Pesos Atribuídos Característica de Qualidade Peso Funcionalidade 16% Interoperabilidade 40% Segurança de Acesso 60% Confiabilidade 10% Maturidade 60% Tolerância a falhas 40% Usabilidade 15% Inteligibilidade 50% Apreensibilidade 50% Eficiência 25% Tempo de resposta 60% Utilização de recursos 40% Manutenibilidade 20% Analisabilidade 50% Modificabilidade 50% Portabilidade 14% Adaptabilidade 50% Capacidade para ser instalado 50,00% A ISO/IEC 9126 aconselha o uso de faixas de pontuação. Nesse sentido, esta obra propõe: 0,0 a 5,0 Insatisfatório; 5,1 8,0 Satisfatório; 8,1 10,0 Ideal. 3.3 Execução da Avaliação Ambiente de Avaliação A Figura 1 apresenta o ambiente 'simplificado' de testes. Para a conexão à Internet, foi utilizado um link com capacidade de 300 Kbps(upstream) e 128 Kbps (downstream). Figura 1: Estrutura do ambiente de testes 80

85 3.3.2 Resultados Seguem os resultados obtidos ao considerar o Ninf G sob o ambiente de testes sugerido. Característica de Qualidade: FUNCIONALIDADE Atributo de Qualidade Interna: 1.1 Interoperabilidade Resultado Final: Ideal Nota: 8.5 Critérios de avaliação: Analisar a interação com sistemas operacionais. Método aplicado para o teste: Tentar executar o Ninf G em ambiente híbrido (Linux CentOS 4 e FreeBSD 6) Resultados obtidos: A instalação do Ninf G é simples nas plataformas homologadas para seu uso. Entretanto, no FreeBSD foi necessário aplicar um patch de correção para localizar os cabeçalhos de bibliotecas. Característica de Qualidade: FUNCIONALIDADE Atributo de Qualidade Interna: 1.2 Segurança de Acesso Resultado Final: Ideal Nota: 10.0 Critérios de avaliação: Verificar os mecanismos de segurança utilizados. Método aplicado para o teste: Recorrer à documentação do software e verificar como a segurança é provida. Resultados obtidos: O Ninf G utiliza os serviços de segurança fornecidos pelo Globus GSI (Grid Security Infrastructure) [Ninf 2007], cuja idéia é utilizar uma autoridade certificadora (foi utilizada a Simple CA). Característica de Qualidade: CONFIABILIDADE Atributo de Qualidade Interna: 2.1 Maturidade Resultado Final: Satisfatório Nota: 7.0 Critérios de avaliação: Avaliar quais os meios que o Ninf G utiliza para evitar falhas de software. Método aplicado para o teste: Recorrer à documentação do software e verificar a existência de tal mecanismo. Resultados obtidos: Os erros são reportados diretamente pelo compilador GCC (Gnu C Compiler). Característica de Qualidade: CONFIABILIDADE Sub Item: 2.2 Tolerância a falhas Resultado Final: Insatisfatório Nota: 4,0 Critérios de avaliação: Avaliar o comportamento do Ninf G quando ocorrem falhas de software. Método aplicado para o teste: Recorrer à documentação, à procura de funcionalidades de tolerância a falhas. Resultados obtidos: O Ninf G propaga erros para os clientes, para que possam fazer o devido tratamento. Característica de Qualidade: USABILIDADE Sub Item: 3.1 Inteligibilidade Resultado Final: Ideal Nota: 10.0 Critérios de avaliação: Avaliar as formas fornecidas para compreensão e uso (documentação, manuais, etc.) Método aplicado para o teste: Avaliar a documentação disponível no site oficial do Ninf G. Resultados obtidos: A documentação ressalta as potencialidades do Ninf G. Os programas exemplo auxiliam no entendimento dos conceitos básicos de funcionamento e da utilização de recursos mais sofisticados. Característica de Qualidade: USABILIDADE Sub Item: 3.2 Apreensibilidade Resultado Final: Insatistatório Nota: 5.0 Critérios de avaliação: Avaliar a forma de aprendizado fornecida pelo software. Método aplicado para o teste: Tentar executar um tutorial de criação de um programa baseado no Ninf G. Resultados obtidos: O tutorial mostrou se impreciso em alguns exemplos, que não possuíam todos os elementos para que a customização de uma aplicação, que não utiliza o GridRPC, pudesse ser executada com sucesso. Característica de Qualidade: EFICIÊNCIA Sub Item: 4.1 Tempo de resposta Resultado Final: Satisfatório Nota: 10,0 Critérios de avaliação: Avaliar o tempo de resposta do aplicativo durante a execução. Método aplicado para o teste: Executar os programas exemplo em diversas plataformas e verificar o tempo de resposta e a taxa de transferência de dados. Resultados obtidos: Chamadas ao Globus são consideradas gargalo, uma vez que este associa a cada processo, um gerente de tarefas distinto. Os programas têm que aguardar a execução de tarefas em todos os nós, antes de exibir o resultado final. Assim, para cálculos pequenos, o uso de computação distribuída aumentou o tempo de execução. Característica de Qualidade: EFICIÊNCIA Sub Item: 4.2 Utilização de recursos Resultado Final: Ideal Nota: 10.0 Critérios de avaliação: Avaliar a utilização de recursos de hardware tais como processamento e memória. Método aplicado para o teste: Executar os programas exemplo e verificar a utilização de CPU e Memória. Resultados obtidos: Testou se um programa que calcula o valor do PI (método de Monte Carlo), no qual, a precisão e poder computacional necessários variam em função do número de pontos. Seguem as situações. Situação A: Execução disparada de um cliente para 1 servidor; Situação B: Execução disparada de um cliente para 2 servidores (1 instância em cada); Situação C: Execução disparada de um cliente para 2 servidores (2 instâncias em cada). O processamento foi distribuído em função do número de nós e instâncias disponíveis 81

86 ( e de pontos). Na Situação A, ocorreu uso maciço de recursos para de pontos. Na Situação B, não houve ganho substancial de tempo dado o poder computacional distinto dos nós. O uso de memória não ultrapassou 3 MB. Na situação C, houve ganho de tempo, mas a utilização de memória dobrou e a utilização de CPU permaneceu praticamente a mesma. Portanto, a utilização de recursos se mostrou satisfatória. Característica de Qualidade: MANUTENIBILIDADE Sub Item: 5.1 Analisabilidade Resultado Final: Ideal Nota: 8,0 Critérios de avaliação: Avaliar se o aplicativo fornece meios de verificação de falhas e recursos de depuração. Método aplicado para o teste: Simular erros de configuração, dados inconsistentes e analisar o comportamento. Resultados obtidos: O Ninf G propaga erros das camadas inferiores (do Globus) para as superiores (aplicação). Todavia, aumentando o nível de log a ser exibido, a rastreabilidade de erros é facilitada. A localização do erro é dificultada em virtude da impossibilidade de identificar se a falha é local, na configuração do Ninf G ou no Globus. Característica de Qualidade: MANUTENIBILIDADE Sub Item: 5.2 Modificabilidade Resultado Final: Ideal Nota: 10,0 Critérios de avaliação: Avaliar os recursos de documentação disponíveis para modificações nos códigos fontes. Método aplicado para o teste: Avaliar a documentação de programação (APIs) disponível para o Ninf G. Resultados obtidos: O Ninf G provê APIs para as linguagens C e Java. A documentação da API para C e Java está disponível, respectivamente, na forma de man pages e javadoc, cujo conteúdo foi considerado satisfatório. Característica de Qualidade: PORTABILIDADE Sub Item: 6.1 Adaptabilidade Resultado Final: Satisfatório Nota: 7.0 Critério de avaliação: Avaliar o nível de complexidade de migração de um ambiente para o outro. Método aplicado para o teste: Portar uma instalação completa do Ninf G de um equipamento para outro. Resultados obtidos: O nível de complexidade de migração é mediano, pois alguns passos para a criação de um primeiro ambiente são desnecessários para os demais, tais como a compilação do Globus e Java. Característica de Qualidade: PORTABILIDADE Sub Item: 6.2 Capacidade para ser instalado Resultado Final: Ideal Nota: 10.0 Critério de avaliação: Avaliar a complexidade de instalação do produto. Método aplicado para o teste: Instalar o aplicativo em ambientes distintos e avaliar a complexidade. Resultados obtidos: A instalação de um compilador Java compatível com o Globus e Ninf G representa um dos desafios para sua implementação em plataformas que não possuam um compilador Java nativo. 4. Conclusão De posse dos resultados, pôde se tabulá los para a obtenção de médias (vide Tabela 2). Tabela 2: Planilha de Avaliação de Viabilidade Técnica #Aspecto analisado Peso Nota 1Funcionalidade 16% 9, Interoperabilidade 40% 8, Segurança de acesso 60% 10,00 2Confiabilidade 10% 5, Maturidade 60% 7, Tolerância a falhas 40% 4,00 3Usabilidade 15% 7, Inteligibilidade 50% 10, Apreensibilidade 50% 5,00 4Eficiência 25% 10, Tempo de Resposta 60% 10, Utilização de recursos 40% 10,00 5Manutenibilidade 20% 9, Analisibilidade 50% 8, Modificabilidade 50% 10,00 82

87 6Portabilidade 14% 8, Adaptabilidade 50% 7, Capacidade para ser instalado 50% 10,00 100% 8,70 O Ninf G depende de uma infra estrutura (Globus) o que limita a sua análise, quando considerado isoladamente. Porém, a sua configuração, instalação e utilização foram consideradas satisfatórias, se a configuração da infra estrutura for adequada. Prover uma interface amigável para programação em grades computacionais e obter alta performance premissas do Ninf G, são satisfatórios (Manutenibilidade e Eficiência). Todavia, a confiabilidade está aquém do ideal. Constatou se que não há uma distinção entre metodologias de avaliação para softwares comerciais e para serviços de redes/computação distribuída. Apesar de ambos serem produtos de um processo de engenharia de software, os serviços de rede não têm, necessariamente, levantamentos de requisitos da forma prevista, e nem têm como objetivo prover algumas funcionalidades, tais como testabilidade, já que existem casos em que o usuário final é um outro aplicativo, por exemplo. As nuances identificadas sugerem um trabalho futuro para adequar padrões de desenvolvimento e de avaliação de qualidade de software para a área de redes de computadores e computação distribuída. A nota final obtida 8.7 (ideal) demonstra que o Ninf G é tecnicamente viável. Sugere se, nesse contexto, a execução de testes adicionais em outras plataformas (hardware e sistemas operacionais), buscando subsídios adicionais de sustentabilidade. Referências Boas, A. V. (2005) Qualidade e Avaliação de Produto de Software, Dissertação de Mestrado, Universidade Federal de Lavras. Globus (2009) The Globus Toolkit, Grid Forum (2009) Open Grid Forum, Nakada, H., et al. (2007) A GridRPC Model and API for End User Applications, Global Grid Forum, Ninf (2009) A Global Computing Infrastructure, Norma (2001), NBR ISO/IEC Tecnologia da Informação Avaliação de Produto de Software Parte I: Visão Geral, Associação Brasileira de Normas Técnicas. Tanaka, Y. et. al. (2005) Design, Implementation and Performance Evaluation of GridRPC Programming, grid02keith/grid02keith.pdf. Working Group, (2007) GRID Remote Procedure Call Working Group, https://forge.gridforum.org/projects/gridrpc wg/. 83

88 Projeto e Implementação de um Servidor para Persistência e Recuperação do Estado de Persistent Browser-Based Games Thalles Robson Barbalho 1, Jezmael Oliveira Basílio 1, Marcelino Pereira dos Santos Silva 1 1 Departamento de Informática Universidade do Estado do Rio Grande do Norte (UERN) BR Km 46, Bairro Pres. Costa e Silva CEP , Mossoró - RN Abstract. The growth of Internet use has led many large development companies to create web-based applications. One example is the game class called Persistent Browser-based Games (PBBG), whose main feature is to persist the state of the environment for a long period of time, allowing the player to recover this state later. This work aims to present a prototype for the server of a browserbased game, focusing on an architecture for the persistence and recovery of the state of the environment using relational databases and XML files. Resumo. O crescimento do acesso a internet tem levado muitas grandes empresas de desenvolvimento a criarem aplicações baseadas na web. Um exemplo disso são os jogos eletrônicos denominados Persistent Browser-based Games (PBBG), cuja a característica principal é persistir o estado do ambiente por um longo período de tempo, podendo o jogador recuperar este estado posteriormente. Este presente trabalho tem como objetivo apresentar um protótipo para o servidor de um browser-based game, focando uma arquitetura para a persistência e recuperação do estado do ambiente utilizando banco de dados relacionais e arquivos XML. 1. Introdução O constante crescimento do acesso a internet tem tornado aplicações baseadas na web muito mais atrativas que aplicações locais. Deste modo, pode-se dispor dessas aplicações em qualquer computador que esteja conectado à internet e possua um navegador, sem a necessidade da instalação de softwares e bibliotecas adicionais [Magalhães 2006]. Podemos definir um Persistent Browser-based Game (PBBG) como um jogo eletrônico que pode ser jogado e acessado em um navegador da web e que apresenta um ambiente virtual compartilhado persistente, onde os eventos continuam a acontecer mesmo na ausência do usuário, podendo este recuperar sua sessão posteriormente [Project 2009]. Os bancos de dados relacionais são o meio mais utilizado para a persistência dos dados destes ambientes. Aplicações dessa categoria precisam ter tanto uma implementação servidora, onde as regras de negócio do mesmo são garantidas e mantidas, quanto uma implementação cliente, que provê uma interface ao usuário proporcionando a usabilidade desejada. O presente trabalho apresenta o desenvolvimento de um protótipo para um servidor de browser-based game, com foco na arquitetura de persistência e recuperação do 84

89 estado da aplicação cliente, bem como conceitos, técnicas e ferramentas que forneçam suporte à implementação do protótipo para o cenário estudado. Toda a ênfase deste trabalho será dedicada à aplicação servidora, ficando o cliente destinado a trabalhos futuros. 2. Persistent Browser-Based Games Em [Project 2009] um PBBG é definido como jogos de computador na qual satisfaçam os dois seguintes critérios: O jogo deve ser completamente executado na internet usando apenas o navegador. Nas multiplas sessões do jogador, as suas progressões no jogo devem completamente armazenadas. Desse modo podemos considerar que a definição de um PBBG é bastante ampla, na qual jogos de categorias como single-player (jogos de um único participante) e multi-player (múltiplos participantes), e de gêneros como: jogos de interpretação, estratégias, cartas, tiro, sociais e assim por diante; também podem ser englobados. Porém, não podemos dizer que um PBBG tem o mesmo significado que um MMOG (Massively Multi-player Online Game), já que este pode ser também executado como uma aplicação instalada localmente, eliminando assim o conceito de portabilidade que um PBBG propõe. Atualmente, são exemplos de PBBGs que contemplam o estado da arte Gaia Online [GaiaOnline 2009] e Dofus [Dofus 2009]. Estes jogos proveêm tanto a portabilidade requerida para o gênero quanto uma rica interface com o usuário proporcionando uma profunda imersão ao ambiente virtual, tornando a linha entre PBBG e games baseados em desktop cada vez mais tênue, através do uso de tecnologias RIA (Rich Internet Aplication) como Adobe Flash, Microsoft Silverlight e Java FX, isto sem a necessidade de dispôr de nenhuma instalação ou aplicativo adicional além do navegador. Por outro lado, aplicações dessa natureza demandam um tempo de carregamento no cliente, o que pode ser bastante inadequado para usuários com limitações na conexão com a internet. 3. Estudo de Caso Este trabalho aborda o estudo de caso de um PBBG de estratégia em tempo-real, onde o jogador envia comandos de forma independente à passagem do tempo da simulação [Cecin and Trinta 2006], em oposição a jogos baseado em turnos, que exigem uma ordem pré-definida para as ações, como damas ou xadrez. Seu enredo é composto por 4 entidades principais, denominadas: Nação, Building, Artefato e Pesquisa. Cada jogador inicia o jogo com uma nação. Há muitos jogadores distribuídos no mesmo ambiente. Um jogador com uma nação pode construir buildings, que servirão para produzir recursos, artefatos ou realizar pesquisas para sua nação. O objetivo de cada jogador é sobrepor-se aos adversários através da obtenção do maior número de recursos possíveis e da destruição das nações oponentes. Captura-se melhor a jogabilidade a partir do diagrama de caso de uso, conforme descreve a figura 1. As ações descritas pela figura 1 devem ser tratadas por uma camada de controle e delegadas à camada de modelo de negócios a fim de serem corretamente atendidas e seus resultados propagados ao ambiente do jogador. 85

90 Figura 1. Diagrama de Caso de Uso 4. O Projeto Inicialmente, foi levantado o conjunto de requisitos mínimos necessários para a definição do projeto conceitual do protótipo: Efetuar carga e persistência dos dados dos elementos do jogo quando necessário. Permitir que o sistema possa obter dados estáticos comuns a todos os elementos a partir de fontes simples de dados como arquivos em XML (extensible Mark-up Language). Realizar o processamento dos elementos do jogo mesmo na ausência do jogador. Garantir que as operações atômicas aos jogadores sejam também transacionais a nível de persistência de dados. Uma vez levantados os requisitos iniciais, o relacionamento entre as diversas entidades do enredo do jogo pode ser explicitado pelo diagrama de entidade-relacionamento descrito na figura 2. Considerando-se que para este protótipo foi utilizado o SQLite 2 [Owens 2006], um desafio do projeto encontra-se na separação do modelo lógico de negócios (classes) e Figura 2. Diagrama de entidade-relacionamento do protótipo 86

91 a camada de persistência, ou seja, em como fazer o mapeamento objeto-relacional entre essas camadas, uma vez que existem diversos conceitos na orientação a objetos para os quais o modelo relacional simplesmente não oferece suporte [Dall Oglio 2007]. Para o mapeamento entre as classes do modelo de negócio e a estrutura tabular do banco de dados, escolheu-se o padrão de projeto Data Mapper, que se constitui em uma camada de aplicação que separa os objetos conceituais do banco de dados, permitindo transferir dados entre uma camada e outra de forma transparente, sem que os objetos do modelo conceitual precisem implementar métodos de persistência [Dall Oglio 2007]. Dessa forma, é preciso que a classe a realizar essa tarefa possa ter acesso aos atributos do objeto conceitual que se deseja persistir ou recuperar na base. Pode-ser fazer isso a partir de métodos próprios que acessam os atributos desse objeto ou tornando esses atributos públicos, alternativa essa escolhida pelo projeto a nível de protótipo pela facilidade de implementação. A figura 3 apresenta um exemplo detalhado do padrão de projeto Data Mapper. Conclui-se que a relação de agregação entre as classes Venda e Produto são tratadas pela classe VendaMapper e corretamente mapeadas em relações tabulares no banco de dados através de recursos com chave primária e chave estrangeira, tornando a camada de persistência transparente à implementação das classes. Figura 3. Exemplo do padrão Data Mapper [Dall Oglio 2007] O objetivo do modelo que separa classes de negócio das classes da camada de persistência é garantir que mudanças nessa camada, como por exemplo a troca do sistema de gerenciamento de banco de dados, possa ser feita sem invalidar o modelo de negócio. Uma arquitetura em camadas é modificável e portável, ou seja, desde que a interface permaneça inalterada, uma camada poderá ser substituída por outra equivalente [Sommerville 2003]. 5. Resultados O protótipo do servidor foi implementado utilizando a linguagem de programação PHP 5 e SQLite 2, uma biblioteca que implementa um banco de dados embutido. Os dados estáticos, comuns a todos os elementos, são mapeados em arquivos XML para que seja possível mudar características ainda que em tempo de execução sem alteração do código 87

92 fonte do protótipo [Rabin 2000]. Essa técnica de desenvolvimento é descrita na literatura como sistemas orientados a dados (data-driven systems), cujo propósito é manter a flexibilidade, extensibilidade e facilidade de manutenção [Kozovits et al. 2003] A figura 4 descreve o diagrama de componentes da implementação do protótipo e as setas indicam a dependência direcional dos componentes. Figura 4. Diagrama de componentes da implementação do protótipo Pode-ser ver no diagrama de componentes da figura 4 a organização interna dos arquivos. Cada entidade no modelo entidade-relacionamento corresponde a uma classe na implementação do protótipo, como mostrado nos componentes Artefato.class.php, Nacao.class.php, Building.class.php e Pesquisa.class.php. A implementação do mapeamento objeto-relacional pelo padrão de projeto Data Mapper encontra-se nos componentes DBMapper.php, responsável por obter dados persistidos no banco de dados e colocá-los nos objetos das classes. O componente DBStore.php tem como função obter os dados destes objetos e persisti-los no banco. Deste modo, uma eventual troca de sistema de gerenciamento de banco de dados não afetaria a implementação das classes estáveis. Toda chamada a algum método em DBMapper.php recai em uma chamada de método em XMLMapper.php. Este componente é responsável por fazer o parsing das estruturas XML dos elementos contidas no componente XML, onde juntamente com os dados obtidos no banco, retornará os dados completamente mapeados para o objeto instanciado. O componente Gateway.php captura as requisições enviadas pelo cliente e de- 88

93 lega a Acoes.php a tarefa de processar essas requisições, isto é, atender as casos de uso da aplicação. Há ainda alguns componentes auxiliares como Funcoes.php, apenas com implementações matemáticas da mecânica de jogo, e ConsultasUteis.php, com um repositório de consultas parametrizáveis ao banco. 6. Conclusões e Trabalhos Futuros O presente trabalho apresenta um protótipo para um servidor de Persistent Browser-Based Game. Foi abordada a arquitetura interna da aplicação com ênfase no mapeamento objetorelacional entre a camada de negócio e a camada de persistência, haja vista que em PBBG persistência é um requisito crucial. Os conceitos tratados foram implementados em ferramentas básicas, a nível de protótipo, mas futuramente pretende-se aplicar esses mesmos conceitos em ferramentas mais poderosas como a linguagem de programação Java, auxiliada por bibliotecas específicas como Hibernate para mapeamento objeto-relacional e Maven 2 para gerência de projetos, dependências, compilação e implantação, além de um sistema de gerenciamento de banco de dados mais robusto como PostgreSQL ou Oracle. Outro aspecto importante em PBBG é a arquitetura do cliente, que envia requisições ao servidor e exibe o feedback ao jogador. A forma como essas requisições são enviadas, recebidas e tratadas serão abordadas em trabalhos futuros. Referências Cecin, F. and Trinta, F. (2006). Jogos multiusuário distribuídos. Dall Oglio, P. (2007). PHP - Programando com Orientação a Objetos. Novatec, 1st edition. Dofus (2009). Dofus - RPG Online Massivo para Múltiplos Jogadores. Disponível em [ Acessado 12 de Novembro de 2009 ]. GaiaOnline (2009). Gaia Online. Disponível em [ Acessado 12 de Novembro de 2009 ]. Kozovits, L. E., Melo, R., and Feijó, B. (2003). O uso de SGBDs relacionais em arquiteturas de jogos multi-jogador. Rio de Janeiro, RJ, Brasil. CNPq e ICAD. Magalhães (2006). O que esperar da internet nos próximos anos? Disponível em [ Acessado 04 de Abril 2006 ]. Owens, M. (2006). The Definitive Guide to SQLite. Apress. Project, P. (2009). Persitent Browser-Based Game - Defining a genre. Disponível em [ Acessado 10 de Março de 2009 ]. Rabin, S. (2000). The magic of data-driven design. In Game Programming Gems, pages 3 7. River Media. Sommerville, I. (2003). Engenharia de Software. Prentice Hall, 6th edition. 89

94 Um Protótipo para a Simulação do Acionamento dos Preventores de Erupção em Poços Petrolíferos Luiz Cláudio N. da Silva 2, Thalles R. Barbalho 1, Marcelino P. S. Silva 1, Elson A. N. de Medeiros 3 1 Departamento de Informática Universidade do Estado do Rio Grande do Norte (UERN) BR Km 46, Bairro Pres. Costa e Silva, CEP , Mossoró - RN 2 Núcleo Tecnológico em Engenharia de Software Universidade Federal Rural do Semi-Árido (UFERSA) BR Km 47 Bairro Pres. Costa e Silva, CEP , Mossoró - RN 3 Petróleo Brasileiro S.A. (PETROBRAS) Estrada do Contorno, Bairro Alto do Sumaré BR Km 46,CEP , Mossoró - RN Abstract. Oil production is growing in Brazil and so is the risk associated with operations involved in this activity. In this scenario, the investment in equipment is important to ensure safety maximization of human resources and productivity. One of such equipment is the Blowout Preventer (BOP), which purpose is to maintain security in the well by allowing it to close in the occurence of an eruption (blowout). It is necessary to propose models that simulate this behavior and test unusual situations without the use of real equipment. This paper proposes a prototype for the activation simulation of these eruption preventers. Resumo. A produção de petróleo vem crescendo no Brasil e com ela os riscos associados às operações envolvidas na sua exploração. Neste cenário é importante o investimento em equipamentos que garantam a maximização da segurança dos recursos humanos envolvidos aliado à alta produtividade. Um desses equipamentos é o Blowout Preventer (B.O.P), cuja finalidade é manter a segurança no poço, permitindo fechar o mesmo na possível ocorrência de uma erupção, isto é, um blowout. Torna-se necessário propor modelos que simulem esse comportamento permitindo que situações incomuns possam ser testadas sem o uso do sistema real. A pesquisa emerge com a proposta de um protótipo para a simulação do acionamento desses preventores de erupção. 1. Introdução Muitas companhias possuem, atualmente, a exploração de petróleo como sua atividade principal. Para garantir uma operação não só lucrativa, mas também segura, as empresas utilizam-se dos equipamentos de segurança de cabeça de poço, do qual faz parte o Blowout Preventer (BOP). Esse equipamento é acionado quando existe o risco de uma erupção e sua função principal é a de fechar o poço, não permitindo que fluidos surjam na superfície em alta pressão. Para efetuar esse acionamento, existe o sistema de controle do 90

95 BOP, o qual pode utilizar tanto garrafas de nitrogênio, como bombas elétricas ou mesmo pneumáticas. É de fundamental importância que as pessoas envolvidas nesse trabalho conheçam o funcionamento desse sistema de controle diante de situações excepcionais que possam vir a acontecer. Com esse objetivo, simuladores são utilizados, uma vez que apresentam uma forma mais segura e financeiramente viável de se testar como o equipamento trabalha, poupando assim o sistema real para que o mesmo não venha a ser danificado. O presente trabalho trata do desenvolvimento de um protótipo de simulador para acionamento desses preventores através de garrafas de nitrogênio. Os cálculos implementados no protótipo estão sendo baseados em um manual específico do sistema de controle de acionamento de BOP desenvolvido pela empresa Koomey Inc. [koo 1984]. 2. Preventor de Erupções Existem dois métodos de controle ou barreiras para prevenção de erupções: o fluido de perfuração e o sistema de segurança, o qual é o composto pelos Equipamentos de Segurança de Cabeça de Poço (ESCP). O fluido de perfuração tem, como um dos objetivos principais, o controle primário do poço, isto é, exercer uma pressão maior que a pressão exercida pelos fluidos da formação, a qual é exercida no sentido contrário. Caso aquela pressão seja menor, o controle do poço será perdido [Belém 2008a]. Nesse caso, o sistema de controle deverá atuar e garantir que não haverá uma erupção na superfície do poço. O ESCP tem como elementos principais a cabeça do poço e os preventores, ou, como é mais conhecido, o BOP (Blowout Preventer) [Belém 2008b]. Um sistema de controle de BOP contém uma série de equipamentos. Dentre eles, deve-se destacar: Conjunto da unidade acumuladora Conjunto de bombas de ar Conjunto de bombas elétricas Painel de controle remoto a ar Preventores A Figura 1 mostra um esquema simplificado de um conjunto BOP composto por um preventor anular e dois preventores de gaveta. A função principal da unidade acumuladora é prover o suprimento de fluido hidráulico para as bombas e o armazenamento de fluido de operação sob alta pressão para o controle do conjunto de preventores [koo 1984]. O protótipo considera um dos componentes dessa unidade acumuladora, o Acumulador, que é responsável por armazenar o fluido hidráulico sob alta pressão. Os preventores podem ser definidos como [...] válvulas de grande porte cuja finalidade é fechar o poço em situações de erupções que nele venham ocorrer [Belém 2008b]. Há diversos tipos de preventores, os quais são utilizados de acordo com cada situação específica. O primeiro deles é o preventor anular, que consiste em uma válvula de grande porte capaz de fechar o poço independentemente da presença de coluna em seu interior. Logo abaixo podem ser visualizados os preventores de gaveta, cujo funcionamento 91

96 Figura 1. Arranjo típico de um conjunto BOP onshore. Adaptado de [Thomas 2004] consiste em [...] dois pistões que, ao serem acionados hidraulicamente, deslocam duas gavetas, uma contra a outra, transversalmente ao eixo do poço [Thomas 2004]. Esse mecanismo faz com que o espaço anular seja fechado, isolando assim as pressões que surgem da formação. Os preventores de gaveta cega, vazada e cisalhante formam os três tipos de preventor de gaveta disponíveis no modelo de simulação [Belém 2008b]. A gaveta cega é usada para o fechamento do poço sem ferramenta em seu interior. Já na gaveta vazada a vedação se dá com o contato das duas gavetas com o corpo da coluna de perfuração. Por sua vez, a gaveta cisalhante, como o próprio nome sugere, tem a função de cortar a coluna ao mesmo tempo em que promove a vedação desta, ou mesmo funcionar como gaveta cega na ausência de coluna de perfuração. A Tabela 1 mostra um cenário hipotético de um conjunto BOP considerando um preventor anular, dois preventores de gaveta vazada e um preventor de gaveta cega. Tabela 1. Dados para o dimensionamento do volume do Acumulador Consultando a tabela pode-se conhecer a quantidade, os tipos de preventores e o número de galões de fluido hidráulico pressurizado exigido por cada um deles. Deste modo, é possível calcular o total de galões suficientes para fechá-los, bem como o volume total do Acumulador. O funcionamento do protótipo simula o escoamento do fluido hidráulico do sistema acumulador em direção aos preventores, informando a pressão e o volume no acumulador a cada segundo após o acionamento do sistema. 3. O Protótipo Analisando as propriedades e relacionamentos entre os elementos físicos do sistema real, pode-se definir, para cada elemento descrito, uma classe com métodos e atributos que representem seu comportamento real. Essas classes podem ser demonstradas pelo diagrama 92

97 de classe UML (Unified Modeling Language). Os preventores Anular, Gaveta Cega, Gaveta Vazada e Gaveta Cisalhante tem essencialmente os mesmos métodos e atributos. Em um nível de abstração superior, podemos representá-los através de uma única classe abstrata, a qual denominamos Preventor, conforme podemos ver na Figura 2. Figura 2. Classe Preventor Essa figura mostra um diagrama de classe UML que representa a classe abstrata Preventor, a qual não pode ser instanciada e deve ser especializada por tipo de preventor previsto na simulação. Esta especialização permite que as características específicas de cada preventor sejam definidas, no caso, a quantidade de fluido necessário para o fechamento e o nome do preventor. Cada uma dessas classes especializadas apresenta dois construtores sobrecarregados, sendo o primeiro um construtor padrão e sem argumentos que permite ao preventor ser inicializado com valores padronizados previstos no manual da Koomey [koo 1984], enquanto o segundo permite que esse preventor receba valores redefinidos. A classe Acumulador deve prover métodos e atributos que representem as propriedades reais de um acumulador. O volume total do acumulador para um sistema de controle de BOP de psi deve ser dimensionado para fechar totalmente o anular e todos os preventores de gaveta com bombas fora de serviço, mantendo um mínimo de psi de pressão de operação. Um adicional de 50% de fator de segurança é exigido para compensar qualquer perda de fluido no sistema de controle ou nos preventores [koo 1984]. Para o protótipo desenvolvido decidiu-se adotar apenas linguagem e ferramentas Java, principalmente pela sua portabilidade entre plataformas [Deitel and Deitel 2005]. Deste modo, o protótipo tende a ser facilmente distribuído e utilizado por terceiros, não necessitando de nenhuma configuração ou bibliotecas adicionais além da JRE (Java Runtime Environment). O protótipo do simulador consiste em uma aplicação gráfica, a qual aceita vários parâmetros de entrada e apresenta resultados da simulação através de uma tabela na própria interface e de gráficos gerados na aplicação utilizando a biblioteca Java Jfree- Chart. Essa biblioteca é livre e totalmente escrita em Java, suporta vários tipos de gráficos como pizza (2D e 3D), gráficos de barra horizontais e verticais, gráficos de linhas, séries de tempo e muito mais. O JfreeChart pode ser usado em aplicações como applets, servlets e páginas JSP (Java Server Pages), além de aplicações desktop [JFreeChart 2009]. A aplicação provê o recurso de geração de relatórios utilizando outra biblioteca 93

98 de classes Java, a JasperReports. Tal biblioteca é usada para a geração de relatórios que permitem a impressão ou a criação de arquivos em diversos formatos, dentre eles PDF, HTML, ODT e XML. Esta biblioteca é escrita inteiramente em Java e pode ser usada para gerar conteúdo dinâmico [Danciu and Chirita 2007]. A integração entre essas ferramentas ao protótipo de simulador permite que os dados relativos a uma determinada simulação possam ser persistidos em documentos nos formatos citados. 4. Resultados Utilizando os dados da Tabela 1 inseridos no protótipo podemos chegar ao resultado mostrado na Figura 3. Figura 3. Gráfico mostrando a pressão nos acumuladores em função do tempo A Figura 3 (extraída da interface do protótipo) mostra o resultado da simulação para os dados de entrada inseridos no painel ao lado esquerdo. É possível configurar vários parâmetros da simulação, dentre os quais: a quantidade de cada tipo de preventor utilizado na simulação, o tempo máximo de fechamento do conjunto de preventores e como ocorrerá a perda de fluído (se fixa ou aleatória). Entretanto, por questões de testes de verificação do algoritmo, o protótipo considera apenas uma vazão perfeita. O gráfico gerado apresenta a diminuição da pressão (em psi) ao longo do tempo nos acumuladores, considerando, para tanto, uma vazão ideal. Além do gráfico descrevendo a pressão dos acumuladores pelo tempo, o protótipo dispõe de um gráfico mostrando a diminuição do volume do fluído hidráulico dos acumuladores também em função do tempo. 5. Conclusões e Trabalhos Futuros Este trabalho propôs um protótipo para a simulação do acionamento dos preventores de erupção em poços petrolíferos. Foi apresentado um aplicativo Java capaz de prever o 94

99 comportamento quanto ao fechamento do conjunto BOP para os parâmetros de entrada informados, bem como recursos para a visualização desse comportamento, através de gráficos e relatórios. O protótipo apresenta algumas limitações, pois o algoritmo principal de simulação está considerando que todos os preventores fecham ao mesmo tempo, o que não é um comportamento ideal. Na prática é preciso determinar individualmente a ordem de fechamento dos preventores. Além disso, outras variáveis e aspectos do protótipo deverão ser avaliados e contemplados em versões futuras, cujo algoritmo resolverá estas e outras questões. Uma vez que o algoritmo tenha sido aperfeiçoado, os relatórios gerados pela aplicação podem apresentar algumas informações extras, como o tempo de fechamento individual de cada preventor e o volume de fluido utilizado para o fechamento. Quando o protótipo de simulação tender a um estado final de produto, é sugerida a utilização do mesmo para finalidade de treinamento de pessoal. Esse estado será atingido quando o simulador puder prever, além do fechamento dos preventores por garrafas de nitrogênio, o uso de bombas elétricas e pneumáticas, inclusive individualmente. Agradecimentos Os autores agradecem ao CNPq pelo suporte a esta pesquisa. Referências (1984). Operation and Maintenance for BOP Control System: Manual and/or Air Remote Operation for Land Based Drilling Rigs. Texas. Belém, F. A. T. (2008a). PROMINP: Operador de Sonda de Perfuração. Controle de Poço I. PETROBRAS, Mossoró, RN. Belém, F. A. T. (2008b). PROMINP: Operador de Sonda de Perfuração. Controle de Poço II. PETROBRAS, Mossoró, RN. Danciu, T. and Chirita, L. (2007). A Definitive Guide to JasperReports (Expert s Voice). Apress Berkely, CA, USA. Deitel, H. M. and Deitel, P. J. (2005). Java How to Program. Pearson Prentice Hall, Nova Jersey, 6th edition. JFreeChart (2009). Welcome to jfreechart.org. Acesso em: 19/08/2009. Thomas, J. E. (2004). Fundamentos de Engenharia de Petróleo. Interciência, Rio de Janeiro, RJ, 2nd edition. 95

100 Técnicas de Sistemas de Gerenciamento de Banco de Dados em Tempo-Real para Redes de Sensores sem Fio Luana D. Chagas 1, Eduardo P. Lima 1, Pedro F. R. Neto 1 1 Departamento de Informática Universidade do Estado do Rio Grande do Norte (UERN) CEP: Mossoró RN Brasil Abstract. One of the challenges Wireless Sensor Networks face is the treatment of the storage and querying of the data they process. Most of the techniques currently used usually store the data in a central database and then query it. These techniques generate a large flow of data, since each sensor sends information through the same channel. An alternative to reduce this flow is to make the devices act as local databases. This approach is called distributed. The data represent the current state of the environment, therefore they are subject to time constraints. In this paper, we propose the use of Real Time Databases techniques to Wireless Sensor Networks that use a distributed approach, so that time constraints are considered. Resumo. Um desafio das Redes de Sensores sem Fio é tratar o armazenamento e consulta dos dados. As técnicas atualmente utilizadas visam armazenar os dados em um banco de dados central para então realizar consultas neste. Estas geram um grande fluxo de dados, uma vez que cada sensor manda informações. Uma alternativa para diminuir esse fluxo é fazer com que os dispositivos atuem como banco de dados locais. Esta abordagem é denominada distribuída. Os dados adquiridos pelos sensores representam o estado atual do meio e, portanto, possuem validade temporal. Neste trabalho, é proposto o uso de técnicas de Banco de Dados em Tempo-Real em Redes de Sensores sem Fio que utilizam a abordagem distribuída, de forma que restrições de tempo sejam consideradas. 1. Introdução As Redes de Sensores sem Fio definem-se por um conjunto de dispositivos, denominados sensores, capazes de detectar características do meio ao qual estão inseridos. Estes dispositivos coletam dados de forma a atender um usuário final, que está interessado no monitoramento e controle de algum fenômeno. Para obter informações, o usuário faz uso de aplicativos que se comunicam com as redes realizando consultas [Pereira et al, 2003]. Os ambientes monitorados pelas Redes de Sensores sem Fio envolvem diversas áreas, tais como indústria, construção civil, agricultura e monitoramento de florestas e oceanos [Vieira et al, 2003]. A realização do monitoramento de ambientes acontece por meio da percepção de mudanças das condições físicas do meio realizada pelos sensores [Pereira et al, 2003]. A interação contínua entre os dispositivos da rede e o meio ambiente resulta na aquisição de grandes volumes de dados. No entanto, os dispositivos possuem uma capacidade de armazenamento restrita, não sendo possível armazenar grandes quantidades de dados 96

101 neste [Silva, 2004]. Uma vez adquiridos, os dados são periodicamente enviados para um repositório central, na qual é possível realizar consultas neste. O armazenamento e consulta desses dados pode ser realizado por meio de duas abordagens: warehousing e distribuída. Na abordagem warehousing, os dados são enviados para um servidor de banco de dados e as consultas são realizadas neste servidor. A abordagem distribuída considera os dispositivos como parte do banco de dados, assim, eles atuam como um banco de dados local, sendo capazes de processar consultas [Ribeiro Neto, 2008]. A consulta diretamente no dispositivo evita que grandes fluxos de dados sejam enviados pela rede. Os dados adquiridos pelas Redes de Sensores sem Fio devem representar o estado atual do meio ambiente. Os ambientes, no entanto, estão sujeitos a sofrerem constantes mudanças. Dessa forma, os dados adquiridos possuem uma validade temporal, pois não se pode garantir que o estado do meio ambiente permanecerá sempre o mesmo. É interessante, então, que as respostas às consultas realizadas pelo usuário garantam que os dados estejam dentro de restrições lógicas e temporais. Nesse contexto, o uso de banco de dados em tempo-real são uma possível solução para o tratamento dessas restrições. O presente trabalho tem por objetivo propor técnicas dos Sistemas de Gerenciamento de Banco de Dados em Tempo-Real em Redes de Sensores sem Fio que utilizam uma abordagem de armazenamento de dados distribuída. 2. Redes de Sensores sem Fio As Redes de Sensores sem Fio (RSSF) vêm conquistando um reconhecido espaço no mundo atual por apresentar a possibilidade de interação automatizada com ambientes que, até então, para serem monitorados necessitariam ser observados por meio da presença humana, tais como indústria, agricultura, florestas e oceanos. As Redes de Sensores sem Fio (RSSF) constituem-se em um tipo de redes adhoc [Corrêa et al, 2006], sendo definidas como um conjunto de dispositivos, denominados sensores, capazes de detectar características do meio ao qual estão inseridos [Pereira et al, 2003]. As RSSF possuem carcaterísticas peculiares que as diferem de outros tipo de redes sem fio: são centradas a dados e aplicações; os nós da rede, de forma geral, possuem as mesmas características de processamento e comunicação; tipicamente o número de nós é bastante grande; a topologia da rede muda com frequência; os nós da rede podem não ter um identificador global; a rede pode crescer até um tamanho arbitrariamente grande [Corrêa et al, 2006],[Akyildiz et al, 2002]. Os nós da rede são considerados inteligentes e possuem quatro unidades básicas: sensoriamento, comunicação, alimentação de energia e processamento. A unidade de sensoriamento é responsável por detectar as mudanças físicas que ocorrem no meio ambiente e é composta por diversos sensores, que irão de acordo com a aplicação para a qual a rede foi proposta. A unidade de comunicação provê a interação entre os nós da rede por meio de um canal de comunicação sem fio. A unidade de alimentação de energia alimenta o nó da rede por meio de uma bateria. E a unidade de processamento é composta por aplicativos, um microcontrolador, um conversor analógico-digital e uma memória [Akyildiz et al, 2002]. Os protocolos e outros aplicativos presentes nos nós da rede precisam considerar a 97

102 quantidade de energia consumida durante atividades de processamento ou comunicação. Quando a energia de um sensor é esgotada, este morre e deixa de compor a rede. Uma vez que os nós sensores nem sempre ficam fixos e/ou em locais acessíveis é inviável a recarga de energia dos nós. Assim, a economia de energia é uma tarefa de grande importância [Vieira et al, 2003]. 3. Sistemas de Gerenciamento de Banco de Dados em Tempo-Real Os Sistemas de Gerenciamento de Banco de Dados em Tempo-Real (SGBD-TR) definemse pela união de características de Sistemas de Tempo-Real (STR) com Sistemas de Gerencimento de Banco de Dados (SGBD) convencionais [Fernandes, 2005]. Dessa forma, eles devem atender as condições impostas pelos SGBD de garantir restrições lógicas, bem como as condições provenientes dos Sistemas de Tempo-Real de garantir restrições temporais. Para garantir as restrições lógicas, as transações devem atender as propriedades ACID (Atomicidade, Consistência, Isolamento e Durabilidade), que foram redefinidas para SGBD-TR. A propriedade de Atomicidade garante que ou tem-se uma execução completa ou não tem-se nenhuma execução. Ela é imposta não a transação completa, mas às subtransações. A propriedade de Consistência amplia o estado consistente do banco, permitindo que valores próximos do real sejam considerados corretos. A propriedade de Isolamento permite que transações sejam vistas por outras antes de seu término, se isto fizer com que elas atendam as restrições temporais. A propriedade de Durabilidade diz que o Banco de Dados deve refletir o estado atual do meio, não sendo necessário recriá-lo na ocorrência de uma falha, mas sim com a aquisição dos novos dados. No que se refere a restrições temporais, os dados dos banco de dados desses sistemas, denominados de Banco de Dados em Tempo-Real, devem representar o estado corrente do meio no qual eles foram coletados. A estrutura desses dados deve indicar que sua validade temporal é limitada por um intervalo de tempo [Leite, 2005]. Devem fazer parte dessa estrutura os atributos: intervalo de validade absoluta (avi), que determina por quanto tempo o dado é válido após sua inserção no banco; e o rótulo de tempo, que indica o momento em que o dado foi inserido no banco de dados. Outro atributo importante a ser considerado é a imprecisão, que refere-se a quão diferente o dado pode ser do seu correspondente no meio em que ele foi coletado. Esses atributos permitem que as restrições de tempo dos dados sejam consideradas. As transações também possuem características para que restrições de tempo sejam consideradas para elas. Cada transação deve possuir quatro atributos: tempo de liberação, tempo computacional, prazo máximo e periodicidade. O tempo de liberação refere-se ao momento na qual todos os recursos necessários para a execução da transação estão disponíveis. O tempo computacional caracteriza-se pelo tempo de processamento necessário para a execução da transação. O prazo máximo indica o limite de tempo para a execução da transação ocorrer. A periodicidade trata-se da frequência com que a transação ocorre. 4. Abordagens de Armazenamento e Consulta de Dados Segundo Ribeiro Neto (2004), as atividades de comunicação consomem maior quantidade de energia do que atividades de processamento, fato que torna interessante a idéia de substituir comunicações entre os nós da rede por processamento local. Dessa forma, a 98

103 abordagem adotada no que se refere ao armazenamento e envio dos dados coletados pelos sensores pode ser considerada um dos fatores de influência no tempo de vida útil das RSSF. Há duas abordagens para o armazenamento e consulta dos dados: warehousing e distribuída. Na abordagem warehousing a rede atua como um coletor de dados. Os nós da rede são programados para enviar seus dados que, por sua vez, irão ser armazenados em um servidor de banco de dados. As consultas são realizadas nesse servidor. Já na abordagem distribuída, os dispositivos atuam como um banco de dados local. Dessa forma, tem-se dados armazenados no servidor de banco de dados central e nos próprios dispositivos da rede, sendo possível realizar consultas em ambos [Ribeiro Neto, 2008]. Para que os dispositivos atuem como banco de dados locais, faz-se necessário que aplicativos estejam presentes neles para gerenciar o armazenamento, bem como responder à solicitações de acesso aos dados. As consultas realizadas na rede podem ser definidas de três maneiras: de dados históricos, na qual a consultas são realizadas no servidor; instantâneas, que referemse a consultas realizadas em um dispositivo em um certo instante de tempo; e longas, que tratam-se de consultas realizadas em um dispositivo durante um intervalo de tempo [Ribeiro Neto, 2004]. A abordagem warehousing é a mais adotada [Ribeiro Neto, 2006]. No entanto, esta apresenta algumas desvantagens, tais como o desperdício de recursos, uma vez que um grande volume de dados é enviado para o servidor, mas nem sempre todos eles são relevantes. A abordagem distribuída então, traz as vantagens de permitir o processamento local: a consulta no próprio dispositivo diminui o fluxo de dados na rede, o que pode levar ao aumento do seu tempo de vida útil [Ribeiro Neto, 2004]. 5. Banco de Dados em Tempo-Real para Redes de Sensores sem Fio As técnicas para armazenar e consultar os dados devem ser o mais eficiente possível. No entanto, as técnicas adotadas atualmente, na qual banco de dados comerciais vêm sendo adaptados para as Redes de Sensores sem Fio, não são adequadas, pois não suportam as propriedades ACID dos bancos de dados e não garantem as restrições temporais dos dados e transações [Ribeiro Neto, 2004]. Este trabalho propõe utilizar técnicas de Sistemas de Gerenciamento de Banco de Dados em Tempo-Real nas Redes de Sensores sem Fio que adotem a abordagem de armazenamento e consulta de dados distribuída. A proposta consiste em implementar as técnicas nos nós da rede, de forma que estes sejam capazes de processar consultas considerando restrições de tempo. Os nós também são programados para enviar periodicamente seus dados coletados para o servidor de banco de dados centralizado. Este também possui técnicas de SGBD-TR implementadas. Para a criação da rede foi utilizado o aplicativo Solarium [Sun Microsystems]. Este trata-se de um emulador para SunSPOT, dispositivos sensores desenvolvidos pela Sun Microsystems [Sun Microsystems]. O emulador pode ser adquirido juntamente com o SDK (Software Development Kit) do SunSPOT, disponível gratuitamente no site do projeto. Por meio de uma API (Application Programming Interface) são disponibilizados diversos métodos escritos na linguagem de programação Java. O Solarium reproduz funções que os dispositivos reais fornecem, tais como nível de luminosidade, temperatura, tensão de entrada analógica e comunicação por rádio [Sun Microsystems]. Para 99

104 estes dispositivos foi desenvolvido um aplicativo com funções para adquirir o valor da temperatura e para que estes sejam capazes de processar consultas advindas do usuário e consigam enviar respostas a estas. Além disso, foram implementadas funções para que os dados adquiridos sejam enviados para um repositório de dados a cada certo período de tempo. Para armazenar os dados adquiridos pelos sensores virtuais foi utilizado o SGBD de código aberto PostgreSQL, desenvolvido pela Universidade de Berkley, Califórnia, Estados Unidos [PostgreSQL]. Com o intuito de garantir que os dados possam ter suas restrições temporais consideradas, foram adicionados a sua estrutura os atributos intevalo de validade absoluta, rótulo de tempo e imprecisão. As consultas aos dispositivos e ao servidor são realizadas utilizando a linguagem de consulta denominada Linguagem de Consulta para Aplicações em Tempo-Real (LC- BDTR) [Leite, 2005]. Esta provê primitivas de tempo-real que são combinadas com comandos da linguagem SQL (Structured Query Language), fornecendo uma sintaxe para declarações de consultas em tempo-real. Exemplos dessa sintaxe são as instruções INI- TIALIZE AT e TEMINATE AT, que indicam o tempo em que a transação deve iniciar e terminar sua execução, respectivamente. Para a implementação da linguagem de consulta foi desenvolvido um interpretador de comandos, que recebe os comandos enviados pelos usuários e interpreta-os, chamando os métodos adequados para cada primitiva. Para a consulta diretamente no dispositivo foi adiciona à LC-BDTR uma instrução denominada SENSOR, cuja sintaxe é o nome da instrução seguida de um parâmetro, que indica o endereço do sensor na qual o usuário deseja consultar. Em Algoritmo 1 é mostrada a sintaxe da instrução SENSOR: Algorithm 1 Sintaxe da instrução SENSOR SENSOR <parâmetro> Uma vez que mais de um usuário pode estar acessando os dados armazenados no servidor de banco de dados ou no dispositivo, faz-se necessário um protocolo de controle de concorrência. Este tratará os casos em que transações executadas concorrentemente podem levar a anomalias, tais como dados inconsistentes no banco. Podemos chamar essas transações como conflitantes. O protocolo utilizado foi definido em [Ribeiro Neto, 2006]. Neste, as transações são classificadas em leitura ou escrita e possuem as características tempo de liberação, tempo computacional, prazo máximo e periodicidade. Tais características permitem que as restrições de tempo sejam tratadas. As transações de escrita podem ser provenientes dos dispositivos da rede ou do usuário. A técnica de controle de concorrência implementada visa permitir a execução de transações conflitantes concorrentemente de forma que o resultado do escalonamento entre elas não ultrapasse a imprecisão associada ao dado. Quando uma transação está executando e uma transação conflitante deseja executar sobre o mesmo objeto do banco de dados, seu primeiro passo consiste em verificar os parâmetros temporais da transação que deseja executar. Se esta é válida temporalmente, avalia-se os parâmetros lógicos. Caso estes também sejam válidos, a transação poderá ser executada. Se a transação não atende alguma das avaliações ela pode ser abortada ou esperar para que tente novamente ser executada caso suas restrições de tempo permitam a espera. A execução concorrente das 100

105 transações, por sua vez, trará uma imprecisão para o objeto do banco de dados nas quais as transações estão atuando. As imprecisões provenientes das transações, bem como as imprecisões escritas nos itens de dados devem ser acumuladas em tempo de execução. Em Algoritmo 2 podemos verificar o pseudocódigo da técnica de controle de concorrência trabalhada: Algorithm 2 Pseudocódigo da técnica de controle de concorrência Verifica-se se as operações são da mesma transação if verdadeiro then As operações são executadas normalmente else Verifica-se se as transações operam sobre o mesmo objeto de dado if verdadeiro then Os parâmetros temporais são avaliados if Verdadeiro then Os parâmetros lógicos são avaliados if Verdadeiro then Imprecisão atualizada else Transação abortada ou em espera end if else Transação abortada ou em espera end if else Nenhuma função é chamada end if end if A união dos componentes acima definidos resultou no desenvolvimento do aplicativo BDSensor. Ele foi desenvolvido utilizando a linguagem de programação Java e consiste em uma interface que se comunica com o usuário de forma a receber solicitações de consultas e exibir resultados; um interpretador de comandos, que interpreta os comandos enviados pelo usuário na solicitação da consulta; um aplicativo que conecta-se ao servidor de banco de dados e aos dispositivos sensores; e os aplicativos presentes no servidor e nos dispositivos que respondem à consultas e tratam o acesso concorrente. Ao solicitar uma consulta, o usuário utiliza a LC-BDTR. A consulta é interpretada e verifica-se se ela é direcionada a algum sensor ou ao servidor de banco de dados central. Se pretende-se adquirir dados provenientes dos dispositivos sensores, utiliza-se a instrução SENSOR. Caso seja direcionada ao servidor, verifica-se se há outras consultas para o mesmo objeto de dados. Se houver, a técnica de controle de concorrência é chamada. Se não há outras consultas, se estabelece uma conexão com o banco de dados e realiza-se a consulta, retornando o resultado para o usuário. Quando a consulta é direcionada a algum sensor, envia-se um pacote com a consulta para o dispositivo. Um aplicativo presente no sensor verifica se há outras consultas tentando executar no mesmo ou se no mesmo instante de tempo não estão sendo adqui- 101

106 ridos do meio ambiente. Se houver, a concorrência é tratada. Se esta condição não é atendida, o dispositivo envia o resultado da consulta, o aplicativo BDSensor a recebe e exibe o resultado para o usuário. 6. Conclusão A área de Redes de Sensores sem Fio constitui um campo de grandes possibilidades de pesquisa, na qual tem-se novas e amplas perspectivas no que se refere ao monitoramento de ambientes, como também novos desafios [Ruiz, 2004], [Yua, 2006]. Dentre esses desafios encontra-se técnicas para tratar o armazenamento e consulta dos dados coletados pela rede. Neste trabalho foi sugerido utilizar técnicas de Sistemas de Gerenciamento de Bancos de Dados em Tempo-Real em Redes de Sensores sem Fio que utilizam a abordagem de armazenamento e consulta de dados distribuídos. Dessa forma, os dados podem ser consultados diretamente no nó da rede e não somente de modo offline como feito na abordagem warehousing, na qual os dados são enviados para um servidor de banco de dados e as consultas são feitas somente neste. Como os nós gastam mais energia comunicando-se uns com os outros do que realizando processamento local [Ribeiro Neto, 2004], a possibilidade de coletar a informação diretamente no dispositivo pode levar a um menor gasto de energia, aumentando o tempo de vida útil da rede. Outra consideração a ser fazer sobre a abordagem distribuída é o fato dela permitir consultas instantâneas e longas, que são realizadas no dispositivo em um certo instante de tempo e que são realizadas no dispositivo durante um intervalo de tempo, respectivamente. Os dados das Redes de Sensores sem Fio representam o estado atual do meio que está sendo monitorado. Isso significa que os dados possuem uma validade temporal. O uso de Banco de Dados em Tempo-Real permite tratar essa característica. Atributos relacionados ao tempo são associados aos dados e transações, assim, as restrições temporais destes podem ser tratadas. Como resultado desse trabalho tem-se uma Rede de Sensores sem Fio virtual cujo nós estão programados para receber consultas de usuários bem como enviar seus dados coletados a um sistema de banco de dados central. Tanto o servidor quanto os dispositivos são programados de forma a tratar o acesso concorrente. Para que o usuário possa ter acesso aos dados coletados na rede, foi desenvolvido um aplicativo, denominado BDSensor, que oferece uma interface na qual o usuário pode realizar uma consulta. O aplicativo se comunica com o servidor de banco de dados ou com o dispositivo, dependendo do que o usuário solicitou na sua consulta, e exibe a informação por estes retornada. Como trabalhos futuros, pretende-se implememtar as técnicas de Sistemas de Gerenciamento de Banco de Dados em Tempo-Real propostas em dispositivos reais e com isto realizar testes comparativos com outras Redes de Sensores sem Fio. 7. References Referências Akyildiz, I., Su, W., Sankarasubramaniam, Y., and Cayirci, E. (2002). A survey on sensor networks. In IEEE communications magazine, v. 40, p

107 Corrêa, U., Pinto, A., Codas, A., Ferreira, D., and Montez, C. (2006). Redes Locais Sem Fio: Conceitos e Aplicações. In IV Escola Regional de Redes de Computadores. Passo Fundo, Brasil, v. 1, p Fernandes, Y. Y. M. P. (2005). Técnica de controle de concorrência semântico para sistemas de gerenciamento de banco de dados em tempo-real. Dissertação. (Programa de Pós-Graduação em Engenharia Elétrica) Universidade Federal de Campina Grande, Campina Grande. Leite, R. M. L. (2005). Linguagem de consulta para aplicações em tempo-real. Dissertação. (Programa de Pós-Graduação em Engenharia Elétrica) Universidade Federal de Campina Grande, Campina Grande. Sun Microsystems. Solarium. Disponível em: https://solarium.dev.java.net/. Pereira, M., Amorim, C., and Castro, M. (2003) Tutorial sobre redes de sensores. Cadernos do IME. Série Informática, Rio de Janeiro, v. 14, p PostgreSQL. PostgreSQL: The world s most advanced open source database. Disponível em: Ribeiro Neto, P., Fernandes. Y., Mendes Neto, M., Leite, C. and Costa, C. (2008). Rede de Sensores: O Estado da Arte. In EPOCA - Escola Potiguar de Computação e suas Aplicações. Ribeiro Neto, P. F. (2006). Mecanismos de Qualidade de Serviços para o Gerenciamento de Dados e Transações em Tempo-Real. Tese. (Programa de Pós-Graduação em Engenharia Elétrica) Universidade Federal de Campina Grande, Campina Grande. Ribeiro Neto, P., Perkusich, M., and Perkusich, A. (2004). Real-Time Database for Sensor Networks. In 6th International Conference on Enterprise Information Systems. Ruiz, L., Correia, L., Vieira, L., Macedo, D., Nakamura, E., Figueiredo, C., Vieira, M., Bechelane, E., Camara, D., Loureiro, A., Nogueira, J., Silva Júnior, D. and Fernandes, A. (2004). Architecture for Wireless Sensor Network. In SBRC Tutorial. Silva, F., Braga, T., Ruiz, L. and Nogueira, J. (2004). Tecnologia de Nós Sensores Sem Fio. In Controle & Instrumentação, v. 92, p Vieira, M., Coelho Junior, C., Silva Junior, D., and Mata, J. (2003) Survey on wireless sensor network devices. In Emerging Technologies and Factory Automation, Lisboa. Proceedings of the Emerging Technologies and Factory Automation. v.1, p Yua, L., Chen, W., and Xi, Y. (2006). A Review of Control and Localization for Mobile Sensor Networks. In Intelligent Control and Automation. WCICA

108 Uma Solução para a Recepção de Vídeos em WLANs com Mobilidade Limitada Claudio de Castro Monteiro 1, Paulo Roberto de Lira Gondim 2 1 IFTO Instituto Federal de Educação, Ciência e Tecnologia do Tocantins, Departamento de Computação, Brasil 2 UnB - Universidade de Brasília, Faculdade de Tecnologia, Departamento de Engenharia Elétrica, Brasil s: Resumo. Handoff entre pontos de acesso distribuídos em uma rede IEEE (WLAN) pode ser uma fonte de problemas consideráveis no cenário de transmissão de vídeo. A qualidade visual de aplicações de vídeo streaming é muito reduzida quando os usuários se movem de um acess point para outro. Neste trabalho, apresentamos uma arquitetura de um Proxy de Sessão (PS), que tenta preservar a qualidade de streaming de vídeo a cada handoff entre pontos de acesso. Nós avaliamos os limiares de RSSI e da Taxa de Perda de Frame (TPF) para decidir o momento exato para que a estação inicie o handoff. O desempenho de nossa solução foi avaliada em um ambiente de testes com suporte à distribuição de vídeo sob demanda, usando o padrão MPEG 4. Nesse ambiente foram montados um servidor de vídeo (VLS) e dois pontos de Acesso baseados em FreeBSD, com suporte a IP móvel, DHCP Server e abordagem IAPP. Abstract. Handoffs between access points in a distributed IEEE Wireless LAN network can be a source of considerable problems on video transmission scenery. This visual quality of streaming video applications is very reduced when users move of a acess point to other. In this paper we introduce an architecture of an Session Proxy Switch (SPS), which tries to preserve the quality of streaming video upon each handoff between access points. We have evaluated thresholds of RSSI and Loss Frame Rate (LFR) for decide the handoff process begin. The our solution performance was evaluated in a test bed implementation for MPEG 4 video ondemand with one video server (VLS) and two acess points FreeBSD based, which Mobile IP configuration, DHCP Server and IAPP approach. 1. Introdução O foco do nosso trabalho é preservar o streaming de vídeo em tempo real durante o processo de handoff entre dois pontos de acesso. No entanto, no caso de uma entrega entre dois pontos de acesso WLAN, uma rajada de perda de pacotes ocorre e o nó móvel não é capaz de preservar a qualidade visual. Por este motivo, optamos por analisar também a Taxa de Perda de Frame (TPF), tentando prever o início do processo de handoff do nó móvel. 2. Trabalhos Relacionados O problema causado na qualidade de vídeo pelo handoff entre pontos de acesso tem sido tratado por alguns trabalhos. No entanto, este problema foi dividido em duas partes: a parte que estuda formas de adaptar as WLANs para o tráfego de fluxos de vídeo, e a parte que estuda formas de adaptar o fluxo de vídeo às condições da infra estrutura de rede. Analisaremos os trabalhos que abordam os dois cenários. Todos os trabalhos estudados [1 10], tentam resolver os problemas de qualidade nos fluxos de vídeo em redes Alguns tentam testar tecnologias com IP móvel, outros tentam implementar IEEE f e recomendações r, outros ainda trazem novos conceitos como "Personal Address". Normalmente, as sessões de vídeo tem um tempo de sincronização que não suporta a latência do handoff entre dois pontos de acesso. Os estudos encontrados na literatura, 104

109 tratam esses problemas com técnicas que combinam a aplicação de tecnologias de IP móvel e IAPP, para entregar apenas o necessário ao nó móvel. Portanto, nossa solução é baseada no conjunto formado por técnicas de IP móvel, IAPP, AP e roteador com implemantação do SP. Este conjunto integrado de tenta resolver o problema de continuidade de sessão após o handoff entre APs, garantindo a qualidade da percepção do usuário ao receber o vídeo transmitido. 3. Proposta Na nossa proposta, sugerimos a inserção, na arquitetura da operadora sem fio, de dois componentes: um Proxy de Sessão (PS) e um ponto de acesso baseado em Freebsd com suporte a roteamento IP, servidor DHCP e funcionalidade IAPP. Na figura 1, pode ser visto esses componentes e suas ligações Funcionalidade A idéia principal é usar o PS para assegurar a continuidade da sessão, mesmo após longos períodos de descontinuidade da conexão, utilizando para isso, a previsão de handoff do MN, através dos limites definidos após amplos experimentos detalhados na sessão B e exibido em Tabela 1. Figura 1: Elementos propostos em nosso testebed Assim que o MN autentica e associa ao AP1, ele recebe um endereço IP dinamicamente através do servidor DHCP. Assim, O MN solicita abertura de sessão RTSP para o servidor de vídeo. O pedido será recebido pelo PS, registrado com a estrutura mostrada na Tabela 2 e em seguida, encaminhado para o servidor de vídeo, de acordo com algoritmo 1 abaixo. O servidor de vídeo, em seguida, abre uma sessão RTSP com o PS, que começará a receber os quadros, transferindo os para o AP1, que os entregará ao MN. Este processo continuará até o AP1 identificar que o nó móvel está chegando na zona de handoff (onde RSSI e LFR estão no nível BETA), começando então, o cache dos quadros e indicando ao PS que inicie o cache de quadros também. Neste ponto, os quadros armazenados no cache do AP1, são enviados ao nó móvel e os quadros armazenados em cache, no PS, são enviados ao AP1, utilizando a estrutura de dados apresentados na tabela 2. Quando o MN atingir o nível GAMA, o AP1 efetua o registo da sessão em seu cache, contendo o identificador do último quadro recebido pelo MN e continua com a sessão de vídeo aberta com o servidor, recebendo os quadros, inserindo os em seu cache. Tendo feito esse registro, o AP1 encerra a associação com o MN e informa ao PS que o MN não está mais na sua lista de associação. Este fato indica para o AP1 que deve iniciar a transmissão dos quadros em seu cache, a partir do quadro marcado como registro de sessão, para AP2 via IAPP. ALFA RSSI > 40 LFR < 10% PSNR > 35 BETA 40 RSSI > 30 LFR < 20% 29 > PSNR > 26 GAMA 30 RSSI LFR 20% PSNR < 18 Tabela1: Limites para decisão de handoff 105

110 Session ID Service ID IP association Frame ID 3.2. Decisão de Handoff Tabela 2: Estrutura de cache de sessão O algoritmo de decisão de handoff foi construído baseado em limiares combinados de RSSI com taxa de perda de frames (TPF). Para alcançar esses limiares, realizamos 200 transferências de um fluxo de vídeo no formato MPEG 4 para cada um dos três cenários abaixo, e obtevemos, com o resultado médio, os valores expressos na Tabela 1 e nas Figuras 2 e 3. Cenário 1 AP1 no channel 10 / AP2 no canal 9 (interferência de canal adjacente) / Uma estação sem movimento a 2m do AP1 Cenário 2 Cenário 3 AP1 no channel 10 / AP2 no canal 9 (interferência de canal adjacente) / Uma estação sem movimento a 10m do AP1 AP1 no canal 10 / AP2 no canal 9 (interferência de canal adjacente) / Uma estação sem movimento a 25m do AP1 Table 3: Cenários para obtenção de limites Figura 2: Thresholds RSSI and PSNR levels Figura 3: Níveis limite de frames perdidos Assim, para prever o handoff do MN, os APs usam o algoritmo 2 a seguir para determinar os níveis em que o MN está para então sinalizar para iniciar o cache. Após o início do cache de quadros no AP1 e no PS, o MN entra no nível GAMA e sua sessão RTSP, aberta com o PS, será suspensa, e os quadros serão armazenados no cache daquele móvel, dentro dos AP. Quando o MN, voltar ao nível BETA, associado ao AP1 ou ao AP2, ele receberá o vídeo a partir do próximo quadro após o último recebido antes de entrar no nível GAMA, gerando uma garantia de entrega de todo o conteúdo do vídeo. 4. Cenário e Testbed Para validar nossa proposta, criamos um testbed com um cenário que está ilustrado na figura

111 Em nossas testes, usamos três computadores com VLS [11] atendendo a requisições de sessões RTSP para fluxo de vídeo. Um computador que faz as funções do PS, dois pontos de Acesso baseados em FreeBSD com suporte a IP móvel [12] e implementação IAPP. Os enlaces com os servidores de vídeo e o PS foram de100 Mbps e os enlaces entre os APs e o MN foi de 54Mpbs. Cada estação pode estabelecer um enlace com um AP se e somente se, a sua taxa de transmissão é igual ou superior a 2 Mbps, conforme seleção RTS mecanismo proposto por [11]. Os APs foram configurado para usar os canais 1 e 11, respectivamente, para evitar interferências de canais adjacentes. Uma versão reduzida e especializada do sistema operacional FreeBSD foi desenvolvida e embarcada em um cartão IDE flash. Cada AP tem três interfaces de rede: duas IEEE a 100Mbps e uma IEEE g a 54 Mbps com chipset Atheros. Para testes, usamos um arquivo de vídeo com 16,6 minutos, em formato MPEG 4. Este vídeo foi armazenado no servidor de vídeo e enviado pelo VLS, quando solicitado, ao SPS a 30 fps. O vídeo foi transmitido 200 vezes nos cenários apresentados na Tabela 3. Usamos o comando ifconfig, nativo do sistema UNIX, nos APs para reduzir os níveis de RSSI durante a transmissão, visando simular as mudanças nos níveis propostos (movimento MN). Os resultados são médias destas 200 transmissões. 5. Resultados Obtidos Após as experiências, constatamos que, quanto mais distante do AP está MN, ou seja, quanto mais ele se aproxima dos limites de sua célula, seu nível de RSSI, medido no AP, reduz. No ambiente configurado com IP móvel e IAPP, o nível de RSSI do MN atinge zero durante o handoff físico, recuperando sua intensidade, uma vez que se aproxima e se associada ao novo AP. O tempo entre a desassociação do AP antigo e a associação no novo AP, levando em consideração a autenticação, combinado com o tempo gasto pelo servidor DHCP para fornecer um endereço IP para o MN e o tempo de negociação entre a HA e FA, foi em nosso experimento, cerca de 10 segundos. Esse tempo foi suficiente para a sessão RTSP iniciada com o servidor ser fechada por incapacidade absoluta do protocolo de recuperar a seqüência dos quadros perdido (no caso 30fps x 10s = 300 quadros). Assim, sem a aplicação do PS, proposto neste trabalho, o nível de perda de pacotes gerados pelo handoff entre pontos de acesso chega a 1500 frames em um intervalo de 50 segundos, implicando em uma perda total de sessão. Após o handoff, a sessão RTSP foi perdida, mantendo se constante em 1500 o número de quadros perdidos, como mostra a Figura 4. Figura 4: Média do número de frames perdidos durante transmissões sem e com nossa proposta O impacto visual sobre a qualidade do vídeo recebido é muito grande, conforme podemos ver na figura 5. Considerando que o PSNR foi medido a cada 50 segundos de transmissão, notamos que, após a entrega do frame 13170, os valores de PSNR permanecem em zero até ao final da transmissão, considerando a perda permanente da sessão RTSP. 107

112 Ao analisarmos as figuras 4 e 5, vemos que nossa proposta não impede a perda de pacotes durante o handoff, mas garantimos a continuidade de sessão entre o PS e os Aps e entre o PS e os servidores de vídeo, armazenando os quadros não recebidos pelo MN, entregando os mesmos para ele, logo que a associação com o outro AP é estabelecida e que o nível de RSSI seja suficiente (nível BETA). Isso permite a recuperação de pacotes perdidos, reduzindo a taxa de perda após o handoff, de modo que o MN receba os quadros que não recebeu durante a interrupção de sua conexão. Isso aumenta o PSNR médio do vídeo transmitido, monitorados na transmissão de 50 a 50 segundos. Figura 5: Média do PSNR e do RSSI durante transmissões sem e com nossa proposta Na figura 6, é mostrado um exemplo de seqüência de frames recebidos antes e depois do handoff, entre 600 e 400 segundo. O MN recebe o frame no segundo 439. Após este tempo, o MN entra no nível GAMA, indicando para o AP não enviar mais quadros, visto que o MN não está mais apto a receber quadros com uma qualidade aceitável. Sem a implementação da nossa proposta, reparamos que o PSNR mostrado na figura 5 é constante em zero após o segundo 450, devido a garnde perda de quadros. Figura 6: Sequência de frames antes e depois do handoff sem nossa proposta Figura 7: Sequência de frames antes e depois do handoff com a aplicação de nossa proposta Além disso, na figura 7, mostramos uma seqüência de quadros, obtidos após a implementação de nossa proposta. Notamos que quadros diferentes continuam sendo recebidos, aumentando o valor do PSNR. Notamos que, no segundo 400, o quadro é recebido pelo MN. Após este tempo, o mecanismo PS começa a funcionar e, então, no segundo 490, o MN atinge o nível de RSSI BETA (após handoff) e continua recebendo o frame e todos os outros a partir do ponto onde o handoff iniciou. Podemos verificar que a vantagem da nossa proposta é preservar a continuidade da sessão entre o servidor de vídeo e o MN, assegurando que o mesmo receba todo o conteúdo do vídeo, sem descontinuidades de frames. 108

113 6. Conclusões Após os experimentos realizados, chegamos à conclusão que no handoff entre pontos de acesso, durante a transmissão de um stream de vídeo, o uso de IAPP e IP móvel não é suficiente para resolver problemas de continuidade de sessão, gerados pelo intervalo de tempo do handoff entre os APs, onde o MN fica sem associação definida, gerando alta perda de pacotes. A ideia do PS trouxe uma maior flexibilidade de implementação, considerando que ele atua na camada de rede, recebendo informações do nível físico para decidir o momento mais oportuno para informar à aplicação que o MN não está mais apto a receber dados e assim iniciar os procedimentos de cache de quadros. Nossa proposta oferece uma boa solução para cenários de IPTV, com a entrega de vídeo sob demanda e transmissões ao vivo (sem interação) na última milha, usando WLANs, onde os usuários podem se mover entre os APs formandores de um BSSs (normalmente, aeroportos, estações de ônibus, shoppings, campus universitário, etc.) Referências [1] Xiao, Yang. IEEE N: Enhancements for higher throughput in Wireless Lans In IEEE Wireless Communications, Dezembro [2] Heusse, Martin; Rousseau, Franck; Berger Sabbatel, Gi Duda, Andrzej. Performance Anomaly of b.IEEE INFOCOM, San Francisco, [3] Fonseca, Mauro; Jamhour, Edgard; Mendes, Christian; Munaretto, Anelise. Extensão do Mecanismo RTS/CTS para Otimização de Desempenho em Redes sem Fio. XXV Simpósio Brasileiro de Telecomunicações, [4] Bianchi, Giuseppe; Fsatta, Luigi; Oliveri, Matteo. Perfomance Evaluation and enhancement of the CSMA/CA MAC protocol for Wireless LAN s. Proc. IEEE PIMRC, Taipei, Taiwan. Outubro 1996, pag [5] Conceição, Arlindo Flávio and Kon, Fábio. Desenvolvimento de aplicações adaptativas para redes IEEE SBRC2006. [6] Proxy based multimedia signaling scheme using RTSP for seamless service mobility in home network. Consumer Electronics, IEEE Transactions on, [7] R. Bolla, S. Mangialardi, R. Rapuzzi and M. Repetto. Streaming multimedia contents to nomadic users in ubiquitous computing environments. MoVID, INFOCOM, [8] Reza Malekian. The Study of Handover in Mobile IP Networks, BROADCOM, [9] P. Ferre, D. Agrafiotis, T.K. Chiew, A.R. Nix and D.R. Bull. Multimedia Transmission over IEEE g WLANs: Practical Issues and Considerations. International Conference on Consumer Electronics, ICCE [10] Monteiro, Claudio de Castro and Gondim, Paulo Roberto. Improving Video Quality in Networks. MoVID Workshop, INFOCOM2009. Rio de Janeiro Brazil, [11] VideoLan Software Suite. [12] Stewart, Lawrence, Banh, Mai and Armitage, Grenville. Implementing an IPv6 and Mobile IPv6 testbed using FreeBSD 4.9 and KAME. CAIA Technical Report,

114 EnigMaze: Um Jogo Educativo para a TV Digital Danilo Ricardo F. Barbosa 2, Hallison Augusto J. da Silva 2, Jorge Augusto da C. Dantas 2, Maria das Vitórias S. Medeiros 2, Mônica da Silva Morais 2, Aquiles Medeiros Filgueira Burlamaqui 1 1 Laboratório NatalNet Universidade Federal do Rio Grande do Norte (UFRN) DCA Campus Universitário Natal RN Brasil. 2 Departamento de Informática Universidade do Estado do Rio Grande do Norte (UERN) Núcleo Avançado de Educação Superior de Nova Cruz Nova Cruz RN - Brasil Abstract. This paper describes an introduction of an educational game to Digital TV its goal is to join the act of watching TV to an educational act in a playful, attractive and interactive way, allowing the TV to be also an educational and not only informative. The game used for its purposes will provide the exercise of the logical reasoning sense, sense of direction, knowledge and solutions to everyday problems emphasizing interdisciplinary research to provide expansion of cognitive levels of the viewer, which must not give up the TV schedule to play the game. Resumo. Este artigo descreve a introdução de um jogo educativo para a TV Digital com o intuito de unir o ato de assistir TV ao ato educacional de forma lúdica, atrativa e interativa, possibilitando que a TV seja também de caráter formativo e não apenas informativo. O jogo utilizado para tais fins proporcionará o exercício do raciocínio lógico, senso de direção, conhecimentos gerais, e soluções de problemas cotidianos enfatizando a interdisciplinaridade para proporcionar ampliação dos níveis cognitivos do telespectador, sem que este abra mão da programação da TV para participar do jogo. 1. Introdução Com a chegada da TV Digital no Brasil, tornou-se natural o aumento do ritmo na criação de aplicações relacionadas ao assunto. TV Digital é a união da TV comum às tecnologias de computação, acarretando em imagem e som de alta qualidade, bem como a mobilidade, portabilidade, multiprogramação e interatividade. Segundo uma pesquisa realizada Pelo Instituto de Pesquisas Datafolha citada pelo Folha Online, em 2008, 98% dos jovens brasileiros passam em média 3h40min/dia frente à TV; e esse tempo tende a aumentar, uma vez que a TV Digital trará os atrativos supracitados. Desse 110

115 modo, torna-se relevante a proposta de que esse tempo seja mais bem aproveitado, de forma que os jovens não se prendam apenas à programação exibida na TV. Nesse contexto, objetiva-se utilizar jogos na TV Digital para unir o ato de assistir TV ao ato educacional, que se dará de forma lúdica, atrativa e interativa. PIAGET (1967) afirma que o jogo possibilita a construção do conhecimento, e ANTUNES (2003) corrobora, dizendo que [...] é jogando que se aprende a extrair da vida o que a vida tem de essencial. Sendo assim, torna-se compreensível que o ato de provocar e favorecer o conhecimento, desde que este seja construído a partir da necessidade do indivíduo, resume o sentido de educar. E é num ambiente lúdico que se pode incitar uma pessoa a obter conhecimentos, através da proposta de situaçõesproblemas que possam despertar a necessidade da resolução das mesmas. Trata-se, portanto, de propor uma maneira para que as pessoas possam ser atores principais no sentido do aprendizado, e não apenas coadjuvantes replicadores de conhecimento e informação. Desse modo, é importante propiciar a vivência de práticas alternativas de educação, de acordo com a realidade, necessidades e possibilidades das pessoas. Como forma de tecnologia, há muito que a TV deixou de ser apenas um suporte, e hoje tem sua própria lógica, linguagem e maneiras peculiares de influenciar como o homem age. Embora seja comum ouvirmos que a TV desempenhe um papel de vilã na educação, precisamos estar cientes do seu papel potencial de educar. Como quase tudo na vida, há sempre lados bons e ruins de determinadas coisas, e cabe a nós, seres pensantes, sabermos utilizá-las da melhor maneira possível, sempre aproveitando para acolher tudo o que é construtivo e o que nos beneficia. ADORNO (1995, p. 76) afirma que a televisão, na formação cultural, assume duas funções: uma deformativa e a outra formativa. A TV, a partir de sua função deformativa, contribui para a divulgação de ideologias, bem como dirige de maneira equivocada a consciência dos espectadores, entretanto, este meio de comunicação possui também um enorme potencial de divulgação de informações e de esclarecimento. Agindo mediante o exposto, podemos utilizar jogos que se disponham como guias, que ajudam a reunir as qualidades positivas da TV, e a repassá-las para os espectadores. Nesse sentido, é relevante a criação de jogos que atuem como filtros propriamente ditos do conhecimento, e que, além disso, possam facilitar o desenvolvimento do aprendizado. Os telespectadores, antes de o serem, são cidadãos inseridos em quadros de interações e interdependências, que por sua vez podem ser bem trabalhadas e simuladas em jogos, com o intuito de aproveitar o aprendizado obtido em um ambiente lúdico no mundo real propriamente dito. Os jogos podem, desse modo, ter um papel de incubadores de situações reais, reduzidas ao faz-de-conta, onde as pessoas podem exercitar e aprender as melhores maneiras de atuar e agir na sociedade. Por isso é importante criar uma parceria da TV Digital por fornecer uma maleabilidade no tocante a elaboração, criação e desenvolvimento de aplicações educativas com os jogos, para unir o útil ao agradável e potencializar ainda mais as formas de educação. 2. Metodologia Para tanto, é interessante haver a implementação de jogos de cunho educativo para TV Digital, de modo que a facilidade ao acesso à TV possibilite um ensino construtivo e sua socialização, por meio dos diversos benefícios fomentados e gerados através desses 111

116 jogos. Como proposta de um jogo que abranja o que foi discutido, apresenta-se o jogo EnigMaze construído em linguagens NCL e Lua de programação que possibilitam a integração de objetos gráficos para cenários e personagens, bem como uma interação simultânea com vídeos e outras mídias sem que haja perdas significativas de desempenho da aplicação, tanto em seu carregamento quanto em sua execução num aparelho de TV Digital. Integrar essas mídias reflete-se num cenário de educação importante, uma vez que culmina todos os benefícios propostos por todas e por cada uma delas. O EnigMaze é formado por diversas fases, nas quais o jogador é levado a vários labirintos, onde será forçado a solucionar enigmas aqui dispostos como sequências numéricas e/ou lógicas a serem desvendadas para chegar ao objetivo final: sair do labirinto. Nos labirintos, o jogador deverá desviar das armadilhas e obstáculos durante seu trajeto. Os enigmas poderão ser descobertos por meio do auxílio de dicas e pistas espalhadas pelo caminho. Ao fim de cada labirinto, haverá um avatar que testará o palpite da sequência formada pelo jogador. Se o palpite estiver correto, o jogador avança de fase; caso contrário, perderá uma vida e voltará ao início da fase atual para poder, mais uma vez, tentar descobrir a sequência correta. A interface do jogo consiste em utilizar uma parte da tela da TV para a exibição do labirinto, e outra parte para exibir à programação da emissora de TV, conforme ilustra a figura a seguir: Figura 1. Interface principal do EnigMaze No ambiente do EnigMaze há a proposta de imergir situações cotidianas com conteúdos didáticos, configurando a resolução dos problemas como catalisadores para a aprendizagem. A priori, o jogo destina-se a jovens com faixa-etária compreendida entre 12 e 15 anos uma vez que geralmente é o público juvenil que mais se interessa por jogos. Antigamente havia a passagem da infância para a fase adulta, e atualmente o que se busca é o prolongamento da juventude. E sendo os jogos uma característica marcante 112

117 da juventude, é relevante utilizá-los. Com essa maneira de atender à faixa-etária supra, busca-se um equilíbrio democrático, onde é possível relembrar e/ou reforçar conteúdos didáticos outrora vistos na escola, bem como instruir as pessoas para saberem lidar com situações um pouco mais comuns. Segundo LOPES (1999, p. 23), é muito mais fácil e eficiente aprender por meio de jogos, e isso é válido para todas as idades, desde o maternal até a fase adulta. O jogo em si possui componentes do cotidiano, e o envolvimento desperta o interesse do aprendiz, que se torna sujeito ativo do processo. É seguindo essa lógica que o EnigMaze fundamenta-se e se desenvolve, buscando a integração entre problemas que possam ser solucionados por diversos componentes do núcleo familiar juvenil. O mais importante nesse contexto é possibilitar a construção do conhecimento de maneira coletiva. É possível então trabalhar com diversos temas didáticos: ortografia em Língua Portuguesa, datas de acontecimentos históricos em História, operações fundamentais em Matemática e conhecimentos gerais. Embora o jogo ainda esteja em fase de desenvolvimento, é possível perceber a sua relevância para a educação e para a gerência de conteúdos mais adequados e construtivos para a formação dos jovens. 3. Resultados Esperados Os resultados esperados através da utilização do jogo são o exercício do raciocínio lógico, senso de direção, aquisição de conhecimentos gerais, soluções de problemas, o desenvolvimento afetivo, social e moral, bem como a coordenação espacial, além de ensinar a rever limites e a trabalhar a ansiedade através do ensino de diversos temas didáticos (ortografia, operações fundamentais e datas) e/ou cotidianos de forma objetiva e divertida. Tudo isso utilizando a interdisciplinaridade proposta pela integração de sequências lógicas e matemáticas com os vários campos do conhecimento, para a ampliação dos níveis cognitivos do telespectador-jogador. E o melhor: sem abrir mão do conteúdo exibido na TV para poder participar do jogo. É nesse sentido que buscamos melhorar a atuação das pessoas no contexto social, para que elas possam por em prática o que foi aprendido no ambiente do EnigMaze; promovendo a TV a uma metodologia de caráter de fato formativo. Esperamos também contribuir para a era da telemática união das telecomunicações à informática desempenhando com o jogo, além de um papel educativo, um papel de inclusão social e democratização do conhecimento, sem distinções. 4. Trabalhos Futuros Temos o intuito de possibilitar a interação de diversos usuários no ambiente do jogo, bem como a integração de dispositivos como o celular, por exemplo, para a participação no EnigMaze. Embora ainda haja problemas e paradigmas que precisam ser superados como bem se sabe para a efetivação desses objetivos, dos quais podemos citar a necessidade de hardwares mais robustos e canais de retorno para a efetivação da comunicação entre vários televisores, por exemplo; em condições ideais, a nossa projeção é, portanto, mais ousada, uma vez que pretende integrar vários usuários para a concretização de um ambiente coletivo e cooperativo de aprendizagem e trabalho em equipe, visando o aumento na aquisição de conhecimentos e informações. 113

118 Também ensejamos construir simulações mais versáteis da realidade de cada jogador, onde este possa escolher os níveis de dificuldades e as áreas do conhecimento que lhe interessem. Além disso, também se almeja a interação do EnigMaze com programas educativos, onde o aprendizado obtido através de tais programas possa ser testado, avaliado e manipulado na interface do jogo. Desse modo, haverá uma melhor fixação do que foi aprendido. 5. Conclusão Conclui-se então que a utilização de jogos na TV Digital, se utilizados de maneira correta, pode se tornar uma forte aliada ao processo de educação massiva, interação e socialização do conhecimento de maneira prazerosa, dada a fácil acessibilidade e à ludicidade. Como nem todas as pessoas tem o acesso devido a computadores e à internet, a TV Digital pode ser utilizada como uma alternativa apara aproximar as pessoas ao chamado mundo digital. É graças às semelhanças com os computadores que a TV Digital fornece os meios necessários para a criação de jogos mais bem elaborados e estruturados, para que possam ser mais bem aproveitados pelos telespectadores. Isso possibilita que as pessoas ampliem e adquiram conhecimentos úteis para o seu dia-a-dia e exercitem suas habilidades psíquicas. Assim, a TV se tornará ainda mais efetivamente uma porta aberta para que o conhecimento entre na casa das pessoas. Referências Antunes, Celso. (2003) O Jogo e a educação infantil, Rio de Janeiro Editora Vozes. Piaget, Jean. (1967) O raciocínio na criança, Rio de Janeiro Editora Real. Lopes, Maria da Glória. (1999). Jogos na Educação: criar, fazer, jogar, São Paulo Editora Cortez. Adorno, T. W. (1995). Educação e Emancipação, São Paulo Editora Paz e Terra. Folha Online (2008) Meninos mais novos já preferem internet à TV no Brasil, Novembro. 114

119 Geração automática de casos de testes para interface gráfica Alessandro J, de Souza 1, Macilon A. Costa Neto 2, Jair C. Leite 3, Roberta S. Coelho 3 1 Instituto Federal do Rio Grande do Norte Av. Sen. Salgado Filho, Natal RN 2 Universidade Federal do Acre Caixa Postal Rio Branco AC 3 Universidade Federal do Rio Grande Norte Caixa Postal Natal RN Resumo. A maioria dos sistemas interativos comunicam-se com os usuários através de interfaces gráficas, as quais muitas das vezes constituem grande parte do código da aplicação. Daí a importância deste artefato de software receber atenção dos projetistas para assegurar sua qualidade. Porém, devido a características intrínsecas, elas são difíceis de serem testadas e, por conseqüência, esquecidas pelos projetista de teste. Por esse motivo este trabalho propõe a construção de uma ferramenta capaz de gerar casos de testes de forma automática, utilizando a combinação das metodologias MDD e MDT. Abstract. Usually interactive systems communicate with the users through the graphical interfaces that represents much of the application code. For that reason this software artifact should receive greater attention from designers, in order to ensure their quality. However, as their characteristics are difficult to be tested and it is often neglected by test designers. Therefore, this paper proposes the development of a tool capable of automate generating of test cases, by combination of the methodologies MDD and MDT. 1. Introdução A redução do custo dos computadores foi, notoriamente, a responsável pela explosão de aquisições destes equipamentos. Entretanto, a popularização de seu uso se deu graças às interfaces gráficas de usuários, em inglês, GUI s (Grafical User Interface), muitas vezes confundidas com a própria aplicação [der Veer and Vliet 2001]. Atualmente, a porção de código que corresponde a uma GUI representa mais da metade do código de toda a aplicação [Vinter et al. 1996, Memon 2001]. Até pouco tempo, os testes de uma aplicação eram realizados apenas na porção de código corresponde às regras de negócio, deixando-se de lado a interface gráfica. Dessa forma, mais da metade do código da aplicação não era testada, o que poderia evitar grandes possibilidades de problemas futuros. Memon, em sua tese de doutorado [Memon 2001], apresenta um framework para auxiliar no processo de testes em interfaces gráficas. Além disso, também identifica e descreve os principais problemas encontrados ao se realizar testes sobre GUI s, que mais tarde foram definidas como as ciladas do teste das interfaces gráficas [Memon 2002]. 115

120 Algumas linhas de pesquisa acreditam que características como portabilidade, melhoria da qualidade do produto e redução de custo, podem ser maximizados através da metodologia MDD (Model Driven Development). O desenvolvimento dirigido por modelos busca a geração de código usando-se de refinamentos sucessivos de modelos abstratos através de transformações. O MDT (Model Driven Test) consiste em uma abordagem que segue a metodologia MDD para a geração automática de casos de teste [Heckel and Lohmann 2003]. Atualmente os trabalhos de geração de casos de testes vêm sendo realizados para apenas para o núcleo das aplicações, especificamente utilizando alguns modelos da UML (Unified Modeling Language). A construção de testes para interface gráfica constitui um impacto de codificação elevado, tendo em vista, o grande número de modificações que são necessárias durante a fase de concepção da mesma. Como citado por [Memon 2001], simples alterações no layout podem acarretar inconsistência nos testes de regressão, demandando portanto, imediata adequação do código de teste. Nesse contexto, nossa proposta é a geração automática de casos de teste para GUI a partir de modelos abstratos de interface. Para isso, fez-se uso da IMML (Interactive Message Modeling Language) [Leite 2003] para descrição destes modelos. Com isso, quaisquer mudanças necessárias na interface, poderão ser feitas em seu modelo abstrato, o que acarretará ajustes automáticos refletidos em ambos os códigos (interface e testes). 2. Testes de interface gráfica de usuário Os testes de software têm se tornado uma ferramenta primordial para diminuição de erros. Mesmo com benefícios dos testes sobre o núcleo da aplicação, esta prática ainda é considerada um desafio quando aplicada às interfaces gráficas, devido às peculiaridades existentes neste tipo interface. Teste de unidade convencional envolve apenas classes isoladas, e tornam-se impróprios para componentes de interface. Uma GUI pode envolver no seu diálogo com o usuário outras interfaces, o que inclui várias classes. Atualmente destacam-se dois métodos para testes de interface [Ruiz and Price 2007]: O método record/playback consiste, em um primeiro momento, na gravação de scripts para registrar as interações do usuário com a interface. Após esta gravação os desenvolvedores podem fazer uso desse script para reproduzir as interações do usuário para um determinado cenário. Este tipo de teste se torna muito dispendioso, pois qualquer mudança na aplicação acarreta na regravação de todos os cenários afetados. Outra desvantagem, desse método, é o uso de linguagens proprietárias para descrição dos scripts gerados, fato que dificulta a comunidade de desenvolvedores na manutenção dos testes. Os testes programáticos são executados a partir de uma aplicação externa ao sistema. Esta aplicação tem o objetivo de simular a interação do usuário com o sistema através da manipulação dos componentes da interface a ser testada. Como este método mais adaptável às mudanças, se gerados automaticamente, tornam-se menos custosos que o anterior. Por serem descritos usando orientação a objetos, facilitam a criação e a manutenção. Outra vantagem é que não existe a obrigatoriedade da construção da interface anteceder a construção dos testes. Como os teste de GUI baseados no método record/playback são gerados somente a partir da interface implementada, nossa solução adotou a geração automática de testes programático, a partir de modelos da interface. 116

121 3. Desenvolvimento dirigido por modelos A abordagem MDA TM (Model Driven Architecture) é uma das principais técnicas para o desenvolvimento dirigido por modelos, proposto pelo OMG (Object Management Group) em 2001 e motivado pela adoção em 1995 da UML (Unified Modeling Language) como um padrão para modelagem de software [Miller and Mukerji 2003]. No trabalho de [Miller and Mukerji 2003], os autores destacam que o principal objetivo da abordagem MDA é maximização da portabilidade, interoperabilidade e reusabilidade dos sistemas desenvolvidos, através da separação arquitetural dos conceitos envolvidos [Kleppe et al. 2003]: Computation Independent Model (CIM): este modelo representa uma visão do sistema sob uma ótica computacionalmente independente; Platform Independent Model (PIM): este modelo representa uma visão mais concreta do sistema, porém, abstrata o suficiente para ser independente de plataforma; Platform Specific Model (PSM): aqui tem-se uma visão baseada nas estruturas de implementação disponíveis numa tecnologia específica. Model Transformation: processo de transformar automaticamente um modelo (normalmente de um nível mais alto de abstração) em outro (geralmente num nível mais baixo), acrescentando detalhes, tornando-o menos abstrato e mais específico, objetivando chegar finalmente ao código para o sistema em questão. A principal vantagem da abordagem de desenvolvimento dirigido por modelos a geração automática de código. Isso estimula seu uso no contexto de teste de software. A técnica de MDT (Model Driven Test) vem sendo aplicada na geração de artefatos de teste [Baker et al. 2007]. A geração de testes a partir de modelos proporciona uma maior integração do designer de teste com a equipe de desenvolvimento, haja visto que, ao modelar um caso de teste, este vai ser transformado em código e estará pronto para ser usado pelo testador do software. O uso de MDD nos processos de geração automática de testes favorece o reuso, pois a partir do modelo de casos de teste os mesmos podem ser gerados para plataformas diferentes, reduzindo assim custos e tempo de desenvolvimento. 4. Geração automática de casos de teste para interface gráfica de usuário Neste proposta inicia-se com a descrição abstrata da interface, ou seja construção do seu modelo, utilizando para isso a linguagem IMML [Leite 2003]. Sendo que dos três modelos suportados pela IMML, apenas dois são necessários para construção de GUI e seus casos de testes. Esses modelos são domínio e interação, usados para especificar, respectivamente, as funcionalidades oferecidas pela interface e a forma como o usuário deverá interagir com a interface para realizar suas tarefas usando essas funções. Com estas especificações é possível gerar automaticamente a própria GUI e seus casos de testes correspondentes. Uma visão geral da arquitetura da ferramenta proposta, incluindo as atividades, tecnologias empregadas e artefatos gerados neste trabalho, pode ser visualizada na figura 1. Através dessa arquitetura pode-se observar que, dentro da abordagem MDA, cada modelo deve ser construído (ou gerado) conforme um meta-modelo. Contudo, neste trabalho, será abordado apenas o meta-modelo usado para suportar a modelagem dos casos de testes de interface, empregando a técnica de testes programáticos. 117

122 Figura 1. Arquitetura da Ferramenta. A ferramenta gera automaticamente modelos de testes básicos a partir do modelo da interface. Além disso, garante ao designer de testes a livre edição desse modelo, podendo acrescentar outros casos de testes a partir do modelo gerado, fato que demonstra sua flexibilidade, servindo apenas como ferramenta no processo, e não substituindo o profissional. Para construir o suporte computacional necessário para este trabalho, foram realizadas algumas atividades e utilizadas diversas ferramentas de suporte ao desenvolvimento baseado em modelos empregando a abordagem MDA, a saber são enumerados: 1. Criação de todos os meta-modelos citados na figura 1 usando o Ecore, subconjunto do MOF, implementado no Eclipse Modeling Framework 1. A descrição dos metamodelos de Domínio, Interação e Swing 2 não são apresentados neste trabalho. Depois de criados os meta-modelos, foram gerados os plugins necessários para edição dos modelos utilizando o próprio EMF. O meta-modelo de teste, abstraindo seus elementos do Jemmy 3, é apresentado na figura 2; 2. Criação das regras de transformações M2M (Model-To-Model), utilizando o QVT Operational, que é uma implementação para o padrão QVT do OMG. Assim, foram especificados os seguintes arquivos, com as regras de transformações entre os respectivos modelos: domain2interaction.qvto, interaction2swing.qvto, e interaction2test.qvto; 3. Criação das transformações M2T (Modelo-To-Text) para geração do código correspondente aos modelos Swing e Jemmy. Para este conjunto de transformações foi usando o Acceleo 4, que é um componente integrado a plataforma Eclipse, originado no projeto Elipse M2T, destinado às transformações de modelo para texto, definidas pelo MOF. Utilizando os meta-modelos produzidos, é possível especificar apenas o modelo de domínio e, através das ferramentas citadas acima, gerar automaticamente os demais modelos. Contudo, estes são modelos preliminares passíveis de quaisquer modificações realizadas pelo projetista de teste API Java para construção de GUI, disponível em 3 Uma extensão do JUnit para componentes Swing, dispível em https://jemmy.dev.java.net/

123 Figura 2. Meta-modelo para os casos de teste. 5. Estudo de caso Para demostrar aplicação de nossa abordagem, foi especificado o modelo de domínio para uma simples interface de autenticação. Este modelo foi passado como parâmetro para a transformação domain2interaction.qvto e gerou o modelo de interação. Este modelo passado para as transformações interaction2swing.qvto e interaction2test.qvto, irá gerar os modelos Swing e Jemmy, respectivamente. Gerados todos os modelos, executa-se as transformações de modelo para código sobre os modelos Swing e Jemmy, aplicando sobre estes os templates swing.mt, para produção do código final da interface utilizando a API do Swing; e jemmy.mt, para produção do código dos casos de teste utilizando a API do Jemmy. Essa abordagem foi usada, inicialmente, para gerar o código da interface, mas seu detalhamento de processo foge ao escopo deste trabalho. A figura 3 resume um cenário de execução dos casos de testes gerados neste processo, nela percebe-se: (1) uma instância da interface propriamente dita em execução, chamada diretamente pelo JUnit, para ser submetida aos testes; (2) o trecho de código correspondente ao suite de testes com os casos de testes que serão executados sobre a interface; (3) por fim, os resultados da execução dos casos de testes apresentados pelo JUnit. 6. Considerações finais Este artigo apresentou uma ferramenta de geração de casos de testes a partir de modelos de GUI s usando abordagens MDD e MDT. Dentre os pontos fortes dessa ferramenta pode-se destacar:(a) automatização no processo de desenvolvimento de interface e seus testes; (b) a definição de modelos mais próximos dos designers de interface e teste; (c) a geração de testes pode acompanhar a evolução do sistema. Alguns pontos do trabalho ainda podem ser melhorados, como a ampliação do modelo de interface. Para que fossem gerados os casos de testes básicos neste trabalho, tive-se que especificar algumas possibilidades de interação sobre a interface, o que antes não estava previsto no meta-modelo da IMML. Como trabalhos futuros pode-se investigar a utilização de outros frameworks para testes programáticos de interface gráficas e verificar o comportamento da arquitetura da ferramenta. 119

124 Figura 3. Ambiente de execução dos casos de teste. Referências Baker, P., Dai, Z. R., Grabowski, J., Haugen, O., Schieferdecker, I., and Williams, C. (2007). Model-Driven Testing: Using the UML Testing Profile. Springer-Verlag New York, Inc., Secaucus, NJ, USA. der Veer, G. V. and Vliet, H. V. (2001). A plea for a poor man s hci component in software engineering and computer science curricula. Computer Science Education, 13(3). Heckel, R. and Lohmann, M. (2003). Towards model-driven testing. Electr. Notes Theor. Comput. Sci, 82(6). Kleppe, A., Warmer, J., and Bast, W. (2003). MDA Explained: The Model Driven Architecture: Practice and Promise. Addison-Wesley Longman Publishing Co., Inc., Boston, MA, USA. Leite, J. C. (2003). Specifying the user interface as an interactive message. In Proceedings of Human-Computer Interaction International (HCII 2003), volume 2, pages , Heraklion, Creta. Lawrence Erlbaum Associates. Memon, A. M. (2001). A comprehensive framework for testing graphical user interfaces. PhD thesis, University of Pittsburgh. Adviser-Soffa, Mary Lou. Memon, A. M. (2002). Gui testing: Pitfalls and process. Computer, 35(8): Miller, J. and Mukerji, J. (2003). MDA Guide Version Framingham, Massachusetts. Ruiz, A. and Price, Y. W. (2007). Test-driven gui development with testng and abbot. IEEE Software, 24(3): Vinter, O., Poulsen, P., and Lauesen, S. (1996). Experience driven software process improvement. In Software Process Improvement. Brighton. 120

125 Uma solução para a gestão de autenticação em redes através do padrão X: Arapuca Kleber Jacinto 1, Kempes Jacinto 1, Marcos Tullyo Campos 1 1 Superintendência de Tecnologia da Informação e Comunicação Universidade Federal Rural do Semi-Árido BR Km 47 Bairro Pres. Costa e Silva - CEP: Mossoró/RN {kleber, kempes, Abstract. With the popularity of mobile devices, the demand for Internet access services has grown in domestic, corporative and government places. Security incidents in these networks grown in the same proportion. The security management in these networks can become an activity that consumes human and financial resources, and represents a technical challenge. The software Arapuca [ bird trap, from portuguese] is a user management solution that automates many tasks to the network administrator using an authentication system based on the IEEE X standard, one of the safest available today. Resumo. Com a popularização dos dispositivos móveis, a demanda por serviços de acesso à Internet tem crescido tanto nos ambientes públicos como privados, domésticos ou corporativos. Os problemas de segurança nestas redes cresce em igual proporção. A gestão da segurança pode tornar-se uma atividade complexa, que consome recursos humanos e financeiros, além de representar um desafio técnico. O software Arapuca é uma solução de gestão de usuários que automatiza a relação do administrador da rede com um sistema de autenticação baseado no padrão IEEE X, um dos mais seguros disponíveis. 1. Intróito As redes sem fio estão tornando-se cada vez mais comuns, pela queda nos custos dos equipamentos, pela facilidade de uso/configuração, além do crescimento das vendas de aparelhos dotados de tecnologia de acesso à redes nos padrões IEEE a, b e g. O controle sobre estas redes é consideravelmente mais complexo que nas redes tradicionais, dado que a mobilidade e a dinâmica destas redes dificultam ações de gestão. Quando a rede é plenamente aberta (acesso livre) a situação simplifica-se. Porém num ambiente onde deseja-se gerir o acesso, dois desafios tem de ser enfrentados: a gestão dos usuários em si (criação, concessão de permissões, logging) e o processo de autenticação propriamente dito. Para ambos existem diversas soluções contudo associar as melhores práticas de segurança com uma gestão eficiente de usuários não é uma atividade trivial: as soluções mais práticas de gestão de usuários costumam não ser as mais seguras, e as mais seguras necessitam de técnicas e profissionais nem sempre disponíveis. 121

126 2. Segurança em redes sem fio Diminuir os riscos de segurança em redes sem fio é garantir que apenas usuários ou máquinas específicas possam trocar pacotes de dados com os pontos de acesso, e por conseqüência com a própria rede. Duas abordagens são recomendadas: realizar a autenticação ou na camada de enlace de dados, ou na camada de rede. Nas duas abordagens as opções mais comuns fazem uso da criptografia dos dados/pacotes e, das opções propostas para o padrão , duas destacam-se por se fazerem presentes na maior parte dos equipamentos: o WEP (Wired Equivalent Privacy atua na camada de enlace) e o WPA (Wi-Fi Protected Access atua na camada de rede). [Lashkari 2009] O WEP emprega uma chave secreta de 40 ou 104 bits que deve ser compartilhada pelo ponto de acesso e pelos clientes (todos os cliente usam a mesma chave secretas se conectados a um mesmo ponto de acesso). Durante a transmissão do pacote um vetor de inicialização (Initialization Vector) de 24 bits é escolhido randomicamente e é anexado à chave pré-compartilhada, para formar a chave de 64 ou 128 bits. A chave é criptografada por um algoritmo RC4, e usada tanto para autenticar o usuário como para criptografar cada pacote. [SINGHAL 2001]. Dado que no WEP a chave transita pela rede o sistema é altamente vulnerável à quebra de criptografia e consequentes invasões. O WPA pretende ser uma melhoria do WEP, sem a necessidade de alterações no hardware pré existente (historicamente o WEP surgiu antes do WPA). Em ambientes domésticos ou pequenas redes comerciais, recomenda-se o WPA-PSK (Pre shared key), que possui usa para criptografia a PMK (Primary Master Key) que será derivada da própria PSK já configurada no ponto de acesso. Para ambientes corporativos a chave PMK será originada a partir da MSK (Master Session Key), que é uma chave que foi compartilhada durante o processo de autenticação 802.1X/EAP (Extensible Authentication Protocol). [PEIKARI 2002] X X é a denominação do padrão IEEE chamado de Port-Based Network Access Control (Controle de acesso à Rede baseado em portas). Ele prevê a existência de um provedor de certificados, que através do protocolo RADIUS (Remote Authentication Dial In User Service, ou Serviço Remoto de Autenticação de Ingresso de Usuários) autentica o usuário e prove o certificado que servirá de base para a criptografia dos pacotes. Uma das formas de dar a segurança e a flexibilidade necessária a esse tipo de rede é a utilização de TTLS (Tunneled Transport Layer Security, ou Segurança em Camada de Transporte em Túnel) com suporte a MSChapV2 (Microsoft Challenge Handshake Authentication Protocol version 2, ou Protocolo Microsoft de Desafio de Aperto de Mão versão 2), o que permite a conexão de máquinas da família Windows (incluindo Windows Móbile 6.1), família Linux, família MacOS (incluindo iphone e ipod) e dispositivos com SymbianOS, possam conectar-se à rede. Neste padrão, o terminal que está solicitando entrada na rede (denominado de suplicante) solicita, pela apresentação de credenciais, sua autenticação ao servidor Radius, com o intermédio de NAS (Network Autentication Server), que pode ser um 122

127 Access point ou mesmo um switch [IEEE 2004], conforme a figura 1, onde o NAS é chamado de RADIUS Client. Figura 1. Processo de autenticação de um terminal via X 3. Aplicação Decorator Existe o uso do termo Aplicação Legada para indicar uma aplicação que continua em uso em uma instituição, que devido execução de tarefas importantes e na impossibilidade de troca por outra que execute as mesmas funcionalidades e tantas mais necessárias, a mesma não é substituída e que muitas vezes existe a impossibilidade de adicionar funcionalidades diretamente a aplicação. Se a aplicação legada possuir uma banco de dados que se tenha acesso e que se mesma for considerada uma caixa preta que executa funcionalidades sem precisar saber como as mesma funcionam, temos uma analogia com classes de objetos: a aplicação é a classe e o banco sua interface externa. Usando uma analogia ao padrão de projeto Decorator (como indicado em GAMMA et all 1994), pode-se criar uma Aplicação Decorator, isto é, uma aplicação que usa o banco de dados de uma aplicação legada como interface e amplia suas funcionalidades sem haver a necessidade de alterar a aplicação original. Como o formato dos dados originais não são alterados, a aplicação legada não toma conhecimento da existência da nova aplicação e continua a executar todas as suas funções. Já a aplicação decorator, por não estar restringida pela legada possui a liberdade de realizar qualquer funcionalidade adicional, incluindo novas interfaces, relatórios e melhorando a usabilidade. Em aplicações de gerência de usuários, hardware e software, isto pode representar uma mudança do perfil do administrador, passando de um administrador de conhecimento específico em uma ferramenta para um administrador mais focado na tarefa a ser realizada. 123

128 4. Construção da Ferramenta proposta: Arapuca Várias ferramentas e aplicações do sistema operacional Linux são conhecidas por apresentar alto grau de desempenho e confiabilidade, ao mesmo tempo em que apresentam fraca interface para configurações e acompanhamento de sua execução, sendo comum ter-se que recorrer a vários comandos em modo texto ou de outras aplicações, o que pode não ser trivial. Uma dessas poderosas ferramentas é o FreeRADIUS 1, servidor de RADIUS, gratuito e bastante confiável e flexível, que pode dar suporte a uma vasta e heterogênea rede. A configuração funcional do FreeRADIUS deve ser feita em arquivos texto (ou através de algumas interfaces gráficas disponíveis no mercado), mas após entrar em funcionamento existe pouca necessidade de sua modificação. Já as configurações de acesso a rede como criação/cadastramento de usuários e NASs exigem modificações frequentes, dado que a cada dia novos usuários podem surgir ou serem excluídos. As configurações de acesso podem ser lidas tanto de arquivos como de bancos de dados (como PostgreSQL, MySQL e LDAP). Existem muitos trabalhos mostrando a viabilidade e a facilidade de configuração do software. (por exemplo [LUO 2008]) Em um momento anterior testou-se o servidor FreeRADIUS com autenticação TLS. Com esta estrutura um certificado digital é gerado pelo servidor Radius e o mesmo deve ser instalado em cada máquina usuária. Isso simplifica a atividade para o usuário, pois não é necessário realizar login, apenas estar presente na rede, uma vez que a máquina encarrega-se de apresentar as credenciais. No entanto, isso representa grande problema de controle e logística. Como todos os usuários usavam o mesmo certificado digital, não havia possibilidade de saber se um usuário específico estava envolvido em um incidente (como o mau uso da rede). Quando se fizesse necessária a substituição do certificado, todos os usuários seriam imediatamente desconectados e o novo certificado deveria ser instalado, em todas as máquinas novamente, consumindo tempo e gerando descontentamento dos usuários. Um outro problema é que, exceto no sistema operacional Windows, o certificado é armazenado como um arquivo em disco, o qual poderia ser copiado para qualquer pessoa, o que permite a concessão de uso a terceiros não autorizados. A mudança para autenticação através de NAS elimina as desvantagens citadas mas gera dois impactos. O primeiro sobre o usuário que passa a logar-se em cada seção de trabalho (se para o usuário agrega-se mais uma atividade á sua rotina, para o administrador gera-se o importantíssimo log). E sobre o administrador a tarefa de conhecer com competência os arquivos de configuração do freeradius e o trabalho de inserir e excluir manualmente os registros de usuários. O Aplicativo Arapuca (nome alusivo ao fato de que os Access points da UFERSA - Universidade Federal Rural do Semi-árido possuem nomes de aves da Caatinga do Nordeste Brasileiro) é uma aplicação desenvolvida na Superintendência de Tecnologia da Informação/UFERSA que possui uma amigável interface Web, permitindo que o administrador utilize o banco de dados MySQL do FreeRADIUS 1 Disponível em : 124

129 como um sistema de cadastro de usuários permanentes e temporários, e acompanhamento de status de NAS. Além de abstrair conhecimento em SQL e uso de prompt de comando do Linux, o Arapuca usa o banco de dados para guardar maior gama de informações (mais do que o usuário e tipo de senha, como é padrão ao FreeRADIUS), permitindo identificação completa do usuário, logs de entrada e saída, definições de grupos de usuários, criação de usuários temporários, tudo através de interface implementada em PHP e jquery. Com a interface Web permitiu-se a gestão dos usuários diretamente através da internet, sem a necessidade de contato físico ou através de conexão segura com o servidor. Sua implementação foi possível devido à forma como o FreeRADIUS trabalha com o banco de dados de acesso: ele apenas consulta a base e não critica campos ou tabelas adicionais. Com isso foi possível criar novas tabelas com os dados necessários e as mesmas foram mapeadas em views com as mesmas estruturas das tabelas originalmente usadas pelo FreeRADIUS. Assim, o banco de dados pode ser visto como interface entre as duas aplicações, onde uma manipula completamente os dados (o Arapuca) e a outra que consulta regularmente o mesmo banco para permitir ou negar acesso dos usuários a rede (o FreeRADIUS). Uma visão macro do sistema encontra-se na Figura 02. Figura 2. Arquitetura do X integrado com o Arapuca Como a segurança é provida pela própria rede, não há necessidade de funcionários especializados fazerem uso de certificados sigilosos para configurar os computares, assim foram disponibilizados manuais para que os próprios usuários os configurem. Como cada usuário possui login próprio também é possível fazer monitoramento dirigido do uso da rede. Pela observação do tráfego gerado através de um determinado em um endereço MAC/IP, e sabendo que um MAC, por sua vez, é vinculado ao login de usuário no FreeRADIUS, pode-se determinar precisão muito boa a participação em 125

130 incidentes. Em complemento o Arapuca possui conjunto de dados que descrevem os usuários do FreeRADIUS com nomes, documentos, s, senhas e grupos, além de informações dos NASs fornecendo todos os dados necessários para pesquisas de incidentes de segurança. No status atual da ferramento o próprio usuário pode consultar suas informações, dados de acesso, alterar senha e até mesmo, se possuir permissão para tal, gerar tickets temporários que permitem a usuários externos acessarem a rede. Neste caso o usuário externo é cadastrado pelo usuário da rede,e este último é co-responsável pelo acesso do primeiro, mantido portanto os critérios de segurança. Expirado o prazo do ticket, não mais será possível acessar a rede. Pode-se ainda definir grupos de usuários com funcionalidades e tipos de acesso distintos e tempo de validade de contas distintos, de forma a minimizar o trabalho do administrador e distribuindo atividades com usuários. Implantado desde o início de 2009 o sistema gerencia hoje 2395 usuários que usam a rede sem fio através de 26 NAS, todos eles pontos de acesso à rede sem fio. 4. Conclusões Apesar da existência de interfaces para administração do serviço FreeRadius, facilitando assim a implementação de autenticação em redes com X, a gestão de usuários é um ponto crítico que as interfaces existentes não costumam tratar com naturalidade. O Arapuca cobre esta falha com eficiência, sendo testado num ambiente com grande número de usuários e com vantagens na gestão da segurança e controle do administrador da rede. Os próximos desafios a serem tratados como trabalhos futuros são o tratamento de relatórios que melhorem ainda mais a rotina gerencial e a incorporação de NAS de outras naturezas, como switchs, para garantir a segurança também em redes cabeadas, algo previsto no X e já testado, com sucesso, em um ambiente controlado. Referências GAMMA, Erich; HELM, Richard; JOHNSON, Ralph; VLISSIDES, John. DESIGN PATTERNS: Elements of Reusable Object-Oriented Software. Addison-Wesley Professional IEEE - LAN/MAN Standards Committee IEEE Standard for Local and metropolitan area networks Port-Based Network Acess Control IEEE 802.1X, IEEE Computer Society Lashkari, A. H.; Danesh, M. M. S.; Samadi, B. "A survey on wireless security protocols (WEP, WPA and WPA2/802.11i)," iccsit, pp.48-52, nd IEEE International Conference on Computer Science and Information Technology, Luo, X. The Realization of the RADIUS Security Authentication. 4th International Conference on Wireless Communications, Networking and Mobile Computing, WiCOM ' Peikari, C. e Fogie S., Wireless Maximum Security, Sams, 2002 Singhal, S. K., Understanding Wireless LAN Security, ReefEdge,

131 Visualização de requisitos a partir de modelos AOV-Graph Dayanne Kelly Freire da Rocha 1, Lyrene Fernandes da Silva 1 1 Laboratório LUMEN Grupo de Sistemas Embarcados e Tempo Real (GSET) Departamento de Ciência da Computação Universidade do Estado do Rio Grande do Norte (UERN) Natal, RN - Brasil Abstract. With the objective to provide for requirements engineer the base to model in AO-Graph and also new ways to visualize and to analyze the system in development, this work presents a mechanism to visualize requirements from on AOV-Graph models. This mechanism, done automatically through the tool ReqSys, allows the transformation of an AOV-Graph requirements specification to rastreability matrix and to entity-relationship model, obeying the rules of conversion proposed in this work. Resumo. Com o objetivo de prover ao engenheiro de requisitos o apoio para modelar em AOV-Graph e, também, novos meios de visualizar e analisar o sistema em desenvolvimento, este trabalho apresenta um mecanismo de visualização de requisitos a partir de modelos AOV-Graph. Este mecanismo, automatizado pela ferramenta ReqSys, possibilita o mapeamento de uma especificação AOV-Graph em Matrizes de Rastreabilidade e em Modelo Entidade-Relacionamento (MER), obedecendo a regras de transformação propostas neste trabalho. 1. Introdução O processo de engenharia de requisitos inclui todas as atividades necessárias para gerar e manter o documento de requisitos [SOMMERVILLE 2000]. Essas atividades podem ser sintetizadas em elicitação, modelagem e análise de requisitos. Um software com desenvolvimento fundamentado neste processo, provavelmente atenderá às reais necessidades dos usuários. Porém, realizar as atividades da engenharia de requisitos sem apoio ferramental é uma tarefa árdua. Baseado nisto, temos trabalhado no desenvolvimento de ReqSys, um sistema de apoio ao processo de engenharia de requisitos. Para prover este apoio, ReqSys implementa uma estratégia orientada a aspectos para modelagem de requisitos apresentada em [SILVA, 2006], que consiste nas atividades de separação, composição e visualização de características transversais para abordar os problemas de espalhamento e entrelaçamento de requisitos nesta etapa do processo de desenvolvimento. Na Separação, os requisitos são modelados através de uma Linguagem de Modelagem de Requisitos Orientada a Aspectos (LMROA), que permite explicitar quais e como alguns requisitos tendem a estar espalhados ou entrelaçados aos outros. Durante a Composição, os requisitos anteriormente separados, que mantêm relacionamento 127

132 transversal, são combinados. E a atividade de Visualização, foco deste trabalho, provê modelos parciais do sistema. ReqSys utiliza a instância de LMROA, AOV-Graph [SILVA 2006], na qual as atividades de separação, composição e visualização estão centradas, e oferece as seguintes funcionalidades: análises léxica, sintática e semântica da modelagem de requisitos em AOV-Graph; a composição feita a partir da especificação AOV-Graph verificada e a extração de visões como modelos a partir das informações descritas num AOV-Graph. Este trabalho objetiva principalmente aprimorar a atividade de visualização implementada na versão inicial de ReqSys, para que através desta ferramenta o usuário adquira diferentes representações de um sistema, tais como matriz de rastreabilidade e modelo entidade-relacionamento, a partir das informações modeladas em AOV-Graph. Para atingir o objetivo principal, foram realizadas as seguintes atividades, que representam as contribuições deste trabalho: aprimoramento da estrutura inicial de ReqSys responsável pelas atividades de separação e composição de características transversais; definição e formalização de regras de mapeamento da linguagem AOV- Graph para outras linguagens de modelagem de requisitos; desenvolvimento, na ferramenta ReqSys, dos novos meios de visualização. Os produtos gerados são: gramáticas das linguagens de modelagem selecionadas e das regras de mapeamento; analisador léxico e sintático das linguagens de modelagem de requisitos selecionadas; interface no plug-in ReqSys para o Eclipse, que permita a utilização das novas funcionalidades. 2. Fundamentação Teórica Os requisitos de sistema que influenciam ou restringem uns aos outros por estarem fortemente relacionados são chamados de características transversais [TEKINERDOÐAN, 2004]. Estas características dificultam tanto a decomposição de sistemas de software complexos em unidades modulares menores quanto a composição destes módulos. O tratamento de características transversais em um alto nível de abstração, como o realizado durante a modelagem de requisitos, provê, entre outras vantagens, melhor compreensão do problema a ser resolvido e da solução proposta, antes que decisões de planejamento e desenvolvimento tenham sido tomadas sem levar em consideração a transversalidade dos requisitos [NUSEIBEH, 2004]. Este é um dos fundamentos da estratégia orientada a aspectos para modelagem de requisitos proposta em [SILVA, 2006], cujas atividades (separação, composição e visualização de características transversais) centram-se numa LMROA ReqSys Com o objetivo de oferecer auxílio ferramental à realização das atividades nas quais consiste a estratégia orientada a aspectos para modelagem de requisitos, desenvolvemos ReqSys, um sistema de apoio ao processo de engenharia de requisitos. 128

133 ReqSys, em sua primeira versão, utiliza a instância de LMROA, AOV-Graph. Assim, como apoio à atividade de separação, ReqSys realiza a verificação léxica, sintática e semanticamente a modelagem de requisitos em AOV-Graph. A partir desta modelagem em AOV-Graph verificada, ReqSys realiza a composição. E, como resultado da visualização, ReqSys gera, em sua primeira versão, uma visão do sistema, que informa como e quais os requisitos estão espalhados e entrelaçados. Apesar deste resultado ser uma representação do sistema, entendemos que uma única perspectiva é insuficiente para que o engenheiro de requisitos analise adequadamente o sistema a ser implementado. A fim de reparar esta limitação da ferramenta, este trabalho aprimora a atividade de visualização realizada por ReqSys, para que seja oferecida a seu usuário diferentes representações parciais do sistema, ou seja, diferentes visões, que incluem-se na categoria de visões como modelo [LEITE 1996] AOV-Graph AOV-Graph é uma instância de LMROA, que estende um modelo de metas, denominado V-Graph [YU 2004], que permite definir características transversais em requisitos. Os elementos que compõem um V-Graph são softmetas, que representam requisitos não funcionais; metas, que são regras de negócio; e tarefas, que representam requisitos funcionais realizados com o fim de atingirem as softmetas e metas. Estes elementos podem estar ligados entre si através de relacionamentos de contribuição e de correlação. AOV-Graph mantém os mesmos componentes de V-Graph, mas adiciona um novo tipo de relacionamento ao modelo de metas, o relacionamento transversal. Este novo relacionamento permite indicar na modelagem como e quais requisitos estão espalhados e/ou entrelaçados Visões Visão é uma abstração do sistema em estudo, que pode ser baseada em diferentes abordagens [SOMMERVILLE 2000]. Consequentemente, uma visão representa parcialmente o modelo completo do sistema, realçando as características consideradas mais importantes para determinado ponto de vista. [LEITE 1996] classifica as visões em três categorias, que se complementam: visões como opiniões, visões como serviços e visões como modelos. Sendo a visão como modelos uma perspectiva do sistema dada por um tipo de modelo de sistema. A evolução, proposta neste trabalho, da funcionalidade de visualização de requisitos oferecida por ReqSys, consiste na criação de visões como modelos, a partir de uma modelagem em AOV-Graph. Para isto utilizamos regras de mapeamento entre AOV-Graph e matriz de rastreabilidade e entre AOV-Graph e modelo entidaderelacionamento (MER). AOV-Graph permite descrever relacionamentos transversais e centraliza, nestas descrições, informações de dependência entre requisitos, o que facilita a identificação do rastro entre eles. Sendo assim, o próprio relacionamento transversal pode ser visto como 129

134 uma matriz de rastreabilidade, embora não abranja todos os requisitos modelados, representando, então, uma matriz parcial de rastreabilidade. Com a automatização da geração de matrizes de facilidade de rastreamento, aproveitam-se todos os mecanismos da linguagem AOV-Graph criados para tratar rastreabilidade. E, apesar de informações sobre cardinalidade dos relacionamentos não poderem ser extraídas de uma especificação AOV-Graph, sugerir quais os possíveis entidades e atributos e como estes elementos se relacionam é uma importante contribuição que ReqSys oferece ao seu usuário. 3. Mecanismo de Visualização Para gerar visões automaticamente a partir de uma especificação AOV-Graph, é necessária a conversão do modelo AOV-Graph em matrizes de rastreabilidade e MER, o que exige o mapeamento entre as linguagens baseado em regras de transformação, definidas neste trabalho. Apesar da nova versão de ReqSys automatizar o mapeamento entre os modelos de requisitos, as regras podem ser utilizadas para converter um modelo em AOV-Graph para outro manualmente, o que possibilitou a validação destas regras antes da implementação desta funcionalidade em ReqSys. Figura 1. Transformação entre visões O mecanismo de visualização de ReqSys requer um conjunto de informações, que consiste em: sintaxe e semântica das linguagens de origem (AOV-Graph), de destino (matriz de rastreabilidade e MER) e as regras de mapeamento. Sendo assim, fezse necessária a formalização das sintaxes destes modelos, de forma que seus elementos gráficos, tabelas e grafos, possam ser representados através de gramáticas. Cada uma destas gramáticas representa a Sintaxe do Modelo Final, utilizada na transformação do modelo AOV-Graph para outras visões, como ilustra a Figura 1. O mecanismo de visualização foi implementado utilizando como arquivo de entrada um modelo AOV-Graph no formato.txt. A partir desta especificação, que passa pelas análises léxica, sintática e semântica, é gerado um arquivo intermediário, também em formato texto, com a representação do sistema modelado segundo a sintaxe da visão escolhida pelo usuário. Este arquivo intermediário, apesar de ser gerado automaticamente, também passa por analisadores. Após esta etapa, é gerado um arquivo HTML, se a visão escolhida foi matriz de rastreabilidade ou um arquivo.dot, se a visão escolhida foi MER. 130

135 Figura 2. Plug-in ReqSys em funcionamento ReqSys tem sido desenvolvido como um plug-in para a Eclipse IDE. Portanto, o mecanismo de visualização é oferecido ao usuário através deste ambiente de desenvolvimento. Na Figura 2, temos o workbench do Eclipse, ou seja, sua área de trabalho no momento em que o plug-in ReqSys está sendo utilizado. Instruções sobre como instalar e utilizar a ferramenta encontram-se em 4. Estudos de Caso Foram realizados dois estudos de caso que demonstram os resultados das extrações de matrizes de rastreabilidade e de modelos entidade-relacionamento, a partir de especificações em AOV-Graph. O primeiro estudo de caso é um ambiente colaborativo que apóia a edição de cenários e léxicos, chamado C&L. O segundo, UniCal, é um sistema para agendamento e divulgação de eventos universitários. A Figura 3 apresenta um trecho da especificação AOV-Graph de C&L utilizado como arquivo de entrada no processo de criação automática do MER, mostrado na Figura 4. Figura 3. Trecho de especificação AOV-Graph do estudo de caso C&L Figura 4. MER gerado automaticamente por ReqSys a partir de modelo AOV- Graph do estudo de caso C&L 131

136 5. Conclusão Este trabalho aborda a atividade de mapear modelos de requisitos em AOV-Graph para MER e matrizes de rastreabilidade, propondo regras para este mapeamento e a automatização desta atividade através da ferramenta ReqSys. Esta automatização faz parte da evolução da funcionalidade de Visualização oferecida por ReqSys, que implementa também as atividades de verificar especificações em AOV-Graph e de compor características transversais. Sendo assim, este trabalho preocupou-se não só em definir e validar as regras de transformação entre modelos de requisitos, mas também em oferecer meios para que o mapeamento não seja realizado apenas manualmente. Apresentamos como contribuições deste trabalho: o aprimoramento da estrutura inicial de ReqSys; a definição de regras de mapeamento da linguagem AOV-Graph para outros modelos; a visualização gráfica dos modelos AOV-Graph, MER e matrizes de rastreabilidade; gramáticas das linguagens de modelagem selecionadas; analisadores léxico e sintático das linguagens de modelagem de requisitos selecionadas e interface no plug-in ReqSys para o Eclipse, que permite a utilização das novas funcionalidades. Como limitações deste trabalho temos: a extração de apenas dois modelos de requisitos; rastreabilidade apenas entre requisitos e não entre requisitos e artefatos; necessidade de mais estudos de caso e de um estudo avaliativo da qualidade do MER gerado por ReqSys; utilização apenas de uma instância de LMROA (AOV-Graph); uso limitado das funcionalidades do Eclipse e utilização do GraphViz na geração da visualização gráfica de alguns modelos gerados automaticamente. Referências LEITE, J. C. S. P. (1996) Viewpoints on Viewpoints. In: ACM JOINT PROCEEDINGS OF THE SIGSOFT'96 WORKSHOPS, ACM Press. p NUSEIBEH, B. (2004) Crosscutting requirements. In: PROC. OF THE 3RD INTERNATIONAL CONF. ON ASPECT-ORIENTED SOFTWARE DEVELOPMENT (AOSD 2004), Lancaster-UK, p ISBN: ROCHA, D. K. F. et al. (2008) Relatório Parcial de Pesquisa PIBIC do projeto ReqSys: Um Sistema de Apoio ao Processo de Engenharia de Requisitos. SILVA, L. F. (2006) Uma Estratégia Orientada a Aspectos para Modelagem de Requisitos. Rio de Janeiro, p. Tese de Doutorado em Engenharia de Software - PUC-Rio. Disponível em: Acesso em: 15 outubro SOMMERVILLE, I. (2000) Software Engineering, Ed. 6th, Addison- Wesley. TEKINERDOÐAN, B. et al. (2004) Early aspects: aspect-oriented requirements engineering and architecture design. Report. In: EARLY ASPECTS WORKSHOP AT AOSD, England. YU, Y.; LEITE, J.; MYLOPOULOS, J. (2004) From goals to aspects: discovering aspects from requirements goal models. In: PROC. OF IEEE INTERNATIONAL SYMPOSIUM ON REQUIREMENTS ENGINEERING (RE'04), Japan. pp

137 Melhorando a Vazão TCP em MANETs Vinícius de M. Rios 1,3, Cláudio de C. Monteiro 2,3, Vanice C. Cunha 3 1 Universidade do Tocantins (UNITINS) 108 Sul Alameda 11 Lote 03 Cx. Postal CEP.: Palmas - TO - Brasil 2 Instituto Federal de Educação, Ciência e Tecnologia do Tocantins (IFTO) 3 Universidade de Brasília (UnB) Abstract. This article aims to present a proposal for improvement in the transmission of TCP data in a MANET (Mobile Ad Hoc Networks), in order to ensure the delivery of packages, even by changing the delivery route due to mobility of nodes. For this, we propose an architecture that aims to eliminate this problem through storage utilization of a backup route drawn up based on the discovery of neighboring nodes using measurements signal level on the hostsinvolved. Resumo. Este artigo tem como objetivo apresentar uma proposta de melhoria na transmissão de dados TCP em uma MANET (Mobile Ad Hoc Networks), com o intuito de garantir a entrega dos pacotes, mesmo mediante a alteração das rotas de entrega devido a mobilidade dos nós. Para isso, propomos uma arquitetura que visa eliminar esse problema através da utilização de armazenamento de uma rota backup traçadas com base na descoberta de nós vizinhos usando medições de nível de sinal nos hosts envolvidos. 1. Introdução As redes sem fio se tornaram uma forma alternativa de transmissão de dados para dar mobilidade aos usuários que necessitam se deslocar e ao mesmo tempo ter acesso a qualquer tipo de informação seja ela uma página WEB, um arquivo, ou até mesmo acesso a aplicativos online. Em ambientes wireless Ad hoc móveis essas transferências de dados possuem o problema da degradação da performance da transmissão, pelo fato dos nós se moverem, fazendo com que a conexão estabelecida previamente seja quebrada. Nas transmissões onde o protocolo é o TCP, a degradação da performance do enlace de dados dar-se-á por conta da janela de congestionamento e pelas retransmissões dos pacotes perdidos, visto que, o TCP entende a quebra de link como sendo um problema de congestionamento na rede [Yu 2004]. Portanto, este artigo tem como objetivo apresentar uma proposta de cenário para melhorar a vazão dos dados TCP, sem que a transmissão seja comprometida, criando uma rota backup em cache no nó emissor através do protocolo de roteamento DSR, onde essa rota será utilizada, caso alguns dos nós intermediários da rota principal comecem a se locomover, dando indícios de que irá deixar o local. Para isso serão utilizados 3 (três) níveis de sinais, onde cada nível indicará ao nó emissor que este 133

138 deverá regular a sua janela de congestionamento mediante ao estado da rede, caracterizando um comportamento crosslayer entre a camada de rede e a camada de enlace. Em particular no último nível de sinal, avisando ao nó emissor que a rota está quebrada e que a partir desse momento a rota backup deverá ser utilizada. 2. Contextualização 2.1. Modelo As redes Wi-Fi são um grande avanço no modo de transmissão de dados entre computadores fornecendo mobilidade para os equipamentos, ou seja, não havendo a necessidade destes ficarem no mesmo lugar ou evitar a movimentação das pessoas pelos lugares. Há vários sub-padrões para as tecnologias de LAN (Local Area Network) sem fio , denominados a, b e g (Figura 1), que possuem algumas características em comum como: a utilização da mesma estrutura de quadro na camada de enlace, a capacidade de reduzir sua taxa de transmissão para alcançarem distâncias maiores e permitirem dois modos de acessos como infra-estruturada e Ad hoc [Kurose and Ross 2006]. Outros modelos foram criados a partir dos já citados anteriormente para que fossem introduzidas algumas características como segurança, aumento de vazão, redução de consumo de energia, qualidade de serviço, entre outros para a melhora do tráfego de dados [Monteiro and Gondim 2009]. Figura 1. Modelo (MANET) [Kim 2009]. Uma rede wireless Ad Hoc se diferencia de uma rede infra-estruturada por não necessitar de um ponto de acesso (coordenador central) para troca de informações. Isso acontecerá entre os nós da rede, retransmitindo os dados entre seus vizinhos (multi-hop), como pode ser observado na Figura 1. Por ser na grande maioria das vezes uma rede móvel, esta forma de transmissão está susceptível a alguns tipos de problemas como: quebra de link, limitações de recursos (largura de banda, energia computacional, tempo de vida da bateria), interferência co-canal, entre outros que necessitam ser solucionados para melhorar a vazão de dados entre os nós [Xu, Hischke and Walke 2003]. Uma rede wireless Ad Hoc pode ser aplicada nos seguintes cenários [Kim 2009]: Redes celulares; Computação colaborativa; 134

139 Resgate de emergência; Redes mesh; Redes de sensores; Aplicações militares TCP (Transmission Control Protocol) O TCP tem como objetivo criar uma conexão fim-a-fim confiável em um ambiente de rede não confiável. Foi projetado para se adaptar dinamicamente as propriedades da rede e ser robusto diante dos muitos tipos de falhas que podem ocorrer como erros e perdas de pacotes. É uma conexão do tipo full-duplex e ponto-a-ponto, portanto não havendo mais que dois computadores utilizando da mesma transmissão de dados [Tanenbaum 2003]. As conexões TCP são feitas por um handshake de três vias entre o emissor e o destinatário, conforme exemplificado na Figura 2. Figura 2. Handshake entre 2 computadores [Tanenbaum 2003]. Portanto, quando uma conexão é estabelecida, o transmissor ajusta a janela de congestionamento ao tamanho do segmento máximo MSS (Maximum Segment Size) em uso na conexão. Em seguida, ele envia um segmento máximo. Se esse segmento for confirmado antes de ocorrer um timeout (término do tempo máximo de espera de confirmação do pacote transmitido), o transmissor incluirá o número de bytes de um segmento na janela de congestionamento, de modo que ela tenha capacidade equivalente a dois segmentos máximos, e em seguida enviará dois segmentos. À medida que cada um desses segmentos for confirmado, a janela de congestionamento será aumentada em um tamanho de segmento máximo. A janela de congestionamento chegará a n segmentos, se todos eles forem confirmados a tempo, portanto a janela de congestionamento será aumentada do número de bytes correspondente a n segmentos [Tanenbaum 2003] DSR (Dynamic Source Routing) O protocolo DSR utiliza-se de roteamento sob demanda por ser reativo, ou seja, só cria sua rota em função da necessidade de entrega de um pacote e por fonte, isto é, a cada nó em que o pacote passa para chegar ao seu destino, este adiciona em seu cache o caminho completo e ordenado que o pacote deve percorrer [Resende 2009]. 135

140 Ele implementa dois mecanismos em demanda: Route Discovery e Route Maintanance. No Route Discovery a busca por um nó destino é feita em broadcast através de um route request, portanto, quando um nó recebe um route request, este verifica em seu cache se possui uma rota para o nó destino, caso tenha, ele devolve um route reply com a concatenação da rota fonte no route request mais a rota em seu cache. Por outro lado, se o nó não tiver em seu cache o nó destino, ele faz o rebroadcast do route reply com o seu endereço fonte. Portanto, cada nó que encaminha o pacote adiciona a si próprio no pacote e quando ele alcança o nó destino este o retransmite contendo a rota completa para o nó emissor [Yu 2004]. O Route Maintanance tem como objetivo receber a confirmação de que o pacote alcançou o próximo nó para o nó que o emitiu. Caso não receba uma confirmação após várias tentativas de retransmissão, o nó então envia um route error para o nó emissor dizendo que houve uma quebra de link. Portanto, cada nó irá remover de seu cache de rotas esse nó inalcançável [Yu 2004]. A Figura 4 ilustra o funcionamento do protocolo DSR. Figura 4. Protocolo DSR [Tanenbaum 2003]. 3. Metodologia de implementação O cenário será criado em um ambiente virtual, ou seja, todos os testes serão configurados e criados via simulação, utilizando o software destinado a esse tipo de ambiente de redes wireless Ad Hoc móveis, que é o Glomosim por ser bastante robusto e possível de implementar novas características. 4. Funcionalidade Para que se possa ter uma boa performance na entrega de dados pelo TCP em um ambiente wireless Ad hoc móvel, será necessário que os nós se movam o menos possível mantendo o estado do link de comunicação sempre estável. Como nem sempre é possível manter um ambiente estático, há a necessidade de criar uma forma de que os dados possam ser entregues sem comprometer a vazão dos dados. A melhoria da vazão dos dados em uma MANET dar-se-á da seguinte forma: utilizar o protocolo de roteamento DSR para armazenar duas rotas, uma default e uma backup; fazer medições de nível de sinal em cada nó e estabelecer um limiar mínimo de qualidade de transmissão em 3 níveis, sendo eles: α, β e σ, onde nos níveis α e β será alterado a janela de congestionamento para que os dados fluam de acordo com o movimento do nó e no nível σ a transmissão fluirá pelo emissor através da rota backup. A Figura 5 exemplifica esse funcionamento. 136

141 Figura 5. Proposta para melhoria da vazão TCP. O nó A irá procurar uma rota para o nó E, para isso ele utilizará o protocolo de roteamento DSR para encontrar e armazenar uma rota principal e ao mesmo tempo encontrar e armazenar uma rota backup. Feito isso, os dados começam a trafegar de A para E. Depois de um determinado tempo de transmissão, o nó D começa a se mover. Como este está sempre medindo o seu nível de sinal em relação aos seus vizinhos e comparando com o limiar de qualidade de sinal, verificou-se que o seu nível de sinal encontra-se no nível α e que então precisa enviar uma mensagem para o nó A para que diminua a janela de congestionamento em 2x. Após um determinado tempo o nó D ainda está se movendo e agora se encontra no nível β e então envia uma outra mensagem para o nó A para que diminua a sua janela de congestionamento em 4x. Após se mover mais um tempo o nó se encontrará no nível σ e praticamente fora do alcance dos outros nós e com o nível de transmissão e sinal muito ruim para que possa continuar a conexão, portanto o nó D envia uma mensagem ao nó A informando que a partir deste momento é necessário utilizar a rota backup para o nó E, visto que aquela rota está quebrada. Feito isso, a transmissão dos dados irá fluir de A para E pela rota backup, otimizando o seu tempo de transmissão. Essa diminuição da janela de congestionamento é necessário para que os pacotes enviados não fiquem esperando na fila nos nós intermediários, mantendo um seqüenciamento correto quando chegar ao nível σ, ou seja, para que não haja necessidade de retransmissão de pacotes quando a transmissão fluir pela rota backup. 5. Resultados esperados Esperasse obter uma melhor performance no que tange a transmissão de dados entre hosts móveis, visando garantir a entrega de todos os pacotes, havendo o mínimo de congestionamento destes na rede. Para tanto, as medições de sinal mais o protocolo DSR, juntamente com o TCP são peças importantes para que haja a rápida percepção da 137

142 quebra de link e com isso prontamente ajustar as configurações desse protocolo para que os pacotes de dados não congestionem a rede como um todo. 6. Referências Monteiro, C. C. and Gondim, P. R. L. (2009). Improving Video Quality in Networks. INFOCOM workshop, Eshak N. and Baba M. D. (2003). Improving TCP Performance in Mobile Ad Hoc Networks, Faculty of Electrical Engineering, Universiti Teknologi MARA. Tanenbaum, A. S. (2003). Redes de Computadores, Elsevier, 4th edition. Yu, X. (2004). Improving TCP Performance over Mobile Ad Hoc Networks by Exploiting Cross-Layer Information Awareness, Department of Computer Science, New York. kurose, J. F. and Ross, K. W. (2006). Redes de Computadores e a Internet Uma abordagem top-down, Addison Wesley, 3th edition. Kim, Dongsoo Stephen. (2009). Mobile Ad Hoc Networks, Disponível em <http://www.ece.iupui.edu/~dskim/manet/>. RNP (Rede Nacional de Ensino e Pesquisa). (2009). Desvendando o TCP, Disponível em <http://www.rnp.br/newsgen/9804/tcp.html#ng-fast>. Xu B.; Hischke, S. and Walke, B., The role of ad hoc networking in future wireless communications, Communication Technology Proceedings, ICCT International Conference on, vol.2, no., pp vol.2, 9-11 Abril

143 Simulação de Agentes com Aspectos Emocionais Antonino A. Feitosa Neto 1, Katyanna S. Bezerra 2, André M. C. Campos 1, Alberto Signoretti 2 1 Departamento de Informática e Matemática Aplicada / UFRN, Natal RN 2 Departamento de Ciência da Computação / UERN, Natal RN Abstract. This paper aims to address the insertion of emotional aspects in a computational model. The work is based on the OCC theory and uses a simulation environment for human organizations from a multiagent perspective, called Simorg. The paper analyzes the influence of the emotional model on the motivation of agents based on emotions resulting from the desire of the occurrence of events during the simulation. Resumo. Este artigo tem como objetivo abordar a inserção de aspectos emocionais em um modelo computacional. Este trabalho é baseado na teoria OCC e utiliza um ambiente de simulação de organizações humanas segundo o paradigma multiagente, denominado SimOrg. O artigo analisa a influência do modelo emocional em relação à motivação dos agentes devido a emoções resultantes do desejo da ocorrência de eventos durante a simulação. 1. Introdução Atualmente as organizações humanas estão cada vez mais complexas e imersas em um ambiente de volatilidade em ascensão, o que torna o processo de decidir algo de extrema importância para a sobrevivência da mesma. Isto tem levado ao uso de simulações organizacionais para realização de testes e avaliações de possíveis situações com o objetivo de aperfeiçoar o processo de tomada de decisão. O objetivo deste artigo é descrever como emoções podem ser aplicadas nos indivíduos de uma simulação organizacional a fim de obter uma representação mais realística de um cenário de organização. O uso de emoções em simulações de organizações se justifica devido a sua influência no sistema de decisão humano. Segundo Damásio [Damasio 1995] a tomada de decisão não é possível sem emoções e elas estão intimamente relacionadas com o processo de busca reduzindo o espaço de análise e compensando a incerteza dos dados percebidos. Desse modo, se espera que simulações em que os indivíduos estejam representados com características emocionais mais próximas da realidade. O restante deste artigo se divide em quatro seções. A próxima descreve o que são emoções e como representá-las computacionalmente. Em seguida, é descrito a metodologia utilizada para avaliar o modelo proposto. Isso inclui a descrição do sistema SimOrg e as modificações que foram efetuadas sobre ele para dar suporte as emoções. A seção seguinte descreve os resultados obtidos com ou sem o uso de emoções. Por fim, é feita algumas considerações finais sobre este trabalho. 139

144 2. Um Modelo de Agente com Emoção Em 1988, Ortony, Clore e Collins [Ortony et al. 1988] construíram uma teoria baseada na abordagem cognitiva da emoção explicando suas origens, o modelo OCC, como é conhecido, descreve os processos cognitivos que ativam cada uma destas emoções. Esta teoria resulta em um modelo psicológico que explica a origem de 22 tipos de emoções. Esta teoria é caracterizada por promover emoções como reações a eventos, agentes e objetos e é a partir destes elementos particulares que as situações emocionais são construídas. Cada reação de evento, agente ou objeto leva a um determinado grupo definido de emoções. Cada grupo de emoção é estruturado de modo que cada célula do grupo provê a especificação de um tipo de emoção incorporado a determinadas condições. Estas condições de desencadeamento de cada tipo de emoção, nestes grupos, são estruturalmente relacionadas, através de variáveis que identificam um agente e a atribuição de valência destes. Estas variáveis podem influenciar a intensidade de ocorrência das emoções nos grupos como um todo. Neste sentido, pode-se descrever uma técnica que proponha a validação de uma teoria que possa empregar as ferramentas de Inteligência Artificial para um modelo computacional. Na verdade, o intuito proposto pelo modelo OCC, não é o de criar máquinas com emoções, mas sim, criar um modelo computacional que possa descrever que emoções seriam mais susceptíveis para as pessoas em determinadas situações e/ou condições [Ortony et al. 1988] Modelagem Computacional Seguindo a teoria OCC, implementamos os tipos de emoção de bem estar, isto é, as emoções que emergem de como o indivíduo se sente em relação a ocorrência de um evento. Elas são nomeadas na teoria como joy e distress e serão desencadeadas caso o valor da intensidade da emoção sentida for positiva ou negativa respectivamente, ou seja, se o agente se sente bem com a ocorrência de evento então ele pode desencadear o joy. Em nossa implementação, desconsideramos o momento em que um evento ocorre e a influência das variáveis globais. Desse modo, o valor de potencial dessas emoções é igual ao valor das variáveis que as influenciam diretamente. De acordo com a modelo OCC, isso é representado pela intensidade do desejo que o evento ocorra, ou seja, a desirability da ocorrência de um evento. A desirability de um agente a, para um evento e num instante de tempo foi modelada através da função abaixo: D ( a, e) = Va. Pa. Pe O fator Pa simboliza a interpretação que o agente dá ao evento percebido facilitando ou não a geração destas emoções. O fator Pe é o peso do evento associado a desirability e representa a força com que o evento pode desencadear emoções. Ele independe dos agentes e simboliza a importância do evento de acordo com o com o contexto simulado. O peso e o potencial são valores reais na escala de zero a um. O fator Va é a valência da ocorrência do evento assumindo o valor 1 quanto o agente desejar a ocorrência e o valor -1 quando ele não desejar. Dependendo do valor da desirability o agente pode desencadear dois tipos de emoções distintos: Emoções do tipo joy que representa emoções como alegria e felicidade e são geradas quando o valor da desirability for maior que 0.25; Ou emoções do tipo distress que representa emoções como infelicidade e aflição e são geradas quando o valor da desirability for menor que Esses limiares (0.25 e -0.25) são descritos pela teoria OCC como valores que determinam se o potencial da desirability é suficiente para desencadear uma experiência emocional. Esses limiares são características individuais dos agentes, porém por simplicidade, assumimos que todos os agentes possuem os mesmos valores: 0.25 para joy e para distress. 140

145 O potencial de cada emoção é calculado como o valor da desirability da emoção desencadeada pelo agente, ou seja, toda emoção cujo valor da desirability ultrapasse o correspondente limiar, desencadeará um potencial emocional. Na teoria OCC, esses potenciais são característicos de cada tipo de emoção, em nosso sistema combinamos esses potenciais num único valor denominado de coeficiente emocional. É um valor que representa o estado emocional do agente. Inicialmente o seu valor é zero, representado o estado neutro, e quando ocorre um evento que desencadeie uma emoção, o valor do coeficiente emocional é atualizado para a média de seu valor com o valor do potencial gerado pela emoção de forma a refletir a influência do estado emocional anterior do agente Arquitetura dos Agentes O módulo deliberativo da arquitetura do agente é responsável por selecionar um conjunto de possíveis ações baseada nas prioridades, dependências e se os pré-requisitos das ações são válidos. A tomada de decisão é realizada de forma aleatória, porém seguindo uma distribuição baseada na utilidade de cada ação válida. Ou seja, ações com maior utilidade terá uma probabilidade maior de ser escolhida. Ações com utilidade próximas terão a mesma chance de ser escolhidas [Campos et al. 2006]. O cálculo da utilidade é baseado na distância entre o perfil de personalidade do agente e o perfil personalidade esperado de alguém que venha a executar a ação. Outro fator levado em consideração é o valor de motivação do agente. Ele reflete a vontade do agente em executar alguma ação e é diretamente proporcional ao desempenho do agente o qual depende somente da motivação e da distância entre o perfil de personalidade do agente e o perfil de personalidade esperado para ação a ser executada. A motivação do agente é calculada com base na fadiga, pressão e coeficiente emocional. A fadiga é um fator que controla a diminuição da motivação do agente com o passar do tempo, ou seja, a cada passo de simulação. O seu valor aumenta com o tempo e é inversamente proporcional ao valor da motivação. A pressão representa o ritmo de trabalho exigido do agente e é um valor real no intervalo de zero a um. Assim como a fadiga, é inversamente proporcional a motivação e também influencia o valor da fadiga de forma proporcional. Por fim, temos o coeficiente emocional que é um fator que pode contribuir de forma positiva ou negativa para motivação dependendo das emoções geradas pelo agente. A cada passo de simulação o valor da motivação é atualizado em função dos parâmetros citados anteriormente. De acordo com a função abaixo: 1 e m ' = I f.cos + 2 m' + m( t 1) m ( t) = + rand( 0.005,0.005) 2 ( f ) + I p.cos( p) + I e.cos + I f I p m é o valor da motivação no tempo t, f é o valor da fadiga do agente, p é o valor da pressão do agente, e é o valor do coeficiente emocional, I f é o peso associado com a fadiga, I p é o peso associado a pressão, I e é peso associado ao coeficiente emocional e rand é uma função de ruído que gera um valor aleatório entre dois valores (entre e 0.005). No tempo zero o valor da motivação é 1.0 e os valores de I f, I p e I e usados neste artigo são 0.4, 0.1 e 0.8 respectivamente. No início da simulação a fadiga, pressão e o coeficiente emocional são zero e somente a fadiga e o coeficiente emocional variam em função do tempo. A fadiga sempre é incrementada em uma unidade mais o valor da pressão até atingir o valor máximo, que é a quantidade de tempo estimada para o fim da simulação, calculado com base na quantidade de ações a serem 141

146 executadas na organização. O coeficiente emocional e varia numa taxa d, denominada de decaimento emocional, de modo que se o valor do coeficiente emocional for positivo então a cada passo de simulação ele será diminuído em d% do seu valor e caso seja negativo ele será aumentado em d%. Logo, o valor do coeficiente emocional sempre tende a zero e a velocidade com que ele diminui ou aumenta é controlado pelo parâmetro d que é um valor real no intervalo de 0 a 1. Ele controla o período de tempo, que um evento responsável por gerar um potencial emocional, terá influência sobre o valor de motivação do agente, de modo que quanto mais próximos de zero maior será o período de influência. Neste artigo usamos o decaimento emocional d igual a 0.1, ou seja, a cada passo de simulação o valor do coeficiente emocional é aumentado ou diminuído em 10% dependo do sinal do mesmo. Isso reflete o fato de que o efeito das emoções não é fixo, ou seja, se uma pessoa está contente, o potencial desta emoção diminui com o tempo de modo que gradualmente ela fique menos contente até a emoção desaparecer. 3. Metodologia Para efetuar testes sobre os agentes, realizamos experimentos de simulação sobre uma plataforma já existente, conhecida como SimOrg. Como citado anteriormente, o SimOrg [Canuto et al. 2006] é um simulador de organizações humanas desenvolvidas de acordo com o paradigma de sistemas multiagentes. Tem por objetivo representar o comportamento emergente da interação entre os indivíduos de uma organização. Pode ser usado para o treinamento de profissionais e análise de situações antes de seu acontecimento. Para tornar as simulações mais realistas, o SimOrg possibilita a modelagem individual dos integrantes da organização de acordo com uma teoria de personalidade. Isso modela o fato que as pessoas possuem características individuais e aptidões diferentes para tipos de atividades. Por exemplo, pessoas extrovertidas possuem maior facilidade para falar ao público do que pessoas introvertidas. Para uso como ferramenta de treinamento ou análise, o SimOrg permite a interação do usuário durante a simulação através da aplicação de eventos comuns numa organização. Por exemplo, numa empresa podemos aumentar o salário sobre os funcionários, aumentar a pressão exercida sobre eles, etc. Dessa forma o usuário pode analisar o efeito de sua intervenção sobre a simulação, podendo antecipar possíveis problemas e propondo soluções antes da ocorrência dos mesmos. Neste artigo, modificamos a arquitetura interna dos agentes do SimOrg para a arquitetura com emoções aqui descrita. Em virtude disto modificamos também os eventos do usuário sobre os agentes durante a simulação para atuarem de acordo com a emoção desencadeada no agente devido a aplicação do evento sobre ele Eventos de Simulação Modelados O objetivo dos eventos de simulação é permitir que o usuário tome decisões sobre os indivíduos da organização e avaliar o resultado das mesmas sobre o desempenho dos agentes. Modificamos o SimOrg para que as emoções possam ser igualmente representadas nos estados internos do agente. Isso significa que eventos sobre um agente com essa arquitetura resultará estas em reações diferentes das dos agentes anteriores, alteradas pela emoção que os agentes geram. Por exemplo, uma ação de motivação desencadeia emoções positivas em um agente, assim como ocorre na realidade. Neste artigo, trabalhamos com dois eventos: gratificação e aumento do ritmo de trabalho. Gratificar um agente faz com que sua motivação seja aumentada em 10%, sua fadiga seja diminuída em 20% (para diminuir o decaimento do valor da motivação). Para este evento, o agente possui uma valência Va igual a +1 e o potencial Pa igual a 1.0 e o peso Pe do evento é 142

147 igual a 0.5. Como a desirability calculada com estes valores ultrapassa o limiar do agente, o potencial emocional permanece o próprio valor de desirability, que é de 0.5. Aumentar o ritmo de trabalho de um agente faz com que sua pressão seja aumentada em 0.2. Para este evento, o agente possui uma valência Va igual a -1 e o potencial Pa igual a 1.0 e o peso Pe do evento é igual a 0.5. Como a desirability calculada com estes valores ultrapassa o limiar do agente, o potencial emocional permanece o próprio valor de desirability, que é de Simulações Realizadas Para avaliar a influência das emoções sobre os agentes, comparemos os valores de motivação (em função do tempo) de um mesmo agente em simulações onde as emoções podem ser geradas ou não como resultado dos eventos de simulação. As simulações em que as emoções não podem ser geradas, são as simulações onde os eventos possuem o peso Pe igual 0. Desta forma, o valor do coeficiente emocional é sempre zero o que não influencia no cálculo da motivação do agente. Consideramos também, a aplicação de quatro seqüências de eventos diferentes tentando refletir seqüências de emoções positivas, seqüências de emoções negativas e misturas delas. Cada seqüência corresponde a uma simulação e para cada uma utilizamos um modelo de agente com emoção e outro sem emoção. Logo, temos um total de oito simulações. Em cada simulação, os eventos são foram aplicados nos mesmos instantes: o primeiro evento no instante de 60 dias; o segundo com 70 dias; e o terceiro com 80 dias. Esses intervalos foram escolhidos de modo que o potencial emocional, gerado por cada evento, seja combinado com o potencial da emoção anterior, isto é, o intervalo de 20 dias não é suficiente para que o decaimento emocional tenha levado o valor do coeficiente emocional para zero. 4. Resultados Obtidos Os resultados são apresentados como gráficos da motivação de um agente em função do tempo. Para cada seqüência de eventos temos um gráfico que possui duas séries: ME correspondente ao valor da motivação na simulação sob influência das emoções e a MS sem influência das mesmas. Figura 1. O título dos gráficos representa a sequência de ações realizadas, onde G significa uma gratificação (repercutindo positivamente) e R, um aumento de ritmo de trabalho (repercutindo negativamente). A série ME corresponde aos valores de motivação do agente na simulação sob influência das emoções e a série MS sem influência das mesmas. 143

148 Como podemos notar, com a aplicação de um evento de gratificação ou aumento do ritmo de trabalho, a motivação do agente irá aumentar, ou diminuir respecitvamente, de forma proporcional ao potencial da emoção gerada e este valor sofrerá influência da seqüência de aplicação de eventos antes dele. Por exemplo, no gráfico RRR da figura 1 observamos que a motivação do agente sofre uma diminuição maior na terceira aplicação do evento de aumento do ritmo de trabalho (instante de tempo 80) do que na primeira aplicação do mesmo evento (instante de tempo 60). Isso é explicado pelo fato do coeficiente emocional ser um acumulador (devido a atualização pela média do valor corrente e o novo potencial) dos potenciais das emoções geradas. Esta influência também depende do valor de decaimento emocional, de forma que quanto menor o seu valor, maior será o tempo que o potencial de uma emoção irá durar, influenciando o valor do coeficiente emocional. 5. Considerações Finais Modificamos o sistema SimOrg para dar suporte a modelagem de emoções aqui descrita. O Modelo é baseado na teoria OCC e resultou numa função que influencia a motivação dos agentes sempre que uma emoção é gerada a qual depende dos eventos gerados sobre eles durante a simulação. Estes agentes apresentaram uma diferença comportamental coerente em resposta às diferentes seqüências de eventos. Isto é, como resposta a aplicação de eventos desejados, apresentaram um aumento em seu valor de motivação durante a simulação e, de modo análogo, uma diminuição como resposta a aplicação de eventos não desejados. Dessa forma, verificamos que o modelo proposto é capaz de tornar o comportamento dos agentes mais credível. No entanto, temos que considerar as simplificações feitas sobre o modelo proposto: utilizamos somente duas emoções das 22 descritas no modelo OCC e o ambiente é não é complexo, pois consideramos somente a aplicação de dois eventos e não está sendo consideradas as relações interpessoais dos agentes. O grande desafio de modelar seres humanos artificiais é especificar comportamentos que possam ser considerados plausíveis. Este é um termo subjetivo que reflete como interpretamos as reações de um personagem artificial segundo nossa própria experiência. De acordo com esta, o comportamento simulado pelos agentes dotados de emoção, descrito neste artigo, apresenta um comportamento mais plausível (ou credível) do que o comportamento do agente sem emoção. Isto decorre do fato que o fator emocional do primeiro sofreu alterações que foram se acumulando ao longo do tempo. Isto reflete à memória emocional de eventos positivos e/ou negativos que nos acontecem e que, certamente, influenciam em como interpretarmos eventos posteriores. Por esta razão, apesar das simplificações realizadas, julgamos o comportamento destes agentes mais plausíveis. Referências CAMPOS, A. M. C., Canuto, A. M. P., Santos, E. B., Alchieri, J. C. and Soares, R. G. F. A Flexible Framework for Representing Personality in Agents. Em International Conference on Autonomous Agents and Multi-agent System (AAMAS), Hakodate, Japan, CANUTO, A. M. P., Campos, A. M. C., Santos, A. M., Moura, E. C. M., Santos, E. B., Soares, R. G. and Dantas, A. A. Simulating Working Environments Through the Use of Personality- Based Agents. LNAI IBERAMIA/SBIA, v p DAMASIO, Antonio R. Descartes Error Emotion, Reason and the Human Brain. New York: ORTONY, Andrew; Clore, Gerald L.; Collins, Allan. The Cognitive Structure of Emotions. New York: Cambridge University Press,

149 Múltiplas conexões Bluetooth no ambiente da televisão digital interativa Kaio A. A. Dantas¹, Aquiles M. F. Burlamaqui², Ivan S. Silva¹ 1 Departamento de Informática e Matemática Aplicada (DIMAp) Universidade Federal do Rio Grande do Norte (UFRN) Campus Universitário Lagoa Nova Natal RN CEP: Departamento de Computação e Automação (DCA) Universidade Federal do Rio Grande do Norte (UFRN) Abstract. This paper describes the interaction form generated between a TVDI receptor and users using portable devices with Bluetooth connection for interaction. The management of several Bluetooth simultaneous connections is made to permit a net formation with many users beside that a Bluetooth device has a small and limited number of active connections. Resumo. Este artigo aborda a forma de interação gerada entre um receptor de TVDI e usuários utilizando dispositivos portáteis com conexão Bluetooth para interação. O gerenciamento de várias conexões Bluetooth simultâneas é feito de forma que seja possível a criação de uma rede com varios usuários uma vez que um dispositivo Bluetooth possui um número pequeno e limitado de conexões ativas 1. Introdução Com o avanço nas pesquisas e na padronização do sistema de televisão digital interativa no Brasil, um problema surge relacionado ao modo como diversos usuários podem interagir com um televisor ao mesmo tempo. Algumas ferramentas para gerenciamento dessas interações por múltiplos usuários estão sendo desenvolvidas, sendo uma delas o gerenciamento de conexões por tecnologia Bluetooth entre os dispositivos pessoais, como celulares, PDA s, dispositivos multimídia, etc., e um receptor TVDI. O controle das conexões Bluetooth (que é a conexão que abrange um maior número de dispositivos) deve ser feito de forma que vários dispositivos possam se comunicar com um único receptor, tendo em vista que um dispositivo só pode ter até sete conexões ativas (ou até menos, dependendo do dispositivo). Desta maneira, uma forma de capacitar a conexão de muitos dispositivos deverá ser encontrada, possibilitando o uso de um receptor com um elevado numero de usuários simultâneos. 2. Tecnologias de comunicação sem fio Três tecnologias de comunicação sem fio bastante difundidas são o Bluetooth, o Infravermelho e o Wi-Fi. Em comparação ao Infravermelho e Wi-Fi, o Bluetooth tem alguns pontos positivos e também alguns negativos, porém é o mais adequado ao uso junto a dispositivos portáteis. 145

150 O Infravermelho é precursor do Bluetooth, sendo suas taxas de transmissão muito baixas, além de necessitar que os dispositivos estejam numa mesma linha de visão, já que utiliza raios infravermelhos para transferência de dados. Ele se destacou pelo uso em controles remotos e também pela utilização em trocas de arquivos por celulares e dispositivos móveis até que o Bluetooth foi lançado e começou a ser difundido. Um ponto negativo é que o infravermelho possui uma pequena distância de cobertura, em torno de 1m. Seu custo e seu consumo de energia também são pequenos, como no Bluetooth. A tecnologia Wi-Fi possui uma grande área de cobertura e alta taxa de transferência de dados, porém é uma tecnologia mais cara e que consome mais energia. Enquanto o Bluetooth é um substituto para o cabo em uma variedade de aplicações, o Wi-Fi é um substituto do cabo apenas para acesso à rede local, possuindo alguns objetivos diferentes. O Bluetooth é mais pratico e não exige tanto em termos de configurações para se criar uma comunicação entre dois dispositivos. A tabela a seguir mostra as características de cada tecnologia. Infravermelho Wi-Fi Bluetooth Alcance (por padrão) ~ 1m ~ 1 a 100m ~ 1 a 10m Transferência de dados Baixa Alta Média Baixa Custo Baixo Alto Baixo Consumo de energia Baixo Alto Baixo Tabela 1 Comparativo entre as características das tecnologias Por ser voltado para comunicações rápidas e entre dispositivos portáteis, havendo um menor consumo de energia, e, principalmente, por ser a tecnologia mais difundida entre os celulares e outros dispositivos portáteis, o Bluetooth foi escolhido neste trabalho como forma de conexão entre os dispositivos de interação e um receptor de TVDI. Bluetooth é uma especificação de protocolos para comunicação sem fio projetado para comunicação e transferência de uma baixa taxa de dados entre diferentes dispositivos próximos, provendo um baixo consumo de energia e dispositivos de baixo custo. A tecnologia utiliza uma freqüência de rádio de curto alcance globalmente não licenciada e segura, possuindo uma área de alcance pequena, variando entre 1 a 10 metros, e posteriormente aumentada para uma área de até 100 metros, dependendo da classe do dispositivo e hardware utilizado. Alguns dispositivos mais antigos podem ter serviços limitados, como apenas uma conexão por vez, menor alcance, etc. A taxa de transferência de dados é de até 1 Mbps na versão 1.2 da especificação, 3 Mbps na versão 2.0 e de até 24 Mbps na versão 3.0. Por ter a característica principal de baixo consumo de energia, a tecnologia é ideal para o uso em dispositivos portáteis que sofrem de restrições em relação a fonte de alimentação e uso de baterias, como é o caso de celulares e PDA s, além de computadores portáteis, impressoras, eletrodomésticos inteligentes como geladeiras, etc. 146

151 O protocolo possui uma arquitetura Cliente-Servidor, possibilitando a criação de redes pessoais sem fio (Personal Area Network - PAN). A tecnologia Bluetooth é formada de hardware de transmissão por ondas de radio na freqüência 2,45 GHz, uma pilha de protocolos e perfis de interoperabilidade. A pilha de protocolos provê alguns protocolos de alto nível e API s para o serviço de busca por dispositivos e entradas e saídas seriais, além de prover também protocolos de baixo nível para segmentação de pacotes, multiplexação e qualidade de serviço. Cada dispositivo possui um identificador único de 48bits, sendo denominado Bluetooth Address. Os endereços geralmente são mascarados por um nome atribuído ao dispositivo que pode ser configurado pelo usuário. Com esse identificador, uma lista de pareamento pode ser criada em cada dispositivo, e, estando um dispositivo nesta lista, ele estará apto a se comunicar com o outro dispositivo que foi previamente pareado. Parear dispositivos significa estabelecer uma conexão e autenticá-la, permitindo a troca de informações entre os aparelhos conectados. Os dispositivos podem realizar uma varredura em busca de outros dispositivos disponíveis, porém cada um deles pode ser configurado para estar visível ou não. Mesmo que um dispositivo esteja invisível, se o que estiver buscando já estiver previamente pareado sabendo o endereço do outro dispositivo, é possível criar uma conexão entre eles. Uma aplicação que use Bluetooth pode ser servidora, cliente ou pode criar uma rede P2P, fazendo o papel de cliente e servidor. Na conexão entre dispositivos, o primeiro passo é a inicialização da pilha de protocolos, em seguida o cliente verifica os dispositivos que estão próximos a ele seguido de uma verificação dos serviços oferecidos por estes dispositivos. Um servidor deve informar os serviços disponíveis para os clientes, para isso ele registra os serviços no SDDB (Service Discovery Database) e fica aguardando conexões. Ao finalizar um serviço ele é removido do SDDB. 3. Gerenciamento de conexões Bluetooth Para o gerenciamento das conexões no ambiente de TVDI, o receptor TVDI pode estabelecer a forma como essas conexões serão organizadas ou requisitar que os dispositivos também façam parte da rede de gerenciamento, deixando de ser escravos, passando a ser mestres na arquitetura de redes Bluetooth. As arquiteturas podem ser definidas de três formas: um ambiente que possui apenas o receptor e um usuário, um ambiente com um receptor e até sete usuários utilizando um dispositivo de interação, e um ambiente com um receptor e vários usuários interagindo com seus dispositivos. A primeira arquitetura seria o caso de um usuário interagindo direto com a TV utilizando um controle remoto ou mesmo outro dispositivo. Na segunda arquitetura, como um dispositivo Bluetooth suporta até sete conexões ativas, é possível a interação de até sete usuários sem necessitar o desenvolvimento de uma forma de gerenciamento mais complexa das conexões. O receptor poderia conectar-se diretamente a cada um dos dispositivos e trocar 147

152 informações com eles (enviar questões, obter respostas, mostrar resultados dos questionários, etc.). Assim, uma rede piconet pode ser criada entre eles. A terceira arquitetura é o caso mais complexo. Para a troca de informações entre vários dispositivos, redes piconets e scartternets devem ser criadas para gerenciamento do trafego de dados. Neste modelo, o receptor (mestre) tentará se conectar a um maior número de dispositivos (escravos) criando uma piconet, e estes escravos, por sua vez, irão se conectar a outros dispositivos que ainda não estão conectados, criando outras piconets. O dispositivo que era escravo passa a ser um mestre na piconet criada por ele, e desta forma é criada uma scartternet (interligação das piconets). Alguns celulares possuem limitações sobre o numero de conexões Bluetooth simultâneas, como apenas uma ou duas conexões, devido a restrições no consumo de energia, então se existirem outros dispositivos com mais recursos, como PDA s, computadores, etc. no ambiente, estes serão escalonados como mestres em piconets. A princípio será verificado os recursos Bluetooth disponíveis em cada dispositivo, em seguida será feita uma seleção dos mestres de acordo com os mais aptos. Para os celulares ser capazes de gerenciar as conexões, aplicativos JME devem ser criados com um algoritmo incluso para organização das redes Bluetooth, pois caso eles necessitem criar piconets entre si, o aplicativo já estará apto a fazer esse gerenciamento em sintonia com o receptor. Assim, os celulares poderão ter status de escravos e mestres em diferentes piconets (um dispositivo não pode ser mestre em mais de uma piconet). A Figura 1 a seguir esboça a arquitetura com as diferentes piconets formando uma scartternet. Figura 1 - Redes Bluetooth 148

153 Atualmente a tecnologia está bastante difundida e continua evoluindo, a versão mais atual da especificação é a 3.0, que foi lançada no inicio de 2009, conseguindo atingir velocidades de transferência de aproximadamente 24 Mbps com praticamente o mesmo consumo de energia da versão 2.0, além de ser compatível com as versões anteriores. Alguns novos protocolos e características foram adicionados na nova especificação, provendo mais serviços e possibilidades aos usuários e desenvolvedores. 4. Arquitetura desenvolvida para o sistema integrado interativo Inicialmente foram criados programas televisivos interativos com questionários e neles são embutidos aplicativos de interação por celulares para distribuição. O usuário ativa o envio dos aplicativos do receptor para os celulares dentro da área de alcance e, em seguida, os instala nos celulares. A partir daí uma conexão deve ser formada entre o celular e o receptor para que o usuário possa interagir com o programa TVDI. Se for necessário um canal de retorno para os dados do celular, este deve enviar as informações para um servidor web. A apresentação dos programas interativos terá um papel fundamental na difusão do conteúdo, uma vez que é ele quem mostra as informações ao telespectador. No caso de um único telespectador assistindo a um programa no recinto de um receptor, ele pode interagir diretamente através do controle remoto, uma vez que não haverá outros usuários com características distintas, não sendo necessária a apresentação de diferentes conteúdos individuais. Se mais de um usuário estiver no ambiente de um receptor, para que eles interajam simultaneamente, cada um deles deve portar de algum dispositivo de interação com tela para que ele possa ver informações personalizadas transmitidas pelo programa, que no caso pode ser um celular. Assim, cada usuário interage diretamente com seu aparelho e este se comunica com o receptor, levando os dados de cada usuário. Desta forma o celular se comportaria como uma espécie de controle remoto, todavia poderia mostrar informações através de sua tela. O receptor deve distinguir que tipo de dispositivo de interação cada usuário esta utilizando. Para um número pequeno de usuários interagindo simultaneamente (até sete usuários), nenhum gerenciamento e formação de redes scarttnet será necessário, uma vez que o receptor pode se conectar a todos simultaneamente. Caso haja um número maior de dispositivos, o receptor irá dar inicio ao gerenciamento das conexões, estabelecendo que deve criar piconets para formar uma scartternet final. Os dispositivos com mais recursos serão escolhidos como os mestres dentro de uma piconet local, conectando-se com outros dispositivos que estarão dentro do seu alcance, e que possuem maiores limitações em relação ao número de conexão. Enquanto a scartternet estiver sendo formada, os dados já estarão sendo trafegados pela rede, de forma que os dispositivos ingressados já podem ser disponibilizados para interação entre o usuário e o receptor. Quando novos dispositivos tentam se conectar na rede, um simples ingresso pode ser feito caso haja dispositivos mestres no alcance com capacidade para integra-los em suas piconets. Porém, se nenhum dispositivo mestre possuir conexões disponíveis, a estrutura da rede deve ser refeita de forma que todos os dispositivos possam estar 149

154 conectados, assim, novas piconets serão criadas dentro da grande scartternet, agregando os novos dispositivos. Por fim, o usuário estará apto a interagir com o receptor TVDI. Os endereços Bluetooth (Bluetooth Adress) de cada dispositivo são guardados para que não seja necessária a verificação dos recursos disponíveis todas as vezes que cada um deles tentar ingressar na rede. Assim, ganha-se tempo uma vez que os dispositivos já são previamente conhecidos. 5. Conclusão Uma bateria de testes será feita ao término das implementações visando a verificação da eficácia e eficiência, e em seguida, resultados e soluções serão propostos para validar a arquitetura desenvolvida como apta ao mercado consumidor ou não. Com o uso da arquitetura desenvolvida, várias novas possibilidades poderão ser criadas, ficando a critério de desenvolvedores de aplicações para TVDI. Com o modelo proposto neste trabalho, aplicações finais poderão ser desenvolvidas de forma comercial, e também alguns conceitos poderão vir a tornaremse normas, o que geraria transparência para usuários domésticos e possibilidades para criadores de software para TVDI. Referências FERREIRA, Leydson Pontes (2009). Utilizando Dispositivos Móveis e Bluetooth para Aplicação de Avaliações em Meio Digital. Relatório de conclusão de curso (Engenharia da Computação). Natal: UFRN. JEDDAH, Ahmed; ZAGUIA, Nejib; JOURDAN, Guy-Vincent. (2009) Analyzing the Device Discovery Phase of Bluetooth Scatternet Formation Algorithms. IEEE. JOHNSON, David (2004). Hardware and software implications of creating Bluetooth Scattemet devices. IEEE. ORTIZ, C. Enrique. Using the Java APIs for Bluetooth Wireless Tecnology. Disponível na internet: Acesso em: 1 de agosto de SIG. Bluetooth.com - The Official Bluetooth Tecnology Info Site. Disponível na internet: Acesso em: 1 de agosto de SOUZA FILHO, Guido Lemos et al. (2006). Ginga-J: The Procedural Middleware for the Brazilian Digital TV System. João Pessoa: UFPB. YANG, Chorng-Horng; CHEN, Yi-Sheng. (2005). BLUETOOTH SCATTERNET FORMATION FOR SUPPORTING DEVICE MOBILITY. IEEE. 150

155 Modelos de Confiança e Qualidade de Serviço na Web Joel Gonçalves de Oliveira 1, Claudia Maria Fernandes Araújo Ribeiro 1 1 Laboratório LUMEN - Universidade do Estado do Rio Grande do Norte (UERN) Departamento de Computação - Av. Ayrton Senna, Neópolis - Natal RN - Brasil Abstract. This paper has as main goal to point different forms for the qualification of service and applications in the web, as well as to make explicit the basic principles on trust models for web applications under the quality of service context. Resumo. Este artigo tem como meta principal apontar diferentes formas de se qualificar serviços e aplicações na web, bem como explicitar os princípios básicos sobre modelos de confiança para aplicações web no contexto de qualidade de serviço. 1. Introdução A necessidade de ter mais informações, com mais conteúdo e em tempo real, fez surgir a Web que conhecemos, onde uma grande quantidade de informações está disponível. Contudo, tornou-se evidente a necessidade de mecanismos mais eficientes que garantam qualidade na busca destas informações. Assim, tem-se buscado meios para estabelecer confiança e aliada a isso qualidade nos serviços ofertados. É fundamental compreender a necessidade de apresentar os indicadores de qualidade associados aos provedores de serviços e aplicações na Web, bem como explicitar as principais ideias concernentes aos modelos de confiança já estabelecidos, a fim de estabelecer uma referência básica para creditarmos ou não confiança nestas entidades prestadoras de serviço. Neste contexto, uma abordagem promissora para modelos de confiança pressupõe a adoção de arquiteturas orientadas a serviço [Kovac 2009]. Contudo, existem limitações que devem ser minimizadas ou eliminadas visando à qualidade no acesso e distribuição da informação e para isso é fundamental uma nova visão sobre como trabalhar com a confiança. É importante destacar que a qualidade da informação está envolta numa grade de condições e pré-requisitos, dentre elas as condições de usabilidade, conectividade e atualização do sistema. Os pré-requisitos técnicos para isso sem dúvida incluem: alta taxa de disponibilidade, facilidade em caminhar pelo site, padrões de interação homem-máquina que tornam possível o acesso a pessoas de outras nacionalidades, ou que tenham algum grau de deficiência, seja auditiva ou visual. Sem esquecer na objetividade dos fatos expostos ou inseridos em contextos que podem gerar dúvidas. 151

156 2. Indicadores de Qualidade Segundo [Bagheri 2009], a qualidade de um site ou serviço que esteja disponível na web pode e deve ser medida seguindo alguns princípios básicos dentre eles: credibilidade, conteúdo, apresentação do site, links, design, interatividade, anúncios (nesse caso de pouca importância para os usuários e fonte de renda para os provedores) e responsabilidade sobre o conteúdo. 2.1 Credibilidade Um item extremamente importante no quesito credibilidade é a fonte. Espera-se que ela seja especializada na área a que se dedica a publicar conteúdo. Quanto maior o domínio da área em questão, maior a tendência de se creditar confiança nela. Toda fonte insere seu conteúdo num contexto, essa é a forma de conseguir sintetizar a ideia que serviu como base para a pesquisa ou coleta de informação. Existem vários contextos: ambiental, tecnológico, científico, etc. Devemos ter em mente que assim como nós usuários, os provedores de informações buscam e estabelecem critérios para atualizar e alimentar seus bancos de informações. 2.2 Conteúdo Outro fator de extrema relevância, que influi diretamente na credibilidade de um provedor de serviço ou site, é a acurácia, ou seja, a precisão com que essa informação é abordada. Informações breves, mas claras tornam-se mais agradáveis e tendem a ser mais buscadas. O tamanho e o formato destas informações são fatores que influem no processo de carregamento de páginas. Por exemplo, uma demora superior a 15s tende a se traduzir em desapontamento por parte dos usuários, fazendo com que possíveis interessados no acesso relutem ou não queiram fazer uso desses recursos/páginas. Schweitzer (2006) convida ao seguinte teste: acesse digite a seguinte frase: Retornei ao quarto, acendi três cigarros, queria entender por que meu pai gostava tanto de cigarros? Traduza para o inglês, depois do inglês para o francês e agora traduza para o português e compare o resultado inicial com o atual, possivelmente o resultado será diferente. Frase atual: Voltei para o quarto, três cigarros acesos, I entender porque meu pai gostava tanto de cigarros?. Este exemplo explicita que é fundamental inserir um modelo de confiança que garanta a cada passo do caminho a integridade da informação, daí a necessidade de criar modelos de confiança e inseri-lo no contexto da qualidade de serviço. 2.3 Apresentação do site, Links, Design e Interatividade Durante a estruturação do site, deve-se ter em mente como fazer e com o que fazer. A meta principal deve ser construir páginas leves, com links relacionados aos assuntos lidos. Sobre esse ponto de vista: fazer parecer fácil de usar e de fazer, pode ser a diferença entre atingir um grande público de consumidores ou fracassar. Uma forma de garantir esse sucesso consiste em tentar mantê-los conectado pelo máximo de tempo possível, o que pressupões aspectos relacionados a interatividade, links de discussão e possivelmente debates online que potencializem a relação consumidor/produtor. 152

157 3. Modelos de Confiança Existem diversos modelos de confiança, dentre eles os que são baseados em uma entidade centralizadora (serviço de nomes/autenticação). Estas entidades podem propiciar a criação de pontos críticos em relação a falhas e a vulnerabilidade, porém podem impor sérias restrições ao desempenho e à escalabilidade do sistema em ambiente de larga escala. Quando se fala de modelos de confiança, deve-se ter em mente também em políticas baseadas em confiança, na reputação baseada em confiança e na migração de confiança. As subseções seguintes apresentam uma infra-estrutura, técnicas e aspectos relacionados a um modelo de confiança, segundo definido em [Santin et al. 2002]. O objetivo é explicitar elementos fundamentais em um modelo de confiança. 3.1 A Infra-estrutura Santin et al. (2002) definem uma infra-estrutura baseado em um modelo hierárquico de confiança segundo definido na nomenclatura X.500. Construídas com base na confiança das chaves privadas das Certification Authorities (CA's), essa infra-estrutura forma uma hierarquia global. Chaves privadas (cada CA's tem e controla a sua) são usadas na assinatura digital dos certificados que emite. Ainda segundo Santin et al. (2002), na infra-estrutura X.509 são possíveis construir relações de confiança através de certificação cruzada entre duas CA's. O objetivo é dispensar a necessidade de percorrer toda a estrutura hierárquica para ir de uma CA até outra. Importante observar que este fato não descaracteriza a CA como entidade centralizadora da certificação. 3.2 Relações de Confiança sem Entidades Centralizadora A Web é um ambiente de distribuição de informação e como tal nela existem formas mais flexíveis de se construir redes de confiança. Tais relacionamentos podem ser construídos em pares (peer-to-peer) ou em cadeias de confiança. No caso das cadeias de confiança cada entidade se comportaria como se fosse uma CA. A infra-estrutura Pretty Good Privacy (PGP) utiliza criptografia de chave pública e uma estrutura para gerenciamento e certificação das chaves baseada na teia de confiança [Santin et al. 2002]. Essa infra-estrutura foi desenvolvida para cifragem de autenticação de arquivos e correio eletrônico. Diferentemente do X.509 (hierarquia de confiança), os usuários PGP podem construir caminhos de confiança de forma aleatória, utilizando-se de comunidades já existentes espalhadas pelo mundo. Os certificados no PGP são emitidos por usuários comuns (outra diferença em relação ao X.509, onde os certificados são emitidos por CA's). O controle de acesso é tradicionalmente baseado na confrontação da identidade autenticada do cliente (que deseja acessar um recurso) com as ACL's (listas de controle de acesso) armazenadas na memória local do guardião (núcleo de segurança) do recurso sendo acessado. 3.3 Confiança baseada em reputação Esta estratégia pode ser vista como um grafo valorado onde, numa rede social atribui condições em que é possível medir o impacto dessas relações dentro de um contexto formalizado. O grau de impacto pode ser definido usando uma norma de interpretação de contexto. Segundo [Bagheri et al. 2009], esse grau de impacto é denotado por: D i (I i, I j ), onde D i é à distância (Euclidiana) do centro de distribuição para os dois eixos de 153

158 duas categorias. Para calcular as distâncias usa-se o algoritmo de Kruskal (busca uma árvore geradora mínima). O Cálculo da reputação do contexto 'i' é visto sob a ótica das cadeias de Markov. 3.4 Gerência de Confiança A gerência de confiança é efetivada usando uma linguagem na descrição das políticas e das credenciais e um motor-lógico (engine) define o comportamento do módulo de checagem de conformidade (compliance checker) PolicyMaker O objetivo é a autorização expressa através de asserções. Uma asserção é um par (f, s), onde s representa a autoridade origem (emissor) e f descreve a autorização concedida e o seu beneficiário. Na especificação das asserções, uma linguagem é usada como um meio correto e inequívoco de expressão e de interpretação das mesmas Keynote No Keynote uma linguagem específica para definição de asserções foi adotada para aumentar sua eficiência e para facilitar a interoperabilidade na escrita de políticas e de credenciais. Isto permitiu repassar mais atribuições para o módulo de gerência de confiança é o caso da checagem da assinatura digital SDSI / SPKI O SDSI, projetado no MIT por Ronald Rivest e Butler Lampson, é uma infra-estrutura de segurança com o objetivo principal de facilitar a construção de sistemas distribuídos seguros e escaláveis. O SPKI é o resultado dos esforços conduzidos por Carl Ellison no projeto de um modelo de autorização simples, implementável e bem definido. A combinação das duas propostas forma uma base para a autenticação e autorização em aplicações distribuídas. Nesta infra-estrutura, os espaços de nomes principais são locais e o modelo baseado em cadeias de confiança é simples e flexível. Na infra-estrutura SDSI / SPKI os certificados de autorização são construídos a partir das ACL s do guardião. Na verdade, no que se refere a certificados e ACL s, o SDSI / SPKI define um formato único de representação, facilitando as atribuições e checagens de autorização. O conteúdo do certificado pode ser o mesmo da ACL, porém, ao certificado é acrescido o campo do emissor assinando o certificado a ACL não possui este campo porque é local ao guardião do serviço. 154

159 Tabela 1.1 Certificado de autorização SPKI [Santin et al. 2002] Campos Descrição Emissor (Issuer) Nome (name) Sujeito (subject) Validade (Validity dates) Chave pública da entidade (chave emissora) que está definido o Nome em seu espaço de nomes local. Nome local está sendo atribuído ao sujeito Uma chave pública ou um nome definido em outro espaço de nomes que será redefinido ( referenciado ) no espaço de nomes local ao emissor. Especificação do período de validade do certificado em formato 'data-hora'. 4. Conclusão Este artigo dedicou-se a apresentar subsídios que indicam a importância de estabelecer modelos de confiança para creditar serviços e aplicações na Web. A título de exemplo, foi discutido um modelo de confiança, definido em [Santin et al. 2002]. Com base neste modelo de confiança apresentado e outros presentes na literatura, os quais pretendemos investigar mais profundamente em trabalhos futuros, é possível antever que existem limitações que possivelmente podem ser atendidas pela incorporação de significado aos indicadores de qualidade e demais requisitos destes tipos de modelos. Este é precisamente um dos objetivos da Web Semântica que vem ganhando espaço desde 2001, quando Berners-Lee publicou um artigo na revista Scientific American que serviu de referência para os atuais conceitos de semântica na Web. A partir de então, muito foi feito com relação ao estabelecimento de padrões e mecanismos para tratar significado. No que diz respeito à garantia da qualidade da informação, indicador fundamental em modelos de confiança para aplicações na Web, acreditamos que a tecnologia semântica propiciará grande avanço no estabelecimento de procedimentos que possibilitam a qualificação da fonte da informação. Pretendemos, portanto, como trabalho futuro, analisar de que forma a Web Semântica influenciará a proposição de modelos de confiança, que possivelmente permitirão a automatização de tarefas, tais como negociação de requisitos de qualidade de serviço e personalização de serviços. Referências Bagheri, Ebrahim. Zafarani, Reza. e Barouni-Ebrahimi, M. (2009) Can Reputation Migrate? On the Propagation of Reputation in Multi-context Communities, Berners-Lee, T. Hendler, J. e Lassila, O. (2001) The Semantic Web, em: Scientific American. Gil, Yolanda. e Artz, Donovan. Journal of Web Semantics, (2007) A Survey of Trust in Computer Science and the Semantic Web. 155

160 Kovac, Damjan. e Trcek, Denis, (2009) Qualitative Trust Modeling in SOA, em: Journal of Systems Architecture. Santin, Altair O. Fraga, Joni S. Mello, Emerson R. e Siqueira, Frank. (2004) Um Modelo de Autorização e Autenticação Baseado em Redes de Confiança para Sistemas Distribuídos de Larga Escala. Publishing Press Schweitzer, Christiane Marie. Mecanismo de consolidação de confiança distribuída para redes ad hoc. São Paulo, USP pág. 77. Tese apresentada à Escola Politécnica da Universidade de São Paulo, São Paulo, Teixeira, Mario M. Santana, Marcos J. e Santana, Regina H.C, (2006) Servidor Web com Diferenciação de Serviços: Fornecendo QoS para os Serviços da Internet. 156

161 Uma Ferramenta para Avaliação de Conhecimento em Meio Digital Utilizando Bluetooth e Dispositivos Móveis Aquiles M. F. Burlamaqui, Leydson P. Ferreira, Luiz M. G. Gonçalves Programa de Pós-graduação em Engenharia Elétrica e de Computação Universidade Federal do Rio Grande do Norte Caixa Postal Natal RN Brazil Abstract. It proposes an architecture including a protocol for a distributed application in order to provide testing of knowledge via digital media, improving correction, delivery and storage of student evaluation results, which may be used to access each student or class development. A Client Application may run on Mobile Devices (as cell-phones, Smart Phones, Palms). A Server Application may run on a Desktop or even in Digital Television computing devices (STBox). Communication occurs based on a Bluetooth Protocol. This architecture was implemented based on technologies used by developing applications of Brazilain Digital TV. Resumo. Este trabalho propõe uma arquitetura e protocolo para uma aplicação distribuída que visa permitir a realização de avaliações de conhecimento em meio digital, agilizando os processos de correção, entrega e armazenamento dos resultados dos alunos, que poderão ser utilizados para acompanhamento das turmas ou de cada estudante. A aplicação cliente pode executar em vários Dispositivos Móveis (celulares, Smart Phones, Palms e etc), já Servidor, em um Desktop ou até mesmo uma TV Digital. A comunicação entre clientes e servidor ocorre via Protocolo Bluetooth. Para a implementação foram utilizadas tecnologias empregadas no desenvolvimento de aplicações do padrão de TV Digital Brasileiro. 1. Introdução Foi proposta uma aplicação cliente-servidor que visa medir o aprendizado de um grupo de alunos via realização de avaliações de conhecimento em meio digital. A aplicação servidor pode ser instanciada para executar em um ambiente de TV Digital ou qualquer outro dispositivo CDC (Connected Device Configuration), ou ainda em um Desktop, sendo necessário apenas desenvolver a GUI (Graphicl User Interface) de acordo com a plataforma. Já o módulo cliente deve executar em Dispositivos Móveis. Para o desenvolvimento foi utilizada tecnologia Java. Utilizou-se um canal Bluetooth para prover os mecanismos de interatividade entre o cliente e o servidor. O objetivo principal do trabalho é contribuir com área de Ensino à Distância (EaD), deste modo a Emissora ou mesmo as Unidades de Ensino Remotas podem enviar a aplicação servidor via canal de retorno para a TV Digital localizada na sala de aula, onde alunos poderiam acessar a avaliação disponível neste Servidor e durante um 157

162 período de tempo específico, através seus dispositivos móveis, para: fazer o download da avaliação e respondê-la; enviar suas respostas para correção; fazer o download do gabarito e resultado da turma. Deste modo, os professores a quilômetros de distância dos alunos podem criar o arquivo de avaliação a ser enviado com a aplicação, bem como, ao final do teste, ter acesso ao desempenho individual de cada aluno e ao geral da turma, visto que a aplicação gera um arquivo com as respostas e desempenho dos alunos. O presente trabalho foi desenvolvido no âmbito do projeto MultIn - Lidando com múltiplos dispositivos de Interação em Programas Educativos para a TV Digital Interativa e está diretamente relacionado com a dissertação de mestrado O Ginga e formas de interação: conexão com múltiplos e diferentes dispositivos, desenvolvida pelo aluno Kaio Dantas, também no âmbito da UFRN. 2. Arquitetura e Estrutura Para atingir a finalidade da aplicação, foi proposta uma arquitetura distribuída, composta, basicamente, de um cliente e servidor, cuja macroestrutura pode ser vista na Figura 1. Figura 1. Macroestrutura do Sistema nas Plataformas Da figura acima podemos verificar alguns requisitos e resultados da execução da aplicação: Servidor: Deve possuir um Dongle-USB (dispositivo USB que provê TV s Digitais, Computadores e etc realizar conexões Bluetooth), uma Java Virtual Machine instalada (mínimo de recursos definidos no JME CDC Java Micro Edition Connected Device Configuration), o arquivo avaliacao.xml presente no diretório anexos logo abaixo do código-fonte, e após o término da execução da aplicação é gerado o arquivo resultado.xml também no diretório anexos. Cliente: deve permitir a execução de aplicativos Java, suportar a configuração JME CLDC (Connected Limited Device Configutarion) 1.0 ou superior, o perfil MIDP (Móbile Information Device Profile) 2.0 ou superior, bem como a API (Application Programing Interface) de Bluetooth definida pela JSR 82 (Java Specification Request 82); observa-se também a comunicação da aplicação cliente com um repositório permanente de dados do Dispositivo Móvel, de modo que os dados manipulados pelo aluno sejam salvos e, caso a bateria do Dispositivo Móvel acabe, possam ser recuperados após reinicializado o aparelho. A Figura 1 mostra ainda que o servidor foi projetado em dois módulos: API AvaliacaoDigital_Servidor e a InterfaceGrafica_Servidor. O primeiro contém a lógica do negócio da aplicação. Já o módulo InterfaceGrafica_Servidor deve implementar uma 158

163 interface (nomeada Interface_Servidor) de modo a receber mensagens de AvaliacaoDigital_Servidor, permitindo exibir em tela o status da aplicação. A InterfaceGrafica_Servidor pode ser implementada para uma plataforma CLDC (que engloba Dispositivos Móveis como celulares, Smart Phones, Palms e etc) ou CDC (que engloba TV's Digitais por exemplo), sendo exigido apenas que esta implemente a Interface_Servidor, que realiza a comunicação do core da aplicação com a GUI (Graphical User Interface). 3. O Protocolo da Aplicação Primeiramente o cliente deve tentar a conexão com o servidor, e caso este aceite, o mesmo pode fazer alguma solicitação e o Servidor responder. As solicitações possíveis de serem feitas são: Tabela 1. O Protocolo da Aplicação SOLICITAÇÃO DO CLIENTE RESPOSTAS POSSÍVEIS DO SERVIDOR 1 - Solicita Avaliação Envia o arquivo de avaliação para o cliente. 2 - Solicita Gabarito 2.1 Se gabarito já está disponível para alunos, envia o arquivo de gabarito 2.2 Se gabarito não está disponível, informa ao cliente 3 - Solicita Enviar Respostas 3.1 Se servidor está aceitando respostas, informa ao cliente. O Cliente envia respostas, o servidor verifica se o arquivo de respostas corresponde com a sua avaliação corrente: caso sim, corrigeo e envia o resultado para o cliente; caso o arquivo de respostas não corresponda com avaliação do servidor, informa ao cliente. 3.2 Se o servidor não está mais aceitando respostas, informa ao cliente. 4 - Solicita Resultado Caso aluno já tenha tido sua avaliação corrigida, informa o resultado obtido, caso não, solicita que o aluno envie arquivo de respostas. 5 - Solicita Fechar conexão 5.1 Fecha conexão com cliente. Duas considerações devem ser feitas a respeito do protocolo: 1) Caso o cliente conecte-se ao servidor e fique inativo por cerca de 1 minuto, o servidor automaticamente fecha a conexão, de modo a liberar acesso para outros clientes; 159

164 2) Durante o período de aplicação do teste, que é informado ao servidor via o arquivo avaliacao.xml, os clientes podem enviar respostas mas não podem receber o gabarito; após período de aplicação do teste, os alunos não podem mais enviar respostas, apenas solicitar o gabarito. 4. Funcionamento da Aplicação Para ligar o servidor Desktop, deve-se executar o método main da classe InterfaceGraf_Teste: caso o dispositivo Bluetooth não esteja com problemas e o arquivo avaliacao.xml, que é verificado por um verificador de sintaxe XML, criado na aplicação, esteja correto, o servidor é inicializado e fica aguardando conexões dos clientes. A peça de código abaixo ilustra a parte da estrutura DTD (Document Type Definition) do arquivo avaliacao.xml, que contém os dados do teste e é necessário para o funcionamento da aplicação: <!-- DTD do arquivo avaliação.xml --> <!Element avaliacao ( duracao, tempo_t, codigo, descricao, pergunta+ )> <!Element duracao (#PCDATA)> <!Element tempo_t (#PCDATA)> <!Element codigo (#PCDATA)> <!Element descricao (#PCDATA)> <!Element pergunta (tempo, questao, resposta+, gabarito, peso)> <!Element tempo (#PCDATA)> <!Element questao (#PCDATA)> <!Element resposta (#PCDATA)> <!Element gabarito (#PCDATA)> <!Element peso (#PCDATA)> Os nomes indicam a finalidade do campo. Os indicadores (tags) tempo e tempo_t são usados para o caso de exibição dos dados da avaliação e das perguntas na tela do servidor, indicando o tempo que ficarão em exibição. A tag duracao, indica a duração da avaliação em minutos. Durante este tempo os alunos poderão acessar o servidor e realizar o download do avaliação, bem como enviar suas respostas (apenas uma vez); transcorrido esse tempo o aluno só poderá solicitar o gabarito. Transcorrida a duração da avaliação, a aplicação servidor gera um arquivo chamado resultado.xml, salvo no mesmo diretório que avaliacao.xml. Vejam a estrutura DTD para este arquivo: <!-- DTD do arquivo resultado.xml --> <!Element resultadoavaliacao (cod_teste, descricao, dt, hr_inicio, hr_term, i_totalconectados, i_totalparticipantes, media_acertos, media_turma, n_alunos*)> <!Element cod_teste (#PCDATA)> <!Element descricao (#PCDATA)> <!Element dt (#PCDATA)> <!Element hr_inicio (#PCDATA)> <!Element hr_term (#PCDATA)> <!Element i_totalconectados (#PCDATA)> <!Element i_totalparticipantes (#PCDATA)> 160

165 <!Element media_acertos(#pcdata)> <!Element media_turma (#PCDATA)> <!Element n_alunos(endereco, friendlyname, mandouteste, n_acertos, respostas*,resultado )> É importante apenas diferenciar os campos i_totalparticipantes e i_totalconectados, o primeiro campo só considera participante quem enviou as respostas, o Segundo, todos os alunos que conectaram ao servidor, deste modo, para o cálculo da media, utilizamos o i_totalparticipantes. 6. Testes do Sistema Devido à indisponibilidade de emuladores ou plataformas que permitissem a criação e testes da GUI da aplicação em uma TVDI, foi desenvolvida uma interface gráfica para plataforma Desktop para os testes do Módulo Servidor, e utilizados diversos dispositivos móveis como clientes, simulando um ambiente de sala de aula. Utilizou-se como clientes alguns aparelhos que atendem os requisitos de execução da aplicação: Nokia 2630, 2760, 3600, 5200, 5310, 6111, 7100, N70, N95; Sony Ericsson K550i, K800i, W300, W705; Motorola V3. Deste modo, foram feitos os seguintes testes: Os seguintes testes foram bem sucedidos: Verificação da execução da aplicação e apresentação da interface nos dispositivos móveis; Conectar o cliente e deixá-lo inativo por mais de 60 segundos (desconexão foi realizada em todos os casos testados); Testes no RecordStore (é o repositório de dados do Dispositivo Móvel, deste modo verificou-se se os dados estavam sendo salvos); Tentar enviar para o servidor um arquivo com respostas diferente da avaliação disponível (crítica realizada corretamente pelo servidor); Testes de Conexão foram realizadas uma série de testes de conexão: o Tentar conectar até 7 dispositivos: conseguiu-se no máximo 5, após isso as conexões seguintes eram recusadas, só sendo permitida nova conexão quando alguma era fechada; o Quanto maior a distância entre o cliente e o servidor, mais erros de conexão/busca do serviço ocorriam. Foram verificados os seguintes resultados: Tabela 2. Erros de Conexão/Busca Distância entre o cliente e o servidor Quantidade Dispositivos Testados de Número médio de dispositivos que apresentavam erros de conexão/busca 1m a 3m m a 5m m a 7m 10 5 o Velocidade de conexão: testou-se as velocidades de conexão com 1 ou 5 clientes conectados e não foram observadas variações relevantes, ficando sempre em torno de 220KB/s para os aparelhos de todos os fabricantes, valor dentro da especificação do protocolo Bluetooth. 161

166 Funcionalidade Geral da Aplicação: Foram realizados testes com 10 alunos. Considerados os problemas de busca/conexão acima explicitados, todos os alunos conseguiram se conectar ao servidor e realizar seu teste, tendo sido gerado o arquivo resultado.xml conforme esperado. 7. Conclusões e Trabalhos Futuros As perspectivas de interatividade para o usuário são palpáveis com a TV Digital, e existe um nicho muito grande ainda a explorar. Este trabalho aborda uma das formas de fazer isso, permitindo que alunos da EaD realizem avaliações (simulados, exercícios e etc) através, por exemplo, de seus aparelhos de celular, conectando-se ao Servidor (uma TV Digital por exemplo) para baixar o teste, enviar suas respostas para processamento, baixar gabarito, visualizar seu resultado bem como a média dos resultados da turma (acertos e nota), contribuindo para o Ensino à Distância visto que o professor/orientador da turma pode criar sua avaliação a quilômetros de distância e enviá-la via canal de retorno do Sistema de Televisão Digital, por exemplo, para a sala de aula, e a aplicação desenvolvida provê então um mecanismo de interação da TV Digital com os alunos através das novas tecnologias disponíveis. Ao final do teste é gerado um arquivo XML contendo o desempenho detalhado de cada aluno e o geral da turma. Para dar continuidade a pesquisa, bem como aprimorar a aplicação desenvolvida neste trabalho, sugere-se os seguintes trabalhos, ainda a serem realizados: Desenvolvimento de uma interface gráfica para o módulo Servidor em TVDI, de acordo com padrão brasileiro, utilizando LWUIT (Lightweigh User Interface Toolkit); Criar um mecanismo que gere o gráfico de desempenho de um aluno com base num histórico de resultados apresentados em várias avaliações, permitindo ao professor ter um acompanhamento gráfico dos alunos; Adaptar o Servidor para enviar a aplicação cliente para os Dispositivos Móveis (sob demanda ou automaticamente, para dispositivos que estejam com Bluetooth ligado na área próxima). 8. Referências [ADEB, 2008] ADEB Associação Brasileira de Ensino à Distância Disponível em último acesso em junho de [DEITEL, 2005] - Java, Como Programar, H. M. Deitel & P. J. Deitel, 3ª Edição, Editora Prentice Hall. [HOTSPOT, 2009] Download Java Plataform Micro Edition software Development Kit 3.0. Disponível em: <http://java.sun.com/javame/downloads/sdk30ea.jsp>. Ultimo acesso em julho de [DEITEL, 2005] - Java, Como Programar, H. M. Deitel & P. J. Deitel, 3ª Edição, Editora Prentice Hall. [JSR82, 2008] JSR Java APIs for Bluetooth. v Liberado em julho/2008. Disponível em Último acesso em junho de

167 [JSR280, 2007] JSR XML API for Java ME. v1.0. Liberado em junho/2007. Disponível em Último acesso em junho de [MUCHOW, 2004] Core J2ME Tecnologia & MIDP, John W. Muchow; Tradução: João Eduardo Nóbrega Tortello, 1ª Edição, Editora Pearson Makron Books. [OLIVEIRA & LACERDA, 2008] A TV Digital no Brasil e o Desenvolvimento de Aplicações para o Middleware Ginga Antônio Carlos Albuquerque de Oliveira, João Paulo Lopes de Lacerda. Disponível em <http://www.scribd.com/doc/ /a-tv- Digital-no-Brasil-e-o-Desenvolvimento-de-Aplicacoes-Interativas-para-o-Ginga>, último acesso em abril de [SBTVD,2009] Java DTV Specification License. Disponível em: Último acesso em julho de [SOUZA, LEITE & BATISTA, 2007] Ginga-J: The Procedural Middleware for the Brazilian Digital TV System. Guido Lemos de Souza Filho, Luiz Eduardo Cunha Leite, Carlos Eduardo Coelho Freire Batista. JCBS. no. 1; Vol. 13; Mar Disponível em <http://www.sbc.org.br/bibliotecadigital/?module=public&action=publicationobject&su bject=306&publicationobjectid=67>, último acesso em junho de [SPACEONLINE, 2009] Java Trabalhando com XML no Java. Postado em 20/02/2009. Disponível em: <http://www.portaldivinopolis.com/visualizar/585/>. Último acesso em junho de

168 Ferramenta de extração de características e análise do sinal de voz patológica Náthalee C. de Almeida 1, Sandro G. da Silva 1, Heliana B. Soares 2, Ana Maria G. Guerreiro 3 1 Departamento de Engenharia Elétrica Universidade Federal do Rio Grande do Norte (UFRN) Natal RN Brazil 2 Departamento de Ciências Exatas e Naturais DCEN- Universidade Federal Rural do Semi-Árido (UFERSA) Departamento de Ciências Exatas e Naturais- DCEN 3 Departamento de Engenharia da Computação e Automação - DCA Universidade Federal do Rio Grande do Norte (UFRN) Natal RN- Brazil Abstract. The identification of pathological voices has been performed using techniques of digital signal processing, as an auxiliary tool laryngoscopic examinations. In this work we present a tool for extracting features of speech signal using techniques such as Wavelet Packet Transform (WPT) and Frequency Cepstral Coefficients Mel (MFCC), which will form a combined vector of parameters, this vector is used as input data for classification. Furthermore, with this tool you can perform a visual analysis of pathological signs in order to assist health professionals in the diagnosis of vocal disorders caused by diseases of the larynx. Resumo. A identificação de vozes patológicas tem sido realizada por meio de técnicas de processamento digital de sinais, como uma ferramenta auxiliar a exames laringoscópicos. Neste trabalho será apresentada uma ferramenta de extração de características do sinal de voz através de técnicas como Transformada Wavelet Packet (WPT) e Coeficientes Cepstrais de Frequência Mel (MFCC), que formará um vetor de parâmetros combinados, vetor este, utilizado como dado de entrada na etapa de classificação. Além disso, com essa ferramenta será possível realizar uma análise visual dos sinais de vozes patológicas a fim de auxiliar o profissional da saúde no diagnóstico de desordens vocais provocados por patologias na laringe. 1. Introdução O ser humano se integra ao meio em que vive com maior facilidade graças à condição de comunicação oral. Por ser a fala o meio de expressão e comunicação mais importante, qualquer distúrbio da voz pode ter profundas implicações na vida social e profissional de uma pessoa. 164

169 As desordens vocais são caracterizadas por mudanças significativas que comprometem a inteligibilidade e a efetividade da comunicação oral, dentre os quais podemos destacar: alterações na qualidade vocal, freqüência e intensidade da voz, desordens no funcionamento laríngeo, respiratório e/ou do trato vocal. A presença de patologias nas dobras vocais como nódulos, pólipos, cistos e paralisia dos nervos laríngeos, pode ser corrigida por meio de: terapia vocal, cirurgia e, em alguns casos, radioterapia [Martinez and Rufiner, 2000]. Porém, nem sempre as doenças vocais causam necessariamente mudanças na qualidade da voz a nível de percepção dos ouvintes. A desordem na voz é perceptível quando o sinal acústico correspondente é observado. Logo, doenças que provocam alterações vocais podem ser diagnosticadas, acompanhadas e tratadas por técnicas baseadas na análise acústica do sinal de voz. Técnicas de processamento digital de sinais têm sido utilizadas, através da análise acústica, como uma eficiente ferramenta não-invasiva para diagnosticar as alterações na produção dos sons provocadas por patologias da laringe, classificação de doenças da voz e sua pré-detecção, auxiliando, dessa forma, no desenvolvimento do processo terapêutico [Costa et al, 2007]. Nesse artigo apresentamos uma ferramenta de extração de características do sinal de voz através da Transformada Wavelet Packet e Coeficientes Cepstrais de Freqüência Mel (MFCC) como também uma análise visual dos sinais de vozes patológicas a fim de auxiliar o profissional da saúde no diagnóstico de desordens vocais provocados por patologias na laringe como, por exemplo, edemas, nódulos e cistos. 2. Técnicas de Extração de Características A extração das características tem como objetivo retirar alguns atributos mais representativos do sinal de voz que servirão como dados de entrada para o classificador inteligente. As informações relevantes selecionadas dos sinais de voz serão adicionadas a um vetor de características. Um vetor de características é uma representação numérica sucinta de um sinal ou parte dele, descrevendo seus detalhes mais representativos. Neste trabalho, a WPT e o MFCC são usados como parâmetros para formar um vetor de características combinados, o qual identificará um determinado padrão do sinal de voz. Esse vetor é de extrema importância, pois será utilizado como entrada da rede neural durante o processo de classificação. Para obtenção desses coeficientes, os sinais a serem processados foram normalizados para que houvesse uma padronização dos níveis de amplitude (devido à normalização, todas as amplitudes do sinal ficam contidas entre 0 e 1) e segmentados em trechos de 30 ms. Para cada um dos segmentos, foram calculados os coeficientes WPT e MFCC. A Transformada Wavelet é utilizada para analisar os fenômenos de natureza nãoestacionária, como é o caso da voz. Nesta transformada as bases são analisadas tanto do domínio do tempo como no domínio da freqüência e os seus algoritmos processam a informação em diferentes escalas, conseguindo obter uma imagem ou um sinal de forma geral e detalhada [Júnior and Castilho, 2005]. A Transformada Wavelet do tipo Packet utilizada neste trabalho, é uma generalização do conceito de Transformada Wavelet Discreta. Na análise Wavelet Discreta o sinal é dividido em coeficientes de aproximação e detalhes, porém somente 165

170 os coeficientes de aproximação são divididos novamente [Parraga, 2002]. Na Wavelet Packet tanto os coeficientes de aproximação quanto os de detalhes são decompostos em cada nível como mostrado na Figura 1. Com essa transformada é possível extrair características relevantes do sinal, melhorando o desempenho dos classificadores ao retirar características relativas através da decomposição do sinal de voz em diferentes bandas de freqüências. Figura 1 - Árvore binária da transformada Wavelet Packet com 3 níveis de decomposição. Alguns estudos já foram realizados na busca pela diferenciação entre sinais patológicos e não-patológicos por meio da WPT e demonstraram resultados satisfatórios como em Parraga (2002). Os MFCC baseiam-se no uso do espectro de acordo com a escala Mel, uma escala que procura se aproximar de características de sensitividade do ouvido humano [Piconi, 1993] e representam bem a falta de fechamento da glote e as vibrações irregulares, devido à presença da patologia [Costa, 2008]. Os Coeficientes Mel-Cepstrais são obtidos através do diagrama de blocos descrito abaixo: Sinal de voz janelado FFT 2 Banco de filtros Análise cepstral Logaritmo da energia DCT Parâm. melcepstrais Figura 2 Diagrama de Blocos para obtenção dos coeficientes cepstrais de frequência mel O sinal é dividido em segmentos (janelas) e pra cada janela calcula-se o quadrado do módulo da Transformada de Fourier. Filtra-se esse sinal através de um banco de filtros triangulares na escala mel, calcula-se o logaritmo da energia na saída 166

171 dos filtros e por último, calcula-se a Transformada Discreta do Cosseno. Os coeficientes MFCCs são as amplitudes resultantes. 3. Resultados A ferramenta desenvolvida SAV (Sistema para Avaliação de Voz) além de fornecer um vetor de características do sinal de voz ainda apresenta uma análise visual de algumas técnicas de processamento digital de sinais: no domínio do tempo, no domínio da freqüência com a Transformada Rápida de Fourier (FFT) e através de um espectrograma como pode ser observado na Figura 4. Figura 4 Área de trabalho da SAV De acordo com a Figura 5 pode-se observar diferenças significativas entre os sinais de voz no domínio do tempo (normal, edema e nódulo, respectivamente). Os sinais de vozes normais apresentam comportamento periódico,, o mesmo não ocorre com edemas e nódulos, além disso, é possível notar que a amplitude de uma voz normal é bem superior às demais vozes. (a) (b) (c) Figura 5- Sinais de vozes no domínio do tempo (a) normal (b) edema (c) nódulo 167

172 Através da Wavelet é possível identificar alterações em um sinal de voz normal e patológica (com nódulo) como mostrado na Figura 6. Foi realizada a decomposição até o nível 3, pelo fato do sinal de voz estar compreendido entre 80 Hz e 8,5 KHz. (a) (b) Figura 6 (a) Sinal de voz normal (b) Sinal de voz com nódulo obtidas através da decomposição wavelet 4. Conclusão Com esta pesquisa foi observado que a ferramenta desenvolvida SAV (Sistema para Avaliação de Voz) apresenta-se bastante útil para o processo de classificação de vozes patológicas, uma vez que a extração de características do sinal de voz é considerada uma etapa extremamente importante para classificação de padrões. Além disso, através da análise visual dos sinais de voz, foram observadas diferenças significativas entre vozes normais e patológicas, o que irá auxiliar o profissional da saúde na identificação das alterações na voz como também no seu tratamento,, diminuindo assim a regularidade dos exames mais invasivos (exames laringoscópicos). 5. Referências COSTA, S.C. (2008) Análise Acústica, Baseada no Modelo Linear de Produção da Fala, para discriminação de vozes patológicas. Universidade Federal de Campina Grande. Tese de Doutorado. Costa, S.C.; Correia, S.; Falcão, H.; Almeida, N.; Assis F.(2007) Uso da Entropia na Discriminação de Vozes Patológicas. In II Congresso de Inovação da Rede Norte Nordeste de Educação Tecnológica, João Pessoa, PB. Júnior, A. J. P.and Castilho, J.E.(2005) Um estudo comparativo entre a Análise de Fourier e Análise Wavelet. FAMAT em Revista - Número 05. Martinez, C.E. and Rufiner, H.L. (2000) Acoustic Analysis of speech for detection of laryngeal pathologies. In Engineering in Medicine and Biology Society. Proceeedings of the 22 nd Annual International Conference of the IEEE. Vol 3, p , Chicago, EUA. Parraga, A.(2002) Aplicação da Transformada Wavelet Packet na análise e classificação de vozes patológicas. UFRGS Porto Alegre. 168

173 Picone, J. W. (1993) Signal Modeling Techniques in Speech Recognition. Proceedings of the IEEE, vol. 81, no. 9, Prentice Hall, Upper Saddle River, New Jersey. 169

174 Middleware para RSSF com suporte a QoS: Uma Visão Geral Marianna Angélica de Araújo 1, Cláudia Maria Fernandes Araújo Ribeiro 1 ¹Laboratório LUMEN - Universidade do Estado do Rio Grande do Norte (UERN) Departamento de Computação - Av. Ayrton Senna, Neópolis - Natal RN - Brasil Abstract. The development of applications for sensor network wireless (WSN) has increased mainly due to the cheapening and miniaturization of hardware, and improvement of reliability in wireless communications. To facilitate the development of these applications and contribute to the quality of service offered by these networks, many middleware solutions are being proposed. However, traditional middleware are not directly applied to WSNs, since these networks operate in a high degree of resource constraints. The aim of this paper is to investigate solutions to existing middleware for WSN in order to provide developers with key information, such as service provisioning and QoS support. Resumo. É crescente o desenvolvimento de aplicações para rede de sensores sem fio (RSSF), possibilitado pelo barateamento e miniaturização do hardware, e aumento de confiabilidade nas comunicações sem fio. Para facilitar o desenvolvimento destas aplicações e contribuir com a qualidade de serviço oferecido por essas redes, muitas soluções de Middleware estão sendo propostas. Porém, middleware tradicionais não são diretamente aplicadas às RSSFs, visto que estas redes operam com um alto grau de restrições de recursos. O objetivo deste artigo é investigar as soluções de Middleware para RSSF existentes, de forma subsidiar os desenvolvedores de aplicações e de Middleware com informações fundamentais, tais como serviços oferecidos e suporte a QoS. 1. Introdução As Redes de Sensores sem Fio (RSSF) são agrupamentos de possivelmente milhares de dispositivos de tamanho reduzido denominados nós sensores, de baixo custo, baixa capacidade de processamento e armazenamento, e energia limitada. Sensores são alimentados por baterias não recarregáveis e devem operar sem intervenção humana. Em [Cabrini and Kofugi], são discutidas várias características importantes de RSSF, tais como a capacidade de transportar os dados através de nós que utilizam algoritmos de roteamento e a alta densidade de nós. Nestas redes, inúmeros sensores monitoram o mesmo fenômeno, ocasionando grande redundância dos dados e algumas vezes fornecendo um nível de qualidade muito maior do que o necessário. Além disso, nós sensores são sujeitos a falhas devido a baterias descarregadas ou devido a influências ambientais. Falhas de comunicação são também problemas típicos das RSSF, assim como heterogeneidade, pois RSSF pode consistir de diferentes nós em termos de sensores, potência computacional e memória. Agradecimento à PIBIC-UERN 170

175 Áreas de aplicação para RSSF incluem o monitoramento de habitat, por exemplo, para rastreamento dos rebanhos de animais, transporte e monitoramento de tráfego, sistemas militares, monitoramento das condições ambientais (temperatura, pressão, luminosidade, umidade, ruído, etc.), rastreamento de objetos e no futuro, possivelmente cooperar em coisas cotidianas, dentre outros. Embora de grande relevância, qualidade de serviço (QoS) em RSSF ainda é um campo de pesquisa pouco explorado. Contudo, vários autores citam o consumo de energia como fator principal que dificulta a provisão de garantias de QoS. Em [Kasten and Mattern 2007] os autores referem-se à cobertura ou ao número de sensores ativos, assim como precisão ou erros de medição como parâmetros para medir QoS. Mecanismos tradicionais de QoS usados em redes cabeadas não são adequados para RSSFs devido às restrições operacionais, tais como limitações de recursos e topologia dinâmica. Portando, soluções de middleware devem fornecer novos mecanismos para manter QoS por um longo período nestas redes, e possivelmente ajustar o nível de QoS necessário às aplicações. Por exemplo, um middleware para RSSF deve ser concebido baseado em trade-offs entre métricas de desempenho, tais como capacidade ou transferência da rede, atraso na entrega de dados e consumo de energia [Hadim and Mohamed 2006]. 2. Fundamentos de Middleware Middleware corresponde a uma camada de software intermediária entre o sistema operacional e as aplicações, sendo utilizado para mover informações entre programas, ocultando do programador diferenças de protocolo de comunicação, plataformas e dependência do sistema operacional. De forma geral, o objetivo do middleware é facilitar o desenvolvimento de aplicações. O middleware mascara a heterogeneidade das arquiteturas de computadores, sistemas operacionais, linguagem de programação e tecnologias de rede para facilitar o desenvolvimento e a gerência de aplicações. Segundo [Maciel and Assis 2004], alguns tipos de middleware são: Middleware Reflexivo: A aplicabilidade de um middleware reflexivo se concentra em aplicações de computação onipresente em tempo real, visto que a própria natureza deste tipo de aplicação difere em relação à das já existentes. A flexibilidade de um middleware introduzida por um middleware reflexivo é capaz de suprir as necessidades da computação onipresente, característica essa não existente em plataformas de middleware convencionais, por serem grandes e inflexíveis. Middleware Adaptativo: o objetivo desta categoria de middleware é ser dinamicamente personalizável, o que possibilita às aplicações móveis a flexibilidade necessária. O middleware adaptativo deve ser reconfigurável, permitindo que novos serviços sejam acoplados. Distributed Object Computing Middleware (DOC): este tipo de middleware se destina a aplicações distribuídas. Alguns exemplos de middleware pertencentes à DOC middlewares são: a máquina virtual Java da Sun (JVM), a plataforma.net da Microsoft para Web Services, CORBA da OMG, Java RMI, DCOM da Microsoft, SOAP e J2EE da Sun (também J2ME e J2SE). Agradecimento à PIBIC-UERN 171

176 A integração entre sistemas heterogêneos e a intermediação entre as aplicações e o sistema operacional também é um dos objetivos específicos das soluções de middleware. Para que estes objetivos sejam alcançados, um middleware deve fornecer serviços que atendam ao domínio de aplicações para o qual foi construído, sendo importante que este serviço tenha sua base em protocolos padrões Middleware para RSSF A principal proposta de middleware para redes de sensores é prover suporte ao desenvolvimento, manutenção, implantação, e execução de aplicações baseadas em sensores. Isto inclui mecanismos para formulação de complexas tarefas de sensoriamento, comunicação destas tarefas, coordenação de nós sensores para divisão de tarefas e distribuição para os nós sensores individuais, fusão de dados de leituras dos nós sensores individuais, dentre outros. Além disso, abstrações apropriadas e mecanismos para lidar com a heterogeneidade de nós sensores devem ser fornecidos. Todos os mecanismos fornecidos por um sistema de middleware devem respeitar os princípios especiais de RSSF, que na maior parte resume-se a eficiência energética, a robustez, e escalabilidade [Römer et al. 2007]. O âmbito de middleware para RSSF não é restrito somente para redes de sensores, mas também cobre dispositivos e redes conectadas a RSSF. O middleware é aplicado na seleção de nós ativos na rede. Também permite que informações adquiridas no canal de sensoriamento sejam repassadas para a pilha de protocolos a fim de serem transmitidas a outro nó. Outra função desta camada é de permitir uma interface padrão para a camada de aplicação. Em [Delicato et al. 2006] é explicitado que um middleware deve atuar como intermediário, traduzindo requisitos das aplicações em parâmetros de configuração de RSSF, ao mesmo tempo em que deve fornecer mecanismos que permitam à aplicação monitorar o contexto de execução atual através de uma interface de alto nível. A partir do monitoramento, o middleware deve ser capaz de adaptar dinamicamente algum comportamento da rede, se necessário. Portanto, sistemas de middleware para RSSF devem fornecer ciência de contexto. Princípios de middleware reflexivo podem ser adotados no projeto da RSSF para atender as necessidades de suas aplicações e para lidar com o dinamismo do seu ambiente Características Características de middleware para RSSF segundo [Aguilar and Kofugi]: Deve atender aos requisitos específicos das RSSF e oferecer funcionalidades que facilitem a integração de aplicações com a rede e o trabalho dos desenvolvedores de aplicações. Exemplos dessas funcionalidades são: o fornecimento de uma interface de alto nível para acessar a rede e obter seus dados, e a tradução dos requisitos recebidos das aplicações para operações de baixo nível, tais como: a seleção do protocolo a ser usada, a configuração da topologia lógica da rede e o escalonamento dos nós sensores na realização da tarefa recebida. Dadas às características dinâmicas em que operam as RSSFs e a importância da participação da aplicação no processo de comunicação na rede, o middleware Agradecimento à PIBIC-UERN 172

177 deve prover mecanismos que permitam à aplicação configurar, inspecionar e adaptar dinamicamente o comportamento da rede. As RSSF possuem requisitos e restrições com relação à carga computacional, uma vez que os dispositivos sensores possuem capacidades de armazenamento e processamento extremamente restritos. Portanto, um middleware para RSSF deve ser ainda mais leve do que para redes móveis ad-hoc. Além disso, deve possuir mecanismos para otimizar de forma efetiva o uso dos recursos de energia disponíveis. Apesar de geralmente serem fixos, os sensores estão sujeitos às dinâmicas do meio ambiente, podendo ser destruídos ou deslocados de modo imprevisível. Também alterada pelos protocolos de controle de topologia, que decidem quando e quais nós desligar para economizar energia. Tais características mostram o alto grau de dinamismo na disponibilidade dos nós e do contexto de execução das RSSFs. Em geral, nós sensores não possuem um endereço único global, mas são endereçados por atributos que descrevem suas características. Portanto, todas as soluções de middleware usadas nas redes de sensores devem ser escaláveis e adotar mecanismos de endereçamento centrados em dados. 3. Classificação A seguir, são descritos alguns exemplos de middleware para redes de sensores, presentes na literatura. Impala middleware que fornece mecanismos para atualizações de rede eficientes o suficiente para suportar aplicações dinâmicas. Seu comportamento autônomo aumenta a sua tolerância a falhas e auto-organização da rede. Contudo, a natureza de sua instrução de código não permite heterogeneidade de hardware, o que torna impróprio para dispositivos com recursos limitados [Hadim and Mohamed 2006]. Este middleware não apresenta suporte a QoS. DSWare middleware que possui como característica fundamental o gerenciamento de forma transparente de falhas de sensores, desde que uma quantidade suficiente de sensores permaneça na área em questão, a fim de fornecer uma medida válida [Aguilar and Kofugi].Em vez de o serviço ser fornecido por um único sensor, ele pode ser fornecido por um grupo de sensores geograficamente próximos. Milan middleware que permite que aplicações de redes de sensores especifiquem suas necessidades de qualidade e ajuste as características da rede para aumentar a vida útil do aplicativo ao mesmo tempo satisfazer essas necessidades, definidas através de uma interface. Para conseguir isso Milan recebe os requisitos individuais de QoS das aplicações ao longo do tempo e uma forma de atender esses requisitos de QoS usando combinações diferentes de sensor; informações sobre a importância relativa para o sistema e os usuários; além de informações sobre sensores e recursos disponíveis da rede, tais como energia e largura de banda do canal. Milan pode ainda determinar a combinação adequada de sensores que satisfaçam os requisitos das aplicações de QoS [Hadim and Kofugi 2006]. Agradecimento à PIBIC-UERN 173

178 Cougar middleware que utiliza uma abordagem que leva em consideração as limitações do enlace físico durante a agregação de informações, a fim de minimizar o consumo de energia e coleta de dados. As capacidades de processamento dos sensores são aproveitadas para executar parte do processamento de consultas dentro da rede, em vez de centralizar tal processamento em apenas nós sorvedouros [Aguilar and Kofugi]. Sina - middleware que abstrai os nós de uma RSSF como uma coleção de objetos distribuídos. Os usuários acessam informações dentro de uma RSSF utilizando consultas declarativas, ou solicitam tarefas usando scripts a fim de facilitar a formação de cluster hierarquizado para agregação de dados [Aguilar and Kofugi]. TinyLime - de acordo com [Molla and Ahamed 2006], este middleware é implementado em cima do TinyOS, suportando a agregação de dados para encontrar mais informações a partir de dados coletados. Contudo, não possui nenhuma construção que forneça suporte a segurança. Seu modelo de programação não oferece um bom suporte para adaptabilidade ou escalabilidade. Mate middleware que se apresenta como uma máquina virtual capaz de interpretar códigos byte para a plataforma TinyOS, viabilizando a reprogramação dos nós com economia de energia e aumentando a proteção para o hardware. Mate capacita-se à execução de instruções concorrentes mapeando essas instruções em tarefas gerenciadas pela unidade subjacente, que é o sistema operacional TinyOS [Aguilar and Kofugi]. Existem muitas outras soluções de middleware para RSSFdescritas na literatura, tais como o EnviroTrack [T. Abdelzaher 2004], Mires [Hadim and Mohamed 2006], Magnet [Hadim and Mohamed 2006], Smart Messages [P. Kang 2004]. Contudo, nenhum deles tem bom suporte de segurança e QoS. A seguir é apresentada uma tabela de comparação de middleware que destaca o suporte a QoS. Tabela 1. Comparação de middleware adaptada de [Hadim and Mohamed 2006] Nome do projeto Heterogeneidade Escalabilidade Mobilidade Fácil de usar Suporte a QoS Mate Sim Sim Sim Não Não Magnet Sim Sim Sim Não Não Cougar Não Não Não Sim Não SINA Não Alguns Não Sim Não DSWare Não Alguns Não Sim Não Impala Não Sim Sim Alguns Não Milan Não Alguns Não Sim Não 4. Conclusão Este artigo trouxe uma discussão sobre abordagens diversas adotadas em projetos de middleware para RSSF, um assunto relevante, que vem pouco a pouco se tornando de conhecimento público, uma vez que o sensoriamento tornar-se-á parte de nossas vidas. Neste contexto, o middleware enquanto mecanismo para facilitar o desenvolvimento de aplicações deve contribuir efetivamente para a qualidade de serviço nessas redes. Porém, os desenvolvedores de aplicações para RSSF ainda não possuem suporte Agradecimento à PIBIC-UERN 174

179 adequado a QoS, através de serviços de middleware, fato explicitado a partir da análise de sete solução de middleware apresentados neste trabalho. Pretendemos como trabalhos futuros ampliar as pesquisas a fim de responder a esses desafios agora aberto a discussão. Uma questão primordial relacionado a QoS, foco deste trabalho, é identificar e propor mecanismos que permitam à aplicação definir requisitos de QoS que possam ser efetivamente gerenciados por serviços de middleware mais robustos e de maior confiabilidade. 5. Referências Aguilar, Jenny P and Kofugi, Sergio T. Middleware para Redes de Sensores Sem Fio. Em: Universidade de São Paulo (USP). Cidade Universitária, São Paulo Brasil. Cabrini, Fábio Henrique and Kofuji, Sergio Takeo. Introdução as Redes de Sensores Sem Fio, Universidade de São Paulo. Dazhi Chen and Pramod K. Varshney. (2004). QoS Support in Wireless Sensor networks: A survey, Department of EECS, Syracuse University, Syracuse, NY, U.S. Delicato, Flávia. Pirmez, Luci and Rezende, José Ferreira. (2006) Middleware Baseado em serviços para Redes de Sensores sem Fio. Em: Anais do XXVI Congresso da SBC, CTD. XIX Concurso de Teses e Dissertações. Hadim, Salem and Mohamed, Nader. Middleware for Wireless Sensor Networks: A Survey. IEEE New Delhi, India, January Hadim, Salem and Mohamed, Nader. Middleware: Middleware Challenges and Approaches for Wireless Sensor Networks. IEEE Distributed Systems Online , Vol. 7, No. 3; March Maciel, Rita S. P. and Assis, Semírames R. (2004) Middleware Uma solução para o desenvolvimento de aplicações distribuídas, CienteFico. Ano IV, v. I. Molla, Mohammad M. and Ahamed, Sheikh Iqbal. (2006). A Survey of Middleware for Sensor Network and Challenges. IEEE Computer Society. P. Kang, C. Borcea, Gang Xu, et al. Smart Messages: A Distributed Computing Platform for Networks of Embedded Systems, Special Issues on Mobile and Pervasive Computing, The Computer Journal, URL: September. Römer, Kay. Kasten, Over. Mattern, Friedemann. Middleware Challegens for Wireless Sensor Networks. ACM. October, T. Abdelzaher, B. Blum, D. Evans, et al. EnviroTrack: Towards an Environmental Computing Paradigm for Distributed Sensor Networks, IEEE ICDCS, March URL: Agradecimento à PIBIC-UERN 175

180 Componentes da Web Semântica - Uma análise na perspectiva do desenvolvedor Cleber Rodrigues de Freitas 1, Claudia Maria Fernandes Araújo Ribeiro 1 1 Laboratório LUMEN - Departamento de Ciência da Computação Universidade de Estado do Rio Grande do Norte (UERN) Av. Airton Senna, Neópolis Natal RN Brasil Abstract. This paper is intended to provide a theoretical knowledge base about the semantic web application development methodology doing an analysis, in a developer perspective, of major semantic web s components, showing as well existing tools for its development. Resumo. No intuito de fornecer uma base teórica sobre a metodologia de desenvolvimento de aplicações para Web Semântica, este trabalho faz uma análise, com uma perspectiva centrada no desenvolvedor, dos principais componentes da Web Semântica mostrando também as ferramentas existentes para o seu desenvolvimento. 1. Introdução A Web Semântica não é uma Web separada, mas uma extensão da Web atual na qual são dados significados às informações possibilitando que computadores e pessoas trabalhem em cooperação de uma forma melhor. Assim foi definida a Web Semântica pelo seu idealizador, Tim Berners-Lee, no artigo The semantic web publicado em Uma das grandes expectativas a cerca dessa tecnologia, é a possibilidade da criação de um ambiente onde tarefas complexas seriam automatizadas através do uso de agentes de software. Esses agentes seriam capazes de coletar informações de diferentes fontes na Web, processá-las e trocar os resultados com outros agentes [Berners-Lee et al. 2001]. Desde a publicação desse artigo até os dias de hoje muito já se foi feito. Foram desenvolvidas ferramentas para criação de aplicações, criados protocolos de comunicação e, definida a arquitetura para suportar essa nova tecnologia [Burstein et al. 2005]. Publicações de artigos, livros e projetos de pesquisa sobre o assunto crescem a cada dia, tornando a comunidade cada vez mais ativa. Entretanto, a consolidação plena da Web Semântica ainda não é real. Isso ocorre devido ao fato do assunto em questão ainda ser algo obscuro aos desenvolvedores. A maioria dos desenvolvedores de aplicações Web não possui conhecimento sobre o que realmente é a Web Semântica, como ela é estruturada, quais os seus componentes, as suas ferramentas e sua aplicabilidade no mundo real. Tais conhecimentos devem ser mais largamente difundidos de uma maneira menos filosófica e mais prática e acessível aos desenvolvedores. A partir do momento em que questões como essas se tornem algo comum e disseminado entre os desenvolvedores, a consolidação da Web Semântica estará mais próxima de alcançar a plenitude na forma em que fora idealizada. 176

181 2. Componentes da Web Semântica Para se dar início a uma abordagem centrada no desenvolvedor, é necessário que este compreenda, de forma teórica, os conceitos e funcionamento dos principais componentes dessa tecnologia. É importante ter em mente que, na Web Semântica, a lógica está centrada nos dados, e não na aplicação. Nesta sessão será feita uma descrição dos componentes centrais da Web Semântica Declaração Entender como o conceito de declaração está inserido nesse contexto é uma tarefa primordial. O mapeamento de informações na Web Semântica é feito através de declarações a respeito da fonte em estudo. Toda fonte de estudo inserida nesse contexto, é chamada, de forma genérica, de recurso. Uma declaração afirma um determinado fato a respeito de um determinado recurso. Por exemplo, a frase: 'João possui carro' afirma que o recurso João é proprietário de um automóvel. Na Web Semântica, as declarações assumem o papel de componente principal. É através do uso desse componente que se torna possível a representação de afirmações a respeito de um recurso, uma vez que são elas que definem a estruturação de informações e especificam instâncias e limites em sua estrutura. Cada declaração consiste de múltiplos elementos que, tipicamente, formam uma tripla. Uma tripla é formada pela associação de um elemento específico, uma propriedade referente a esse elemento e o valor dessa propriedade [Hebeler et al. 2009]. Esses três itens são denominados, respectivamente, sujeito, predicado e objeto, e formam os componentes estruturais de uma declaração. Uma declaração é representada graficamente na forma de grafo. Figura 1. Representação gráfica de uma declaração URI (Uniform Resource Identifier) O URI garante que cada componente de uma declaração possua um identificador único. Desse modo, cada sujeito, predicado e, objeto de uma declaração possui uma identificação própria na internet. Isso elimina gerência de conflitos e certifica se determinados itens são os mesmos ou não [Hebeler et al. 2009] Linguagem A realização da representação formal de uma declaração é feita de acordo com uma linguagem da Web Semântica. Ou seja, a linguagem é uma maneira de mapear ideias, através de declarações, em uma forma que possa ser comunicada com outros. Uma linguagem da Web Semântica consiste de um grupo de palavras-chave que fornecem instruções para várias ferramentas da Web Semântica [Hebeler et al. 2009]. 177

182 2.4. Ontologia Uma ontologia contém a modelagem de um domínio de conhecimento. Consiste de uma taxonomia e um grupo de regras de inferência [Berners-Lee et al. 2001]. A taxonomia é responsável pela definição de classes de objetos e relacionamentos entre eles, já as regras de inferência expressam regras para manipulação da informação [Prud'hommeaux et al. 2008]. Em outras palavras, ela é constituída de declarações que definem conceitos, relacionamentos e restrições entre termos, sendo responsável, na arquitetura da Web Semântica, pela representação do conhecimento. Ontologias são compostas de três blocos de construção semântica fundamentais: classes, individuals, and properties. Uma classe é um tipo especial de recurso que representa um grupo de recursos que compartilham características ou são semelhantes de alguma forma. Um individual é um recurso que é um membro de uma classe. Properties são usados para descrever individuals Dados de instância Dados de instância são declarações contendo informações sobre uma instância específica ao invés de um conceito genérico. Funciona de forma análoga a objetos em um programa orientado a objetos. Uma ontologia contendo o conceito de Pessoa pode gerar milhares de instâncias a partir desse mesmo conceito, assim como uma determinada classe, no paradigma orientado a objeto, pode gerar milhares de objetos fazendo uso da mesma [Hebeler et al. 2009]. 3. Ferramentas de desenvolvimento Para tornar possível a implementação desses componentes em aplicações do mundo real, é necessário o uso de ferramentas de desenvolvimento da Web Semântica. Nesta sessão é dado o início a uma abordagem que facilita a compreensão do funcionamento dos componentes descritos anteriormente. Três principais categorias formam o grupo das ferramentas de desenvolvimento: ferramentas de construção, ferramentas de consulta e motores de raciocínio [Hebeler et al. 2009] Ferramentas de construção Editores de ontologias são as ferramentas mais óbvias existentes nesse contexto, assumindo um papel importante na criação de ontologias. As ferramentas mais usadas atualmente, Protégé, SWOOP e OntoEdit, permitem aos desenvolvedores a construção, customização e integração de ontologias. Outra ferramenta, de extrema importância é o RDF (Resource Description Framework) que é um formato de dados de grafos direcionado, para representação de informação na Web [Prud'hommeaux et al. 2008]. O RDF é usado para fazer a descrição de modelos fazendo uso de declarações. Outras ferramentas que desempenham papeis primordiais na Web Semântica são o OWL [W3C 2007], linguagem de construção de ontologias que permite a adição de declaração semânticas que vão além das existentes no RDF, e SWRL [Horrocks et al. 2004], linguagem esta que possibilita a criação de restrições fazendo o uso de adição de regras às declarações existentes em uma base de conhecimento, incluindo métodos de programação como contador e declarações do tipo if, else, than. 178

183 3.2. Ferramentas de consulta Não diferente de uma aplicação tradicional, aplicações semânticas devem ser capazes de realizar buscas de extração de informações existentes em uma base de conhecimento. Ferramentas de consulta navegam a Web Semântica e retornam a resposta de uma requisição. Existem vários métodos para consulta que variam de uma simples busca através da navegação de um grafo, a complexas linguagens de consultas [Hebeler et al. 2009]. Dentre elas se destacam SPARQL [Prud'hommeaux et al. 2008] e RDQL [Seaborne 2004], que possuem sintaxe e funcionamento semelhante ao SQL. Enquanto que o SQL faz uma consulta em uma tabela podendo possuir como refinamento desta, dados a serem comparados com os valores de uma determinada coluna, linguagens de consulta semântica realizam essa tarefa analisando as declarações existentes na ontologia podendo receber dados a serem comparados com os valores de um determinado predicado como refinamento. SPARQL e RDQL são recomendações da W3C Motores de raciocínio Motores de raciocínio, comumente chamados de raciocinadores, fornecem metodologias para o raciocínio de informação em uma base de conhecimento e deduzem novos conhecimentos a partir dos previamente estabelecidos [Alesso et al 2009]. Isso torna o uso dessas ferramentas bastante útil e interessante. Para uma melhor compreensão dois exemplos práticos serão descritos. Primeiro: em uma ontologia, ao se declarar que João é filho de Maria e, que Moisés também é filho de Maria, em nenhum momento foi dito que eles se relacionam de alguma forma. Com o uso de um raciocinador a conclusão de que existe um relacionamento entre eles seria feita de forma automática. Segundo: considere uma ontologia que descreva relações entre processadores e que uma busca sobre 64 bits é realizada. Não existe um processador com esse nome, porém existe na ontologia uma relação entre o conceito de 64 bits e a classe que define um grupo de processadores. Logo os dados das instâncias pertencentes a esta classe serão o resultado dessa busca. Jena, Racer e Pallet são atualmente as ferramentas de raciocínio mais usadas no desenvolvimento de aplicações semânticas. 4. Conclusão A comunidade da Web Semântica torna-se mais ativa a cada dia que passa e o desenvolvimento de aplicações que venham a atingir e beneficiar o mercado cresce em ritmo acelerado. A necessidade de se ter profissionais que estejam aptos a desenvolver aplicações inseridas nesse contexto assume um grau de importância alto. O estudo apresentado nesse artigo fornece fundamentos e informações essenciais sobre o funcionamento dos principais componentes dessa tecnologia. Também são mostradas as principais ferramentas de desenvolvimento existentes, bem como alguns exemplos de como é possível fazer o uso prático dessas ferramentas em uma aplicação, fornecendo assim uma perspectiva centrada no desenvolvedor. Desenvolvedores que estejam interessados em compreender o que compõe a Web Semântica e como é possível a implementação de aplicações na área podem ter esse artigo como referência inicial. Referências Alesso, H. P. and Smith, Craig F. (2009) Thinking on the web, USA, A John Wiley & Songs, Inc, p

184 Berners-Lee, T et al. (2001) The Semantic Web, em: Scientific American. Burstein, M.; Bussler, C.; Finin, T.; Huhns, M.N.; Paolucci, M.; Sheth, A.P.; Williams, S. e Zaremba, M. (2005) A Semantic Web services architecture, em: IEEE. Hebeler, John. et al. (2009) Semantic Web Programming, USA, A John Wiley & Songs, Inc, p 4-13, Horrocks, I et al. (2004) SWRL: A Semantic Web Rule Language Combining OWL and RuleML, Outubro. Prud'hommeaux, H et al. (2008) SPARQL Query Language for RDF, Outubro. Seaborne, A. (2004) A Query Language for RDF, Outubro. W3C. (2007) Web Ontology Language, Outubro. 180

185 Implementação de Controladores utilizando Microcontroladores Raimundo Valter C. Filho 1, Camila Mara V. Barros 1, Jaidilson J. Silva 1, Luciano S. Barros 1 1 Universidade Federal Rural do Semi-Árido (UFERSA) BR 110, km 47 CEP Mossoró RN Brasil Abstract. Currently, some kinds of control systems, although be simple, have much electronic components which are responsible for arithmetic and logical operations. These components set the microcontrollers, which are used for several control actions and their performance bases itself on processed signal for discrete systems or digitalized signal for continuous systems. In this work, are implemented the ON-OFF, P, PI, and PID controllers and their performance are evaluated at the rotational speed control of a mini wind turbine (cooler). Resumo. Atualmente, muitos dos sistemas de controle, ainda que simplórios, têm sua ação propiciada por uma quantidade muito grande de componentes eletrônicos, que juntos constituem os circuitos responsáveis por operações aritméticas e lógicas. Estes circuitos em conjunto, denominados microcontroladores, são utilizados para uma infinidade de ações de controle e o seu desempenho se baseia na premissa de que os sinais processados devem ser digitais, se o sistema ou processo controlado for discreto; ou digitalizados, se o sistema ou processo controlado for contínuo. Neste trabalho, é investigado o desempenho do controlador PID e de suas variações, P e PI, além do controlador ON-OFF, no controle de velocidade de uma mini turbina eólica (ventilador). 1. Introdução A teoria de controle analógico consiste na utilização de técnicas de análise e projeto de sistemas que podem ser representados por modelos matemáticos contínuos no tempo [Ogata 2003]. Para compor um sistema de controle analógico, apenas componentes analógicos como resistores, capacitores, amplificadores operacionais, etc., devem ser usados. Além disto, os componentes utilizados como atuadores devem também ser analógicos, como dispositivos mecânicos, pneumáticos, elétricos, etc. Para viabilizar, logística e comercialmente, a utilização dos sistemas de controle projetados, nas últimas décadas grandes esforços foram empreendidos a fim de construir estruturas que contenham uma grande quantidade de circuitos, com várias funcionalidades em um só componente. Estas estruturas denominam-se microcontroladores. Os microcontroladores são utilizados para uma infinidade de ações de controle e o seu desempenho se baseia na premissa de que os sinais processados 181

186 devem ser digitais, se o sistema ou processo controlado for discreto; ou digitalizados, se o sistema ou processo controlado for contínuo. Consequentemente, ainda que para certos sistemas a análise e projeto de controle se baseie na teoria de controle analógico, o sistema de controle propriamente dito é digital. O sistema de controle baseado em teoria de controle analógico mais difundido é o de ação proporcional-integral-derivativa (PID), uma vez que seu desempenho é considerado satisfatório para a maioria de sistemas e processos controlados. Neste trabalho, é investigado o desempenho do controlador PID e de suas variações, P e PI, além do controlador ON-OFF, no controle de velocidade de uma mini turbina eólica (ventilador). Os controladores são implementados através de microcontroladores, especificamente pela plataforma de desenvolvimento Mclab2. 2. Teoria de Controle Um sistema de controle tem a função de comparar o valor real de saída da planta com a entrada de referência (valor desejado), determinando o desvio entre elas. A partir desse desvio, o sistema produz um sinal de controle que vai reduzi-lo a zero ou a um valor pequeno, como ilustrado na Figura 1. A maneira pela qual o controlador produz o sinal de controle é denominada ação de controle [Ogata 2003]. Entrada Erro Comparador Controlador Planta Saída Medidor Figura 1. Diagrama de blocos de um sistema de controle qualquer. Os controladores podem ser classificados de acordo com suas ações de controle: Controlador de duas posições ou on-off; Controlador proporcional; Controlador proporcional-integral; Controlador proporcional-integral-derivativo. 2.1 Controlador de Duas Posições ou On-Off Para os sistemas de duas posições o elemento atuante tem somente duas posições fixas, ou simplesmente on off. Este tipo de controle é relativamente simples e barato, por isso é bastante utilizado em sistemas de controle domésticos e industriais [Pinto et al 2008]. O sinal de saída do controlador é u(t) e o sinal de erro atuante é e(t). No controle de duas posições, o sinal u(t) permanece em um valor máximo ou em um valor mínimo, conforme o sinal de erro atuante for negativo ou positivo. Portanto: u(t) = U 1, para e(t) > 0 (2.1) u(t) = U 2, para e(t) < 0 (2.2) Onde U 1 e U 2 são constantes e o valor mínimo U 2 é normalmente zero ou U

187 2.2 Controlador Proporcional (P) Para um controlador com ação de controle proporcional, a relação entre a saída do controlador u(t) e o sinal de erro atuante e(t) é: u(t) = K p e(t) (2.3) Utilizando a transformada de Laplace: U( s) = E( s) K p Onde K p é denominado de ganho proporcional. 2.3 Controlador Proporcional-Integral (PI) Essa ação é definida por: (2.4) K p t u( t) = K pe( t) + e( t) dt (2.5) T 0 i ou a função de transferência do controlador é: U ( s) 1 = K p 1 + E( s) Ti s Onde T i é denominado de tempo integrativo. 2.4 Controlador Proporcional-Integral-Derivativo (PID) (2.6) A combinação das ações de controle proporcional, integral e derivativo é denominada de proporcional-integral-derivativo. A equação de um controlador com essas ações combinadas é dada por: K p t de( t) u( t) = K pe( t) + e( t) dt + K ptd T (2.7) 0 dt E a função de transferência é: U ( s) 1 K p 1+ + T E( s) Ti s = d i Onde T d é o tempo derivativo. 3. Plataforma de Testes (2.8) A aplicação do controle de velocidade foi desenvolvida utilizando a placa de desenvolvimento Mclab2 (Mosaico), apresentada na Figura 2. Este arranjo permite a utilização de várias funcionalidades do microcontrolador PIC16F877A da Microchip [Sousa 2007]. Foram utilizados, no desenvolvimento desse trabalho, os circuitos do tacômetro e acionamento do ventilador. O tacômetro consiste em um sensor de barreira montado 183

188 usando um LED infravermelho e um fototransistor. O sensor é responsável por monitorar a passagem de cada pá da hélice. O Setpoint é ajustado através de um potenciômetro que aplicará um sinal de tensão à entrada analógica do microcontrolador. Este sinal de referência é adotado, para todo o experimento, como sendo 1400 rpm. Figura 2. Fotografia da placa de desenvolvimento Mclab2. Para os controladores P, PI e PID são utilizados valores de ciclo de trabalho variáveis entre zero e 100%. Para o controlador ON-OFF o ciclo de trabalho utilizado é zero ou 100%. O firmware, programa que acompanha o microcontrolador, foi desenvolvido em linguagem C [Pereira 2007]. O compilador utilizado foi o PCW Compiler (CCS - Custom Computer Service). 4. Resultados Experimentais Foram implementados os controladores ON-OFF, P, PI e PID. Os três últimos foram sintonizados utilizando a técnica de Ziegler-Nichols. Na Tabela 1 estão listados os valores de d (tempo morto) e a constante de tempo T, que estão representados na Figura 3. Utilizando estes valores é possível obter os parâmetros T i, T d e K p, úteis na parametrização dos respectivos controladores [Sousa e Costa 2001]. Tais valores estão apresentados na Tabela 2. Figure 3. Resposta à entrada degrau. Tabela 1. Parâmetro para o método de Ziegler-Nichols Parâmetro Z-N Tempo (ms) T 840,0 d 195,0 184

189 Tabela 2. Constantes para os controladores P, PI, PID por Ziegler-Nichols Controlador K p T i T d P 4,308 0 PI 3,877 0,650 0 PID 5,169 0,390 0,098 Para análise dos resultados foram adquiridos os valores de velocidade, para um degrau na entrada, que estão ilustrados na Figura 4. Para dar suporte à análise dos controladores, as variáveis relevantes foram sintetizadas na Tabela 3. Figura 4. Resposta à entrada degrau com Setpoint em 1400 rpm para os controladores ON-OFF, P, PI e PID. Tabela 3. Resultados obtidos com a entrada degrau em 1400 rpm Controle Tempo ao Setpoint (s) Tempo de acomodação (s) Overshoot (%) Erro médio quadrático (%) ON-OFF 0,307 0,346 6,93 4,098 P 0,307 0,384 10,02 1,334 PI 2,342 3,418 0,00 0,725 PID 0,768 1,920 20,50 0,716 Os fatores analisados são: tempo ao setpoint, tempo de acomodação, overshoot e erro médio quadrático. O primeiro mede o tempo para o controlador atingir o setpoint, o segundo representa o tempo para que o controle estabilize o erro médio quadrático, o terceiro mede a diferença entre o setpoint e o valor máximo atingido pelo controlador e o quarto indica o erro médio quadrático observado após o tempo de acomodação. 185

190 Conforme análise qualitativa da Tabela 3, o controle ON-OFF chega à referência e estabiliza mais rapidamente que todos os outros controladores, porém mantêm um erro quadrático médio de 4,098%, o maior dentre os controladores testados. O controlador P possui, assim como o controlador ON-OFF, valores de tempo de alcance do setpoint e estabilização bem próximos. Em contrapartida o erro médio quadrático no estado estacionário é sensivelmente menor. Entretanto há ocorrência de um overshoot maior para esse controlador, quando comparado ao anterior. O controlador PI, diferentemente dos demais controladores, necessita de um tempo maior para atingir a referência e estabilizar. Porém demonstra a inexistência de overshoot e um erro médio quadrático menor que os controladores ON-OFF e P. O controlador PID, apesar de resultar em um overshoot considerável (20,50%), é o que possui menor erro médio quadrático em regime estacionário e consegue chegar à referência em um tempo intermediário entre os extremos ON-OFF e PI. 5. Conclusões Neste trabalho foram apresentados os resultados das implementações de controladores clássicos, como ON-OFF, P, PI e PID, utilizando um microcontrolador para controlar a velocidade de uma mini turbina eólica (ventilador). A variável monitorada é a velocidade do ventilador, enquanto que o parâmetro controlado é a tensão de alimentação do mesmo. Verificou-se que o menor erro em relação ao sinal de referência foi obtido com o controlador PID, que é mais robusto que os demais controladores implementados, mas que apresenta o maior overshoot. Para aplicações onde o overshoot deve ser considerado, o controlador PI pode ser utilizado, desde que o tempo para alcançar a referência não seja um parâmetro crucial para o projeto. Para este último caso, o controlador P seria o mais indicado. Para trabalhos futuros, pretende-se controlar a velocidade do ventilador tendo um setpoint variável, de modo a manter constante a relação entre esta velocidade e a do vento, e assim utilizar as técnicas de controle implementadas em turbinas eólicas. Referências Ogata, K. (2003), Engenharia de Controle Moderno, Prentice-Hall, 4ª Edição, São Paulo. Pinto, A. F. C., Almeida, M. P., Macêdo, W. N. e Pinho, J. T. (2008), Desenvolvimento de um controlador de carga do tipo on-off. II Congresso Brasileiro de Energia Solar e III Conferência Regional Latino-Americana da ISES, Florianópolis, Brasil. Pereira, Fábio (2007), Microcontroladores PIC: Programação em C, Érica, 7ª Edição, São Paulo. Souza, Cleonilson P. e Costa Filho, José T. (2001), Controle por Computador: Desenvolvendo Sistema de Aquisição de Dados para PC, EDUFMA, São Luís. Souza, David José de (2007), Conectando o PIC 16F877A: Recursos Avançados, Érica, 4ª Edição, São Paulo. 186

191 Protocolo de Controle de Concorrência para Banco de Dados em Tempo-Real Yáskara Y. M. P. Fernandes 1, Francisco Milton Mendes 1, Flávia Estélia Silva Coelho 1, Pedro Fernandes R. Neto 2 1 Departamento de Ciências Exatas e Naturais (DCEN) Universidade Federal Rural do Semi-Árido (UFERSA) BR 110 Km 47 Bairro Presidente Costa e Silva, Mossoró RN CEP Departamento de Informática (DI) - Universidade do Estado do Rio Grande do Norte - UERN Rua Almino Afonso, 478 Centro, Mossoró, RN, CEP: Abstract. The great technological breakthrough in the areas Sensor Networks has motivated the use of such networks a variety of applications, among which we highlight: monitoring systems, flood detection system, tracking items stocked in warehouse, among others. The main feature of these applications is the large volume of data with time constraints that must be processed. This paper introduces a protocol of concurrency control for real-time database system, called is Semantic Concurrency Control Protocol. It enables the negotiation between the logical and temporal consistency when there is conflict between them. The protocol is based on a user defined Compatibility Function (CF), for reading and writing methods of object of the application. Resumo. O grande avanço tecnológico na área de redes de sensores tem motivado o uso de tais redes em uma variedade de aplicações, entre elas podemos destacar: sistemas de monitoramento, detecção de enchentes e rastreamento de produtos estocados em um armazém. A principal característica dessas aplicações é o grande volume de dados com restrições temporais que precisa ser processado. Apresenta-se um Protocolo de Controle de Concorrência para Banco de Dados em Tempo-Real, denominado Protocolo de Controle de Concorrência Semântico. A mesma permite a negociação entre a consistência lógica e temporal quando houver conflito entre ambas, é baseada em uma Função de Compatibilidade, definida pelo usuário, para os métodos de leitura e escrita de um objeto da aplicação. 1. Introdução O avanço tecnológico das últimas décadas colocou de forma definitiva os computadores no cotidiano da vida moderna, seja nos sistemas bancários, de transporte, de saúde, de comunicação, de manufatura, entre tantos outros. Se de um lado tal inserção traz inúmeros benefícios às nossas vidas, de outro coloca novos desafios tecnológicos para a 187

192 construção de sistemas computacionais cada vez mais confiáveis e seguros, sem os quais prejuízos e desastres tornar-se-ão inevitáveis. Os Sistemas em Tempo-Real (STR) são casos especiais de sistemas computacionais em que o computador interage diretamente com o ambiente, não somente por meio de uma interface homem-máquina (vídeo e teclado), mas, sobretudo através de dispositivos que captam informações e que interferem no ambiente, denominados de sensores. Exemplos desses sistemas vão desde simples fornos de microondas até sistemas de controle automático de vôo. Esses sistemas executam as ações desejadas dentro de intervalos de tempos determinados pelo ambiente. O Banco de Dados em Tempo-Real (BD-TR) possui como principal característica o tratamento de dados e transações com restrições explícitas de tempo [Y. Xiao, H. Zhang, and F. Wang 2007]. Tal característica impõe aos protocolos de controle de concorrência desses sistemas à necessidade de considerar tanto a manutenção da consistência lógica quanto a consistência temporal dos dados e transações. Entretanto, em algumas situações a manutenção simultânea de tais restrições é impraticável. Então, existe a necessidade de se negociar entre a manutenção da consistência temporal ou consistência lógica. Se a consistência lógica for escolhida, existe a possibilidade que o item de dado torne-se temporalmente inválido, ou que uma transação viole sua restrição temporal. Se por outro lado, consistência temporal for escolhida, a consistência lógica do dado ou da transação pode ser comprometida. Portanto, é fundamental disponibilizar uma técnica de controle de concorrência para BD-TR que permita a negociação entre a consistência lógica e consistência temporal dos dados e transações. 2. Fundamentação Teórica Nos últimos anos, várias pesquisas têm sido voltadas para técnicas ou protocolos de controle de concorrência para BD-TR [LAM et al. 2002; LINDSTRÖM 2003; LINDSTRÖM 2006]. Muitos destas técnicas são baseadas em técnicas de controle de concorrência tradicionais. A maioria destas técnicas baseia-se no mecanismo de serialização como critério de corretude para determinar quais transações pode executar concorrentemente. Dos protocolos de concorrência bastante utilizados, temos: Protocolo de Bloqueio de Duas Fases Pessimista (2TPL) [NYSTRÖM et al., 2004]: As transações são bloqueadas antes de executarem suas operações ou esperam pelo bloqueio se este não puder ser adquirido; Protocolo de Controle de Concorrência Otimista (CCO) [LINDSTROM, 2002, 2003; RAATIKAINEN; LINDSTROM, 2002]: A resolução de conflitos é atrasada até a transação está próximo de comprometer; Em um BD-TR além das características citadas acima, os aspectos temporais dos dados e as restrições de tempo das transações também devem ser considerados [Y.Y.M.P. Fernandes 2008]. Portanto, um protocolo de controle de concorrência para esses sistemas deve buscar manter a consistência temporal dos dados e transações simultaneamente, ou seja, precisa dar suporte à consistência lógica e temporal dos dados e transações, e quando a manutenção simultânea de ambas não for possível, precisa 188

193 permitir a negociação entre elas, além de controlar a imprecisão resultante dessa negociação 3. Protocolo de Controle de Concorrência para BD-TR O protocolo de controle de concorrência semântica, orientada a objetos, apresentada em [Dipippo 1995], suporta a consistência lógica e temporal dos dados e transações, por permitir a especificação de técnicas de escalonamentos mais maleáveis que aquelas permitidas pela serialização. É definida uma função de compatibilidade (FC) para cada par de métodos de um objeto com o objetivo de controlar o acesso concorrente ao banco de dados. Além da FC, a técnica utilizada, baseia-se também no critério de corretude (Serialização Epsilon - ES), ele generaliza a serialização permitindo imprecisão limitada no processo de transação, assumindo usar apenas dados mensuráveis [RAATIKAINEN, K.; LINDSTROM, J. 2002] O Algoritmo da técnica de controle de concorrência semântica é bastante genérico, e o nosso trabalho propõe a definição de um algoritmo mais específico, para ser utilizados em redes de sensores. O algoritmo definido consiste em que: Para cada par de métodos é considerado as transações T1 e T2 com as operações: (rt1(x), wt2(x)), (wt1(x), rt2(x)) e (wt1(x), wt2(x)) onde r representa leitura e w representa escrita. A FC será avaliada de acordo com as situações descritas abaixo: Quando as operações pertencem a transações diferentes; Quando as operações das transações requisitam a mesma tabela, a mesma tupla e acessam o mesmo atributo. Os três casos que requerem a avaliação da FC são mostrados a seguir: Quando ocorre (rt1(x), wt2(x)), a FC será avaliada como apresentado anteriormente, e ilustrada pelo algoritmo abaixo: 1: FC verifica se as operações são da mesma transação 2: Se forem da mesma transação as operações são executadas normalmente 3: Se forem de diferentes transações 4: Verifica se as operações acessam a mesma tabela, tupla e atributo 5: se verdadeiro então 6: Execute FC (leitura, escrita) 7: Avalia parâmetros temporais e lógicos 8: Concedido em verdadeiro 9: Incrementa Imprecisão 10: Concedido em falso 11: Aborta wt2(x) 12: senão 13: A FC não é invocada 14: fim se O segundo caso possível é se a operação (wt1(x), rt2(x)) for invocada, sua execução concorrente só é possível se elas forem compatíveis. O algoritmo para este caso e mostrado a seguir. 1:FC verifica se as operações são da mesma transação 189

194 2:Se forem da mesma transação as operações são executadas normalmente 3: Se forem de diferentes transações 4:Verifica se as operações acessam a mesma tabela, tupla e atributo 5:se verdadeiro então 6: Execute FC (escrita, leitura) 7:Avalia parâmetros temporais e lógicos 8:Concedido em verdadeiro 9: Incrementa Imprecisão 10:Concedido em falso 11:Aborta rt1(x) 12: senão 12:A FC não é invocada 13:fim se O último caso é (wt1(x), wt2(x)), e definido no algoritmo abaixo: 1:FC verifica se as operações são da mesma transação 2:Se forem da mesma transação as operações são executadas normalmente 3: S forem de diferentes transações 4:Verifica se as operações acessam a mesma tabela, tupla e atributo 5:se verdadeiro então 6: Execute FC (escrita, escrita) 7:Avalia os parâmetros temporais e lógicos 8:Concedido em verdadeiro 9: Incrementa Imprecisão 10:Concedido em falso 11:Aborta wt1(x) 12: senão 13:A FC não é invocada 14:fim se 4. Estudo de caso Nos últimos anos, muitas pesquisas têm sido realizadas na área de redes de sensores. Dentre as diversas aplicações para tais redes destacam-se: rastreamento dos produtos estocados em um armazém, monitoramento residencial, detecção de enchente, e monitoramento de tráfego de veículos [R. SUGIHARA and K. Rajesh GUPTA 2008]. Para validar o protocolo implementado considera-se uma rede de sensores que é utilizada para monitorar a distância percorrida por um determinado veículo em um sistema de controle de transportes urbanos. Portanto a aplicação precisa ler dos sensores os atributos de tempo e velocidade do veículo para calcular a distância percorrida pelo mesmo. Observe que os atributos de tempo e velocidade devem ser relativamente consistentes de forma que o espaço percorrido seja calculado corretamente. Além disso, também é importante considerar uma imprecisão em relação à consistência absoluta entre o valor calculado e armazenado no banco de dados e a nova posição do veículo. No entanto esta imprecisão deve refletir aproximadamente a posição correta do mesmo. Assim é importante ressaltar que algumas aplicações precisam garantir tanto a consistência lógica quanto a consistência temporal do banco de dados. Observe que o 190

195 método implementado, através da FC permite negociar entre a consistência lógica e temporal a fim de atender ao propósito de diversos tipos de aplicações, além de considerar e controlar a imprecisão gerada no banco. Dentre as possíveis transações que devem ser executadas concorrentemente pela aplicação, temos: Transação de Atualização (Sensor)- adquire os dados de (tempo e velocidade) dos sensores e escreve no banco de dados; Transação de Consulta (Aplicação)- lêem os dados de (tempo e velocidade) do banco de dados. De acordo com a Figura 1, considerando uma situação em que o veículo ultrapassou a velocidade permitida, então o sensor é disparado e fotografa a placa do veículo que ultrapassou a velocidade permitida. O banco de dados servidor é atualizado com o dado adquirido do sensor através da transação de atualização. Nesse instante de tempo a aplicação requisita uma consulta ao banco de dados servidor para verificar as placas dos veículos que foram multados. Esta é uma situação clássica de conflito de transações, onde duas operações, uma de leitura e uma de escrita, pertencentes a transações diferentes tentam acessar o mesmo item de dado, concorrentemente no banco de dados. Essas duas operações só podem executar concorrentemente se a FC for avaliada em VERDADEIRO. Assim, através desse estudo verificou-se que o protocolo implementado foi executado com sucesso. Algumas das situações conflitantes foram consideradas e os resultados produzidos atenderam os objetivos definidos. Figure 1. Redes de Sensores 5. Conclusões O objetivo principal deste trabalho foi o desenvolvimento de um protocolo de controle de concorrência para BD-TR, denominada Técnica de Controle de Concorrência Semântico. Ela permite o gerenciamento da execução concorrente de transações com restrições temporais, pois tais transações geralmente manipulam dados com tempo de vida útil limitado, portanto precisam ser utilizados enquanto são válidos. 191

196 O protocolo foi implementado através da linguagem de programação Java e o gerenciador utilizado foi o Microsoft SQL Server. É importante destacar que apesar do SGBD utilizado ter sido Microsoft SQL Server a técnica pode ser utilizada com qualquer SGBD, desde que, a técnica de controle de concorrência do mesmo seja desativada, assim como foi feito neste trabalho.visando validar o protocolo implementado foi desenvolvida uma aplicação para redes de sensores com seu respectivo banco de dados. 6. Referências DIPIPPO, L. Semantic Real-Time Object-based Concurrency Control. Tese (Doutorado) - Department of Computer Science and Statistics, University of Rhode Island, LINDSTRÖM, J. Relaxed Correctness for Firm Real-Time Databases. IEEE International Conference on Embedded and Real-Time Computing Systems and Applications, NYSTRöM, D. et al. Pessimistic concurrency control and versioning to support database pointers in real-time databases. In: Proceedings of Euromicro conference on Real-Time Systems (ECRTS). [S.l.: s.n.], LINDSTROM, J. Integrated and adaptive optimistic concurrency control method for realtime databases. VIII International Conference on Real-Time Computing Systems and Application, University of Helsinki Finland, VIII International Conference on Real-Time Computing Systems and Application. LINDSTROM, J. Optimistic Concurrency Control Methods for Real-Time Database. Tese (Doutorado) Department of Computer Science, University of Helsinki Finland, January RAATIKAINEN, K.; LINDSTROM, J. Using real-time serializability and optimistic concurrency control in firm real-time databases. University of Helsinki Finland, LAM, K.-Y. et al. Evaluation of concurrency control strategies for mixed soft real-time database systems. Inf. Syst., Elsevier Science Ltd., v. 27, n. 2, p , ISSN Y.Y.M.P. Fernandes, P.F. Ribeiro Neto, M.L.B. Perkusich, A. Perkusich, and F. M Mendes Neto. Gerenciamento de qos para banco de dados em tempo-real em sistemas embarcados. EATISEuro American Conference on Telematics and Information Systems, Y. Xiao, H. Zhang, and F. Wang. Maintaining temporal consistency in real-time database systems. IEEE Computing Society, H. S. Son, J. Oh, H. P. Sin, and D. Kang. A real-time database testbed and performance evaluation. IEEE Computing Society, R. SUGIHARA and K. Rajesh GUPTA. Programming models for sensor networks: A survey. ACM Transactions on Sensor Networ,, 4(2):29, March

197 HN2NInt: Um Middleware para Interoperação de Sistemas Multiusuários Pervasivos Hugo T. A. Sena 1, Ricardo A. R. Dias 1, Claudio A. Schneider 1, Átila V. F. M. Oliveira 1, Marcelo Nobre 1, Rummenigge R. Dantas 1, Aquiles M.F. Burlamaqui 1 1 Departamento de Engenharia de Computação e Automação Universidade Federal do Rio Grande do Norte (UFRN) Caixa Postal Natal RN Brasil {hugotacito, ricardo.rochadias, {marcelonobre1, rudsondant, Abstract. In this paper, we will extend the concept of Interperception for integration with applications of Digital TV and mobile phones. Based on this extension we want to ensure the execution of virtual environments in Digital TV and cellphones, as well as their integration with this environment running on a personal computer (PC) or even a cellphone. This way, users who access the computer environment may interact with those who access the same environment on Digital TV. Resumo. Neste trabalho, pretendemos estender o conceito da Interpercepção para a integração com aplicações da TV Digital e celulares. Através desta extensão pretendemos garantir a execução de ambientes virtuais na TV Digital e celulares, bem como a sua integração com a versão deste ambiente executada em um computador pessoal (PC) ou mesmo um celular. Assim, usuários que acessarem a versão do ambiente pelo computador poderão interagir com aqueles que acessarem o mesmo ambiente pela TV Digital. 1. Introdução A computação ubíqua/pervasiva é caracterizada pela integração e interação entre vários dispositivos diferentes e aplicações. Isto só é possível através do uso de middlewares. Os middlewares para aplicações pervasivas têm como principais qualidades: interoperabilidade, escalabilidade, reuso, manutenção e extensão, portabilidade e adaptabilidade, robustez, agilidade e fidelidade. Interação espontânea é importante por causa da natureza volátil da computação ubíqua. O gerenciamento de contexto é fundamental para decidir as ações que serão tomadas com a detecção do contexto. Projetar aplicações neutras aos dispositivos fornece interação transparente com o usuário. Tal transparência pode ser obtida através da definição de interfaces abstratas e predição de diferentes tipos de interação, levando ao envolvimento mínimo do usuário com problemas do sistema. A invisibilidade é uma característica inerente da ubicomp, que está preocupada em manter o foco do usuário na aplicação propriamente dita e não nas ferramentas. O software deve aprender com o usuário, e permitir que ele mude suas preferências de uma maneira quase imperceptível. A interação transparente é uma das características fundamentais da Interpercepção. A interpercepção é uma arquitetura de software que integra ambientes criados com interfaces de visualização distintas. A transparência é garantida pelo middleware Portal, que converte informações entre as interfaces. A interpercepção foi 193

198 proposta pensando na diversidade de usuários encontrada na internet e de várias interfaces para interação com ambientes virtuais. Utilizando um sistema projetado com base nesta arquitetura, usuários conectados através das diferentes versões de um mesmo ambiente podem perceber e interagir uns com os outros de modo transparente. Neste trabalho apresentamos um middleware que permita um determinado aplicativo multiusuário de tempo real ser executado por diferentes clientes em dispositivos distintos, e que estes possam trocar mensagens entre si. Esta integração cria um ambiente pervasivo onde a aplicação proposta estará disponível para os usuários a todo tempo e em todo lugar. A figura 1 ilustra o ambiente desta aplicação. Figura 1 - Ambiente propício a aplicações Interpeceptivas Como a figura mostra, o ambiente prevê a integração de celulares, computadores pessoais e Set-top Box. Além disso, está prevista a interação de pessoas de diferentes faixas etárias e com diferentes necessidades. Apresentaremos na última seção um aplicativo construído sobre um ambiente virtual multiusuário. 2. Trabalhos Relacionados Computação ubíqua é um tópico de pesquisa atual e vários middlewares e aplicações pervasivas têm sido propostos. O Projeto Aura [6] tem como objetivo minimizar distrações do usuário, criando um ambiente que se adapta ao contexto e às necessidades do mesmo. Ele foi especificamente projetado para ambientes pervasivos envolvendo comunicações sem fio, computadores portáteis ou não, e para espaços inteligentes. No entanto, ao tentar atacar vários aspectos de ubicomp o projeto Aura não consegue fornecer middlewares com todas as qualidades de pervasividade. A tendência hoje é fazer middlewares e frameworks para problemas específicos, mesmo usando um modelo geral como parâmetro. AlfredO [7] é uma arquitetura de middleware que possibilita que o usuário interaja de maneira flexível com outros dispositivos eletrônicos. O middleware proposto fornece escalabilidade, flexibilidade, independência do dispositivo, segurança, eficiência e é de fácil administração. Para mostrar a validade da arquitetura foram implementadas duas aplicações: MouseController e AlfredOShop. O trabalho de Jameela et. al. [8] aplica agentes colaborativos na descoberta de recursos físicos e computacionais. Os autores infelizmente não apresentam nenhuma aplicação construída com o framework, mesmo assim a o arcabouço proposto é relevante para criação de ambientes pervasivos com grande heterogeneidade. 194

199 3. Desafios da Computação Distribuída Muitos são os desafios da computação distribuída, mas, o maior de todos é: tornar comunicáveis dispositivos distintos, provavelmente com sistemas operacionais e arquiteturas distintas e com aplicações desenvolvidas em linguagens diferentes, ou seja, permitir que estes dispositivos troquem dados um com o outro. Para que dispositivos de diferentes plataformas de hardware e software possam se comunicar: trocar dados e entender bem sua semântica, é necessário algo que reduza a complexidade inerente à computação distribuída decorrente de vários fatores: variedade de equipamentos, sistemas de hardware heterogêneos, sistemas operacionais distintos, possíveis diferenças na arquitetura de redes, etc. 4. Arquitetura do Sistema Neste trabalho propomos um middleware que permita um determinado aplicativo multiusuário de tempo real ser executado por diferentes clientes em dispositivos distintos. Esta integração cria um ambiente pervasivo onde a aplicação proposta estará disponível para os usuários a todo tempo e em todo lugar. A figura 1 ilustra o ambiente desta aplicação. Demos a este arquitetura o nome de Interpercepção entre dispositivos. Como a figura mostra, o ambiente aqui proposto prevê a integração de celulares, computadores pessoais e Set-top Box. Com isto, o sistema deverá fornecer diferentes formas de interação e visualização para os usuários. Figura 2 - Arquitetura do sistema Além disso, está previsto também a coleta dos dados resultantes do fluxo de dados tramitados pelo sistema, com o objetivo de alimentar um futuro balanceamento de cargas na rede criada. Como validação do trabalho aqui proposto será construída um ambiente virtual multiusuário. Este ambiente será executado nas diferentes plataformas contempladas pelo middleware aqui proposto e os dados de rede coletados e manipulados para exibição. Como as versões deste ambiente para computador já estão prontos, será desenvolvida a versão deste para TV Digital e Celular. 5. Implementação Utilizamos como base para a nossa implementação uma versão intermediária entre o N2N e o HN2N a qual chamamos de HN2NBeta. Para que possamos construir nosso 195

200 middleware interoperável tivemos que alterar o modo de comunicação utilizado nessa implementação. O HN2NBeta envia e recebe objetos serializáveis e com isso a única possibilidade de comunicação entre aplicações são as que são construídas utilizando a linguagem Java. Para que possamos construir aplicações com hardwares e softwares distintos, foi definido um protocolo binário de comunicação. Este protocolo é capaz de comunicar os diferentes dispositivos e linguagens. Mesmo com essa definição de protocolo, temos outros problemas relacionados com o formato de armazenamento e transmissão de dados binários. Neste caso, o formato BigEndian e LittleEndian. 5.1 Construção das mensagens As mensagens são construídas utilizando um componente de software que realiza o Marshalling e Unmarshalling das informações binárias. Com isso, não temos ambigüidade da forma de como os dados são enviados/recebidos pelas aplicações. Esse componente fica responsável por realizar as transformações necessárias para que a informação binária seja corretamente interpretada. Neste trabalho, apenas os seguinte dados binários foram utilizados: byte 8bits; short 16bits; int 32bits; string array de caracteres. As mensagens são escritas da seguinte forma: byte Não sofre nenhum tipo de transformação; short e int São transmitidos utilizando o formato BigEndian; string É transmitido primeiramente o tamanho da string no formato dito anteriormente e depois transmitido somente os caracteres que fazem parte da string. As mensagens são lidas de forma análoga a escrita. Para que uma mensagem seja enviada e recebida tanto pela aplicação quanto pelo servidor, ambos somente têm acesso a esse componente de software. Com isso, garantimos que a mensagem seja sempre transmitida no formato definido acima. 6. Resultado Para a validação deste trabalho, foram implementados: um servidor na linguagem Java, um cliente utilizando a linguagem C, um cliente utilizando a linguagem J2ME (celular) e um cliente utilizando a linguagem Java. O cliente Java é um Applet executado através de qualquer navegador da web. A aplicação para celular pode ser visto na figura 5. No experimento um servidor foi executado em um PC e os vários clientes se conectaram ao mesmo para validar a interoperação do sistema. No teste, os clientes se comunicam através de um chat. O mesmo chat, com as mesmas informações são exibidos na interface de cada cliente. Durante o teste, ao chegar uma nova mensagem, todos os clientes eram capazes de visualizar e responder. Além disso, cada usuário era capaz de visualizar a lista de usuários conectados. Figura 3 - Aplicação para celular. 196

201 7. Conclusão A computação pervasiva é uma área promissora, contudo suas qualidades ainda são difíceis de serem alcançadas. O middleware aqui proposto visa reunir algumas destas qualidades para criar um sistema pervasivo para aplicações de realidade virtual. Nossa idéia é que o middleware aqui proposto evolua para um arcabouço. Este arcabouço permitirá a criação de aplicações pervasivas multiusuário que são executadas em cada uma das plataformas para qual o middleware aqui proposto foi pensado. Referências Boulic, R. and Renault, O. (1991) 3D Hierarchies for Animation, In: New Trends in Animation and Visualization, Edited by Nadia Magnenat-Thalmann and Daniel Thalmann, John Wiley & Sons ltd., England. Dyer, S., Martin, J. and Zulauf, J. (1995) Motion Capture White Paper, December. Holton, M. and Alexander, S. (1995) Soft Cellular Modeling: A Technique for the Simulation of Non-rigid Materials, Computer Graphics: Developments in Virtual Environments, R. A. Earnshaw and J. A. Vince, England, Academic Press Ltd., p Knuth, D. E. (1984), The TeXbook, Addison Wesley, 15 th edition. Smith, A. and Jones, B. (1999). On the complexity of computing. In Advances in Computer Science, pages Publishing Press. M. Weiser, The computer for the twenty-first century, Scientific American, pp , P. A. Bernstein, Middleware: A model for distributed system services, Commun. ACM, vol. 39, no. 2, pp , S. Vinoski, An overview of middleware, in Ada-Europe, 2004, pp E. Niemel a and T. Vaskivuo, Agile middleware of pervasive computing environments, in PerCom Workshops, 2004, pp C. A. da Costa, A. C. Yamin, and C. F. R. Geyer, Toward a general software infrastructure for ubiquitous computing, IEEE Pervasive Computing, vol. 7, no. 1, pp , D. Garlan, D. P. Siewiorek, and P. Steenkiste, Project aura: Toward distraction-free pervasive computing, IEEE Pervasive Computing, vol. 1, pp , J. S. Rellermeyer, O. Riva, and G. Alonso, Alfredo: An architecture for flexible interaction with electronic devices, in Middleware, 2008, pp J. Al-Jaroodi, A. Kharhash, A. AlDhahiri, A. Shamisi, A. Dhaheri, F. AlQayedi, and S. Dhaheri, Collaborative resource discovery in pervasive computing environments, in International Symposium on Collaborative Technologies and Systems, 2008, pp MAHMOUD, Q. H. Middleware for Communications. Willey,

202 VÖLTER, Markus; Kircher, Michael; Zdun, Uwe. Remote Patterns: Foundations of Enterprise, Internet and and Realtime Distributed Object Middleware. Chichester. Wiley XXXIV, 389 p.. Wiley series in software design patterns. 198

203 TV Mímica: Uma aplicação NCLua, como uma Atrativa Ferramenta de Aprendizagem Felipe S. da Costa 2, Igor R. de Medeiros Silva 3, Pedro Henrique C. M. Cabrita 1, Haroldo Watson T. da Silva 1, Akynara Aglaé R. S. Silva 4, Diogo Henrique D. Bezerra 2, Aquiles Burlamaqui 1 1 Laboratório NatalNet Universidade Federal do Rio Grande do Norte (UFRN) DCA Campus Universitário Natal RN Brasil 2 Laboratório Lumen Universidade do Estado do Rio Grande do Norte (UERN) CaN Av. Ayrton Senna Filho, Natal RN Brasil 3 Departamento de Computação e Automação Universidade Federal do Rio Grande do Norte (UFRN) Campus Universitário Natal RN Brasil 4 PPGED - Universidade Federal do Rio Grande do Norte (UFRN) CCSA Campus Universitário Natal RN Brasil {igorosbergster, akynara, costa.felipesoares, {conde_nostaw, Abstract. This article proposes to show the new interface of the application for the Interactice Digital TV "TV Mímica" that joins the playful, big and visual power of the mimics by children's part. It objectifies to educate through the interpretation of relative mimics from images, letters and words, creating new possibilities in the use of the TV as an educational tool. Resumo. Este artigo propõe apresentar a nova interface da aplicação para TV Digital Interativa "TV Mímica", que unindo o grande poder visual e lúdico das mímicas à possibilidade de interação por parte das crianças, objetiva educar através de interpretações de mímicas relativas a imagens, letras e palavras, criando novas possibilidades no uso da TV como ferramenta educadora. 1. Introdução O espaço educacional vem sendo bombardeado por fortes mudanças decorrentes de transformações sociais e principalmente do processo de globalização e avanços tecnológicos, acarretando, assim, a modificação dos valores culturais de um país. Hoje estamos inseridos em uma sociedade onde a cultura material cede espaço para uma cultura da informação e conhecimento. Castells (1999) corrobora afirmando que vivenciamos um intervalo histórico, no qual a principal característica é a transformação da nossa cultura material pelos mecanismos do novo paradigma tecnologia da informação. Como causa dessa mudança paradigmática do social, temos uma incorporação cada vez mais acelerada e qualitativa das tecnologias em vários âmbitos da vida social, refletindo desta forma, na educação. Quando falamos em tecnologias no contexto educativo, com maior evidência o de nível público, percebemos que mesmo com a incorporação de determinadas tecnologias em sala de aula, não são atingidos resultados eficientes no processo de 199

204 ensino, pois na realidade tais ferramentas na maioria das vezes são mal empregadas. Vários são os fatores que causam essa má utilização dos recursos tecnológicos, porém enfatiza-se, sobretudo, a resistência à aceitação do "novo conhecimento" por parte de um alto número de docentes; podemos citar também a falta de preparação da categoria para o uso desses equipamentos, especialmente devido a falta de compromisso das próprias agências formadoras em incluir em seu currículos, de forma obrigatória, cursos nos quais haja estudo dos meios de comunicação e suas linguagens, incluindo aqui os de suporte tecnológico, tendo como exemplo a informática e suas possibilidades/benefícios. Outro aspecto que pode ser observado na realidade educacional brasileira, o qual contribui para o uso inepto das ferramentas didáticas de suporte tecnológico na escola, refere-se ao fato de não haver, na maior parcela das instituições públicas, uma estrutura física adequada para abrigar determinadas tecnologias. Acrescenta-se ainda a inexistência de técnicos especializados que auxiliem na manutenção dos equipamentos. Ao pensar nesse novo momento, técnico-científico-informacional, não podemos deixar de citar a televisão, que possui um longo alcance, no que se refere ao aspecto geográfico, e considerado um utensílio doméstico presente na maioria dos lares brasileiros, como sendo um instrumento que auxilia na formação e comportamento do indivíduo. E que tenderá a ocupar cada vez mais espaço na casa de cada um, já que no ano de 2007 foi inaugurada a primeira transmissão de TV Digital no Brasil. Proporcionando um ótimo momento para o campo de mídia nacional, já que possui uma ótima qualidade de som e imagem, além da portabilidade e interatividade. Dentre essas tecnologias, uma está assumindo papel de destaque por reunir toda a atratividade e poder da mídia televisiva à diversidade e flexibilidade decorrentes do uso de softwares, juntamente à comunicação interativa e/ou simultânea proporcionada pela rede mundial de computadores, a internet. É fácil notar que a popularidade da televisão, presente atualmente em aproximadamente 96% das residências brasileiras, será herdada por esse novo modelo de TV Digital. Tal popularidade poderá tornar a TV o meio mais poderoso e de maior alcance no escopo educativo, fato este não observado ainda em outros meios de comunicação como a internet, que ainda está longe de tornarse presente no cotidiano de toda a população. Na tentativa de agregar a popularidade da televisão às possibilidades advindas do novo modelo de televisão digital interativa, integrando à isto uma função educacional, é que a TV Mímica surgiu no ano de E como toda aplicação em fase inicial possuía algumas carências, principalmente no que se refere à interface gráfica, e somado-se a isso, alguns desacordos com a norma regida pela ABNT (que sofreu mudanças no decorrer de um ano).através disso, iniciou um estudo buscando melhorar a aplicação, e torná-la atraente ao telespectador-aprendiz. 2. Caso de Estudo TV Mímica O sistema de TV Digital Interativa Brasileiro foi implantado no final do ano de 2007 e em 2008 tivemos as primeiras implementações do middleware Ginga (2008), componente do sistema brasileiro responsável pela interatividade. O Ginga possui dois subsistemas responsáveis pela implementação das aplicações interativas, são eles o Ginga-NCL(2008) e o Ginga-J(2008). O Ginga-NCL utiliza uma linguagem declarativa baseada em xml chamada NCL(Nested Context Language) para a especificação de aspectos de interatividade, sincronismo espaço-temporal entre objetos de mídia, adaptabilidade e suporte a múltiplos dispositivos, já o Ginga-J utiliza a linguagem Java para a construção das aplicações. 200

205 Procurando explorar o potencial que a TV Digital nos oferece, criamos uma aplicação para TV-Digital a qual recebeu o nome de TV Mímica, uma aplicação para TV Digital Interativa voltada a educação. Esta foi desenvolvida em Ginga-NCL, por suprir todas necessidades requeridas para tal aplicação. O TV Mímica Trata-se de uma aplicação para TV digital interativa que tem como objetivos a realização de experimentos de inserção digital em escolas, reforçar conhecimentos gramaticais, fazer associações (imagem/palavra/frase) e trabalhar o raciocínio lógico, auxiliando assim, no processo de alfabetização e desenvolvimento da inteligência da criança, promovendo a interação sujeito x TV e explorando as potencialidades da tecnologia como forma de auxiliar no trabalho realizado por docentes da instituição, minimizando a questão da exclusão digital. Com base em tais circunstâncias, acreditamos que o uso da mímica em contexto educativo poderá gerar benefícios para uma aprendizagem de ordem alfabetizadora, por trazer possibilidades de expressão e comunicação, aliados a apropriação do código lingüístico (Prado, 2008). Desenvolvemos um ambiente que nos remete uma atmosfera lúdica, como uma brincadeira de criança, assim o telespectador-aprendiz poderá aprender o conteúdo sugerido de forma descontraída e divertida, por meio de adivinhações das mímicas propostas A intenção foi criar um espaço ensino capaz de auxiliar no processo de alfabetização dos alunos, ajudando na aprendizagem da leitura e escrita, proporcionando assim a fixação e o melhoramento do aprendizado do conteúdo aplicado à Educação. O programa é organizado no formato de um jogo. São exibidos vídeos de um artista realizando mímicas de objetos, animais, personagens famosos, dentre outros, bem como também são exibidas várias imagens ou lacunas a serem preenchidas com texto, dentre as quais uma está relacionada à mímica do vídeo. A criança deve associar a mímica à sua imagem ou texto para poder prosseguir no jogo. Os professores/apresentadores do programa contam histórias e no meio destas são inseridas adivinhações, através de mímicas o apresentador dá dicas para que as crianças possam desvendá-las. Um fator importante para o sucesso de tal método está na atenção que os alunos dão ao apresentador, desse modo itens que tornem a história que eles estão contando divertidas, chamando a atenção da criança, são essenciais. Alguns desses itens são: boa articulação das palavras, tom de voz do narrador e até a respiração (expirar / inspirar) que agem no imaginário da criança criando o clima da narrativa e se transformando em imagens. O jogo foi desenvolvido por nível de complexidade, a seqüência seria: decifração de imagens, concluindo este nível passamos para letras, as quais serão feitas mímicas por meio de leitura labial. Por fim, terminamos com um nível mais complexo, o qual seria a decifração de palavras, tudo através da mímica. Os níveis de complexidades mencionados anteriormente são divididos da seguinte maneira: nível 1: Mímicas e Figuras, nível 2: Mímicas e Letras e nível 3: Mímicas e Palavras. 2.1 Mímicas e Figuras Nesta primeira etapa o telespectador será convidado a adivinhar a mímica que corresponde a uma das figuras que estão dispostas na tela. Abordando temas diversos, os alunos - telespectadores aprendem brincando, alfabetizando-se pela associação de imagens, mobilizando seu potencial imagético, criativo e poder de percepção, utilizando e aprimorando seus conhecimentos prévios acerca da temática abordada, as quais convergem com o objetivo de tornar o aprendizado alfabetizador dentro de uma perspectiva de letramento, ou seja, ensinar a comunicação no contexto das práticas 201

206 sociais da leitura e da escrita. Portanto, ao adivinhar a imagem associada a figura o telespectador - aluno estará mobilizando e aprimorando diversas competências. 2.2 Mímicas e Letras Neste nível, passamos a realizar a mímica por meio da linguagem labial. O aluno/telespectador tentará adivinhar por meio da mímica, neste caso, a mímica estará relacionada a leitura labial, a letra correspondente. Nesta etapa, o aluno estará mobilizando competências e conhecimentos relacionados como a associação, fonética, memória auditiva e visual e conhecimento inicial acerca do nosso código lingüístico. Esse nível, também poderá gerar forte contribuição para a aprendizagem de alunos portadores de necessidades especiais, neste caso, contemplamos a deficiência auditiva, visto que, com a realização da atividade proposta o aluno terá a possibilidade de conhecer as letras do alfabeto mediante a pronuncia das letras. 2.3 Mímicas e Palavras Esta etapa corresponde a mímica de palavras. Tomamos uma palavra como mímica e o aluno-telespectador tentará adivinhá-la. As palavras variam de acordo com a quantidade de letras, nesse sentido, buscamos aumentar o repertório de letras, de palavras e de significados, fazendo uso da associação, mobilizando conhecimentos relacionados a fonética e ortografia, fazendo uso também dos conhecimentos prévios do alunado, proporcionando a interpretação das situações apresentadas. 3. Compreendendo as Melhorias Para uma melhor compreensão, das alterações feitas na interface da aplicação, mostraremos a seguir, imagens das duas versões. Figura 1. Interface Anterior Figura 2. Interface Atual Como podemos verificar, a atual versão do Tv Mímica nos remete a um ambiente mais colorido, passando por um gradiente de cor que nos remete as cores do arco-íris,e portanto um ambiente alegre e atraente ao telespectadro-aprendiz. 202

207 4. Implementação Ginga-NCL Como mencionado anteriormente, na implementação de um programa interativo no Sistema Brasileiro de TV Digital podemos optar por duas abordagens, utilizar o Ginga- NCL ou o Ginga-J. Optamos então por trabalhar com a linguagem NCL, que embora seja uma linguagem mais direta quando falamos em aplicações simples, a mesma se torna burocrática para programas mais complexos. Por isso, foi utilizado a linguagem de scrip lua, prevista e suportada no Ginga-NCL, para suprir as deficiências do NCL. Para os testes dessa versão foi utilizado o Ginga-NCL Virtual STB: Máquina virtual Linux para VMWare(Ginga-NCL, 2009), como emulador. 5. Conclusões e Trabalhos Futuros O novo modelo de comunicação propiciado pela TV Digital Interativa cria novas possibilidades para a educação a distância, possibilitando a comunicação em massa com elementos interativos. O presente trabalho apresentou o TV Mímica, um programa interativo voltado para a alfabetização de crianças do fundamental I, o qual associa mímicas e sons a imagens,letras e palavras, além de estimular o espírito de grupo. Como meta, buscamos agora aplicar o TV Mímica em escolas do ensino fundamental I, visando obter bons resultados no que diz respeito à assimilação do conteúdo proposto. Referências SILVA, Igor Rosberg de Medeiros; BEZERRA, Diogo Henrique Duarte; SILVA, Akynara R. S.; SOUZA, Andrey Silva; BURLAMAQUI, Aquiles Medeiros Filgueira; TV Mímica Explorando o uso da gsticulação em aplicações t-learning. Departamento de Informática UFRN,UERN, IFRN, Andrade, A. A. M.(2003). Fragmentação e Integração dos Meios. In: Marly Amarilha. (Org.). Trajetória de Sentidos. Natal: Editora da UFPB, v., p Carvalho, Alysson Massote(2005); Alves, Maria Michelle Fernandes;Gomes, Priscila de Lara Domingues; Brincar e educação: concepções e possibilidades Psicologia em Estudo Print ISSN Psicol. estud. vol.10 no.2 Maringá May/Aug. 2005;doi: /S Castells, Manuel.(1999) A sociedade em rede (A era da informação: economia, sociedade e cultura ; Volume 1, São Paulo: Editora Paz e Terra, 2a. Ed. Fischer, Rosa Maria Bueno.(2008). O dispositivo pedagógico da mídia: modos de educar na (e pela) TV In: Ultimo acesso 17/08/2008. Ginga-NCL (2008) <http://www.gingancl.org.br/> Ultimo acesso, 21/09/2009; Gomes, Fábio de Jesus Lima, Lima, José Valdeni, Nevado, Rosane Aragón (2006); The Paper as Interface in T-learning ; ICALT'06. Junqueira Filho, Gabriel de Andrade (2001). Conversando, lendo e escrevendo com as crianças na educação infantil. In: Carmem Maria Craidy; Gládis Elise Pereira da Silva Kaercher. (Org.). Educação infantil: pra que te quero?. Porto Alegre: UFRGS, v., p Lima, Cleunice Orlandi (2008); Site sobre o método Professora de Papel, Ultimo acesso, 15/03/2008; 203

208 Nores, Martín López; Arias, José Juan Pazos; Duque, Jorge García, Fernandez, Yolanda Blanco;Solla, Alberto Gil, (2006); A Core of Standards to Support T-learning, ICALT'06. Paivi, Aarreniemi-Jokipelto(2005); T-learning Model for Learning via Digital TV, EAEEIE Prado, Fernando(2008) A utilização da Mímica como recurso psicopedagógico Ultimo acesso 17/08/2008. SOARES, L. F. G. ; BARBOSA, Simone Diniz Junqueira. Programando em NCL. 1. ed. Rio de Janeiro: Elsevier - Campus, p. ABNT - ASSOCIAÇÃO BRASILEIRA DE NORMAS TÉCNICAS. NBR : Televisão digital terrestre - Codificação de dados e especificações de transmissão para radiodifusão digital Parte 5: Ginga-NCL para receptores portáteis - Linguagem de aplicação XML para codificação de aplicações. Rio de Janeiro,

209 LuaR, Uma Ferramenta para Desenvolvimento de Aplicações Customizáveis para a TVDI Ricardo R. Dias 1, Diogo Henrique D. Bezerra 2, Hugo A. Sena 1, Felipe S. Costa 2 Aquiles M. Burlamaqui 1 1 Laboratório NatalNet Universidade Federal do Rio Grande do Norte (UFRN) DCA Av. Senador Salgado Filho, Natal RN Brazil 2 Laboratório Lumen Universidade do Estado do Rio Grande do Norte (UERN) CAN Av. Airton Senna Filho, Natal RN Brazil {aquilesburlamaqui, {costa.felipesoares, ricardo.rochadias, Abstract. This paper presents a tool for developing custom applications for IDTV by relieving the efforts of the programmers and developers for coding applications based on Nested Context Language NCL and Lua. Resumo. Este artigo apresenta uma ferramenta para desenvolvimento rápido de aplicações customizáveis para TVDI, diminuindo o esforço de codificação exigido pelas aplicações baseadas na Nested Context Language NCL e Lua. 1. Introdução Embora programar seja divertido, desenvolver software de qualidade dentro de um prazo limitado e com preço viável é uma tarefa bastante árdua. Existem muito mais elementos envolvidos entre simplesmente programar e ter um produto de software que contemple ótimas idéias e requisitos. No apressado e exigente mundo do comércio eletrônico, da tecnologia da informação e dos meios de comunicação, as aplicações devem ser projetadas e desenvolvidas com menos dinheiro, maior velocidade e menos recursos que antes. O problema do desenvolvimento mais rápido, com custo mais baixo também existe no ambiente da TV Digital Interativa. A TVDI passou a vigorar no Brasil em 2007 na capital paulistana. A mudança do sinal analógico para o digital trás enormes melhorias para a transmissão e recebimento do sinal de TV. Dentre elas podemos destacar: Eliminação de Ruídos; Correção de erros; Redução do tamanho da Informação (Compactação); Melhor aproveitamento do espectro eletromagnético. A TVDI faz com que haja um grande aumento na qualidade da imagem e do áudio transmitido. Isso é possível graças à utilização de técnicas de compactação/compressão que permitem o envio de uma quantidade muito maior de informação quando comparado com o uso do sinal analógico. Além disso, há ainda a possibilidade de transmitir dados associados ou não a programação, podendo estes, virem na forma de programas interativos, comparados com os programas de computadores, aos quais estamos acostumados, contudo voltado para o conteúdo e formato televisivo. Ou seja, o usuário/telespectador, poderá participar ativamente da programação. 205

210 O caminho para se conseguir desenvolver aplicações para TVDI mais rapidamente de forma a acompanhar a evolução dos meios de comunicação e dos dispositivos eletrônicos é, sem dúvida, eliminar o trabalho repetitivo de codificação quando isto for possível, deixando o desenvolvedor cuidar somente daquilo que é específico da aplicação. Apresentamos aqui o LuaR, uma ferramenta para desenvolvimento de aplicações customizáveis para a TVDI, que utiliza a linguagem de script lua para geração automática de código NCL, agilizando o desenvolvimento de programas interativos do Sistema Brasileiro de TV Digital (SBTVD). 2. Trabalhos Relacionados Ferramentas para a TV Digital aderentes as normas do SBTVD são escassas, uma vez que tal mercado é relativamente novo no Brasil. Nesta seção faremos um breve resumo sobre duas delas: Composer(Guimarães, 2007) e o MatooltoTV(Lemos, 2008). O Composer permite a edição de arquivos NCL utilizando várias visões: visão estrutural, visão temporal, leiaute e textual. A visão estrutural abstrai, através de uma representação gráfica, as principais entidades definidas na NCL. Nessa visão o autor pode criar, editar e apagar objetos de mídia que compõem um documento, composições (conjuntos de objetos e seus relacionamentos), e elos (relacionamentos entre objetos). A visão de leiaute abstrai a disposição espacial dos objetos de mídia nos dispositivos de exibição. Através dessa visão, o autor pode criar, editar e apagar regiões espaciais associadas à exibição inicial dos objetos. A visão temporal abstrai os relacionamentos temporais entre os objetos de mídia, permitindo que a especificação temporal dos programas seja realizada através da distribuição gráfica dos objetos em relação a um eixo temporal. No ambiente de autoria Composer as quatro visões funcionam sincronamente, a fim de oferecer um ambiente integrado aos autores. Além das funcionalidades oferecidas pelas visões, para auxiliar o processo de produção de programas junto às emissoras de TV, o ambiente Composer oferece ainda suporte à edição dos programas em tempo de presentação, permitindo que as emissoras realizem operações de edição ao vivo. Além da ferramenta de autoria propriamente dita, o ambiente Composer também oferece um simulador, que permite, a qualquer instante, que o autor de um documento possa disparar sua exibição. O Composer é um ambiente de autoria ainda em fase de desenvolvimento e, como tal, possui instabilidades conhecidas. Recomenda-se a utilização da ferramenta salvando o arquivo de projeto frequentemente, já que foram relatados problemas de corrompimento deste arquivo pela ferramenta. Além dessa desvantagem, deixa a desejar na usabilidade, já que um leigo não compreende algumas funcionalidades da ferramenta. Outra ferramenta para auxílio a programação, ainda em desenvolvimento, é o MatooltoTV, que possui como foco o desenvolvimento de aplicações procedurais interativas utilizando o Ginga-J, que inclui a API Java TV, permitindo o desenvolvimento de aplicações interativas. O projeto objetiva simplificar o desenvolvimento para o usuário final. Utilizando uma IDE web padrão, o indivíduo pode construir uma aplicação sem precisar recorrer ao desenvolvimento por códigofonte. Após arquitetar a aplicação passando alguns dados relevantes e específicos às 206

211 necessidades desta pessoa, o sistema automaticamente gera um arquivo, no formato.jar, que está pronto para ser utilizado no servidor de TV Digital. Já existem protótipos iniciais baseado no padrão europeu de TVDI, com a demora da normalização do Ginga- J, o MatooltoTV sofre, não podendo ter uma devida progressão e realização de testes em ambientes reais, a utilização do MHP como objeto de estudo para o desenvolvimento da ferramenta não se mostra eficaz já que a especificação Ginga-J (ainda em fase de análise pelo FORUM SBTVD) apresentada ao público brasileiro é diferente do MHP. 3. Evolução no Desenvolvimento do Software Devido à necessidade do desenvolvimento de software cada vez mais rápido, houve uma grande evolução no campo dos paradigmas de programação, desde o paradigma estruturado até o paradigma orientado a objetos, e na área dos modelos de desenvolvimento de software passando pelo modelo em cascata até modelos mais atuais e eficientes como o XP, RUP e Modelagem Ágil. Já foi reconhecido também o valor de se ter um conjunto de problemas/soluções catalogado - Padrões de Projeto - coma finalidade de evitar a perda de tempo buscando solução para um problema previamente resolvido com sucesso. A idéia é reutilizar, agilizar o processo de desenvolvimento de software garantindo a qualidade do mesmo. A partir dessas idéias mais gerais foram surgindo ferramentas de desenvolvimento especializadas para certo domínio de aplicação. As aplicações distribuídas antes desenvolvidas usando recursos específicos de plataforma de hardware e sistema operacional através do uso de sockets foram favorecidas pelo surgimento do RPC (Remote Procedure Call) e sua evolução para o RMI (Remote Method Invocation) até especificações como CORBA ou JEE. Apareceram também as DSLs (Domain Specific Languages), linguagens de domínio específico, para facilitar a programação por meio de abstrações de dados próprias para determinado contexto. No ambiente de aplicações web pode se ver um crescente número de frameworks como o Struts, Django, Spring, Cake, Ruby on Rails, Grails, etc. Também existem frameworks para manipulação de banco de dados, como o Hibernate, que visam tornar aplicações mais livres de Banco de dados específicos. 4. LuaR Lua on Rails Através da análise de dezenas de códigos de aplicações NCL, tornou-se perceptível a excessiva repetição de códigos NCL. A Linguagem NCL, por ser uma linguagem de "cola" ou de marcação hierárquica, acaba exigindo redobrada atenção para programar. Cada uma de suas tags possui vários atributos que acabam tendo seus valores redefinidos em tags mais aninhadas. Além disso, existe muito tempo perdido no trabalho de codificação, que chega a ser um pouco tedioso demais. A proposta do nosso trabalho é justamente o desenvolvimento de uma ferramenta de desenvolvimento para aplicações NCL/Lua para TVDI, com a intenção de diminuir a carga de codificação do programador. Essa ferramenta se baseia na idéia da intersecção do código comum existente em determinadas aplicações e na percepção de alguns padrões de codificação das mesmas. 207

212 A ferramenta LuaR consiste em duas partes distintas: a primeira diz respeito a definição de alguns termos específicos de aplicação que serão usados para construção da aplicação em si. Esses termos são termos essenciais e inerentes à aplicação. Por exemplo, se quiséssemos criar uma aplicação enquete, uma maneira simples e rápida para tal, e que exige muito pouco de conhecimento sobre programação seria criar um arquivo de texto atribuir valores a atributos específicos das aplicações de enquete: aplicação: Melhor time de futebol tipo-aplicação: Enquete tema: Qual o melhor time de futebol atualmente: opção1: Palmeiras opção2: Flamengo opção3: ABC opção4: América Os termos acima definem o essencial para se ter uma enquete, que é a pargunta e suas alternativas de resposta. O campo tipo de aplicação define que aplicação está sendo desenvolvida e com isso também os termos específicos que são utilizados. A segunda parte do framework LuaR seria um pequeno interpretador - luar - que iria ler um arquivo de entrada ( o que foi definido na primeira parte ) e a partir daí gerar todo o código da aplicação. Por exemplo: se digitássemos o comando: luar futb.lr, onde futb.lr é o arquivo texto com os termos definidos acima, seria gerado o código da aplicação enquete sem maiores problemas e estaríamos usando o NCL de forma transparente. tags. Figura 3. Imagem de uma aplicação fictícia Se fôssemos programar todo o código NCL seria preciso codificar 320 linhas de Desta forma, muitas aplicações, como enquetes e informativos, poderiam ser desenvolvidas durante a apresentação de alguns programas seguindo até mesmo uma sugestão de interação do apresentador que deseja conhecer a opinião dos telespectadores. 208

213 Figura 4 - Arquitetura Geral 5. Conclusões O surgimento da TV Digital no cenário mundial e especialmente no Brasil traz grandes mudanças no modo de se desenvolver um programa para TV. Esse programa agora deve ser visto também como um software. Essa mistura entre os domínios de Televisão e Programas de Computador cria o domínio dos programas de TV Digital Interativa, trazem novos requisitos para o seu desenvolvimento. Propomos aqui o LuaR, uma ferramenta para desenvolvimento de aplicações customizáveis para a TVDI, objetivando satisfazer tais requisitos de tempo de desenvolvimento, dinamicidade e manutenabilida de exigidos no desenvolvimento de programas para TV Digital Interativa. Idealizada com base em frameworks web de desenvolvimento ágil como Grails, Cake e RubyOnRails, o LuaR utiliza a linguagem de script lua para geração automática de código NCL, agilizando o desenvolvimento de programas interativos do Sistema Brasileiro de TV Digital (SBTVD). Referências GUIMARÃES, Rodrigo Laiola; COSTA, Romualdo Monteiro de Resende; SOARES, Luiz Fernando Gomes. Composer: Ambiente de Autoria de Aplicações Declarativas para TV Digital Interativa. Departamento de Informática PUC-Rio, CASSINO, Carlos; IERUSALIMSCHY, Roberto; RODRIGUEZ, Noemi. LuaJava A Scripting Tool for Java. Departamento de Informática PUC-Rio, SOARES, Michel dos Santos. Comparação entre Metodologias Ágeis e Tradicionais para o Desenvolvimento de Software. Faculdade de Tecnologia e Ciências de Conselheiro Lafaiete Unipac. SIQUEIRA, Fábio Levy. Métodos Ágeis

214 AGILE ALLIANCE WEB SITE. Manifesto for Agile Software Development Manifesto com os princípios e valores dos métodos ágeis de desenvolvimento. Disponível em: <http://agilemanifesto.org/>. Acesso em: 01 de Outubro de SOUZA FILHO, G. L.; LEITE, Luiz Eduardo Cunha; BATISTA, C. E. C. F. Ginga-J: The Procedural Middleware for the Brazilian Digital TV System. Digital Video Applications Lab, Department of Informatics Federal University of Paraíba,. SOARES, L. F. G. ; BARBOSA, Simone Diniz Junqueira. Programando em NCL. 1. ed. Rio de Janeiro: Elsevier - Campus, p. Ginga-NCL. Disponível em: <http://www.gingancl.org.br/>.acesso em: 01 de Outubro de LEMOS, Elizama das Chagas; MEDEIROS, Luciana Araujo de; YOKOIGAWA, Camila Satsu de Amorin; BURLAMAQUI, Aquiles Medeiros Filgueira; MINORA, Leonardo Ataide. MatooltoTV: Construção Simplificada de Aplicações Interativas para TV Digital. IFRN,2008. BURLAMAQUI, Aquiles Medeiros Filgueira, SILVA, Igor Rosberg de Medeiros; BEZERRA, Diogo Henrique Duarte; Construção de programas Interativos para TV Digital utilizando o Ginga. Departamento de Informática UFRN e UERN,2008. SOARES, Luiz Fernando G.; Programando em NCL: desenvolvimento de aplicações para middleware Ginga, TV digital e Web / Luiz Fernando Gomes Soares, Simone Diniz Junqueira Barbosa. - Rio de Janeiro: Elsevier, SBTVD, (2009) Site Oficial do Sistema Brasileiro de TV Digital acessado em 10 de outubro de

215 NCL+ uma opção à utilização de API s externas junto com linguagem NCL Julio Cesar Paulino 1, Aquiles M.F. Burlamaqui 1,Luiz Marcos Garcia Gonçalves 1, Luiz Eduardo Cunha Leite 1 1 Laboratório NatalNet Universidade Federal do Rio Grande do Norte (UFRN) DCA Av. Senador Salgado Filho, Natal RN Brazil Abstract. This paper describes an extension to the NCL language that allows it to handle generic components that were not defined in the original NCL s specification. First we have an introduction to the NCL context, then we present the implementation of the NCL+ and finally some results and tests. Resumo. Este trabalho descreve uma extensão para a linguagem NCL que permite a mesma tratar componentes genéricos que não foram definidos na especificação original do NCL. Primeiramente apresentamos uma introdução ao contexto do NCL, após isso mostramos a implementação do NCL+ e finalmente alguns resultados e testes. 1. Introdução Atualmente no contexto brasileiro de TV digital, é impossível descartar a importância das aplicações interativas. Todos os fabricantes que incluírem em seu set-top box (receptor para TV Digital) a marca Ginga, devem dar suporte a no mínimo uma implementação básica do middleware que da suporte a execução de aplicações escritas na Nested Context Language (NCL)[1], linguagem declarativa adotada como padrão na TV digital brasileira. O Formatador NCL, componente do middleware ginga que da suporte a execução de aplicações NCL, pode ser considerado como um middleware estrutural[2], onde camadas de software são executadas sobre ambientes externos de modo a fazer aplicações interoperarem de forma homogênea. Como exemplo clássico de middleware estrutural podemos citar a máquina virtual Java[3], que permite a execução de aplicações escritas na linguagem Java sem restrição de sistema operacional. Fazendo uma analogia à máquina virtual Java, o Formatador NCL, precisa suportar um grande universo de aplicações possíveis para TV digital, é aí que nos deparamos muitas vezes com a necessidade de utilizar API s extras as quais sabemos que são suportadas pelo hardware, porém o middleware ainda não oferece tal suporte. Nesses casos, a utilização dessas API s é feita externamente ao Ginga-NCL, em alguns casos a utilização é feita através do LuaNCL[5], em outros casos a utilização é feita através do desenvolvimento de uma aplicação com código nativo ao set-top Box, dando origem as chamadas aplicações residentes. Nesse contexto esse trabalho vem propor a definição de uma modificação na estrutura básica do Formatador NCL para que a linguagem Ginga-NCL possibilite a extensão dos seus componentes para que aplicações que requeiram API s externas possam ser construídas também sob o formato Ginga-NCL facilitando em muitos aspectos o seu entendimento e a visualização de sua estrutura. 211

216 3. NCL+ uma extensão para linguagem NCL A proposta desse trabalho é implementar um conjunto de tags que permitam a extensão da linguagem NCL pelos desenvolvedores de aplicação e de middleware. Combinando os recursos do formatador NCL e do interpretador Lua, podemos definir tags que contenham conteúdos específicos do fabricante da aplicação e tal conteúdo pode ser controlado pelo formatador através de um código escrito em lua. Figura 1, estrutura básica de um formatador com suporte a NCL+ A Figura 1, mostra a idéia da extensão proposta. O bloco NCLLoader carrega o documento NCL normalmente, ao fim do carregamento o bloco Pre-Processor irá fazer as otimizações necessárias, e identificará que existe um componente genérico assim o préprocessador irá executar funções de callback escritas em lua que devem implementar o tratamento inicial específico daquele componente, guardando as devidas informações necessárias para o seu funcionamento. Depois disso outros callbacks em lua precisam estar definidos especificando que ação o formatador tomará quando uma específica ação do formatador for executada sobre um componente genérico. Assim, deverá estar especificado em lua não só o comportamento do módulo Pré- Processor, ao encontrar os genericcomponent, como o comportamento do formatador NCL quando executar ações básicas (start, stop, resume, pause, abort ou set) sobre esses nós. É importante que fique claro também o fato de que apenas nós que especificam componentes NCL são passíveis a essa extensão, ou seja, a parte lógica dos links e conectores são mantidas, não sendo permitido ao desenvolvedor, adicionar novas tags com capacidades lógicas ao formatador Implementação do NCL+ Nesta seção serão tratados os aspectos técnicos de implementação atingidos neste trabalho, bem como as mudanças na arquitetura proposta devido a forma como o formatador NCL utilizado foi implementado. Iniciaremos abordando a estrutura de um documento contendo tags NCL+, passando para a parte dos scripts lua envolvidos e finalizando com as modificações feitas no formatador NCL para que o mesmo suportasse a adição do NCL Estrutura de tags Os documentos NCL são constituídos de arquivos XML que é uma linguagem muito bem formada e utilizada em larga escala em uma infinidade de aplicações. Como XML é um padrão de formatação de texto que precisa de tags chave para que possa ser corretamente 212

217 interpretado, foi necessário definirmos tags que pudessem ser adicionadas em documentos NCL para que os mesmos possuíssem suporte as funcionalidades propostas por esse trabalho. Figura 2, DTD das tags NCL+ A Figura 2, mostra a estrutura de tags propostas que devem ser adicionadas à definição do Ginga-NCL a fim de que o mesmo suporte a definição de componentes não definidos inicialmente pela norma. Todos os componentes envolvidos, com exceção do elemento attribute, definem o atributo id que serve para identificar o elemento de forma única em todo documento a fim de permitir uma referencia direta ao elemento caso seja necessário. O elemento genericcomponentbase define até dois atributos, o atributo manufacturerid é um atributo obrigatório que é usado pelo formatador para identificar qual fabricante de middleware possui uma implementação compatível com aquele conjunto de componentes que irão ser definidos, por fim um atributo opcional required especifica quais API s daquele fabricante serão utilizadas pelos componentes. Dentro do componente genericcomponentbase devem ser especificados os componentes genéricos definidos pelo elemento genericcomponent, que pode definir até três atributos. O atributo class especifica uma classe de componentes, é de presença opcional, sua função é apenas para organização para classificação de componentes que fazem a mesma função. O atributo behaviorscript é o mais importante desse elemento, ele especifica a localização de um script em lua que será executado quando uma ação for executada pelo formatador sobre um genericcomponent, a estrutura desse script será discutida mais tarde, porém é importante ressaltar que esses scripts não precisam ser refeitos dependendo das aplicações, ele pode ser desenvolvido pelos fabricantes e distribuídos de forma que as aplicações apenas utilizam esses componentes. As tags filhas do elemento genericcomponent são genericarea e property, a tag property é definida exatamente como é definida no NCL originalmente, com apenas dois atributos name e value, definindo propriedades dos componentes genéricos que devem ser interpretados pelo behaviorscript a fim de configurar o componente genérico antes que o mesmo seja executado. A tag genericarea deve ser vista como uma âncora, a diferença aqui é que a definição é mais genérica que a definição clássica da tag area, seus atributos name e 213

218 value propiciam uma forma mais genérica de definir pontos de eventos dentro de componentes. Figura 3, exemplo de aplicação utilizando as tags ncl+ Através do NCL+ tornamos as aplicações mais flexíveis permitindo a adição de componentes externos de forma mais visível, podendo executar funções diversas no documento ncl. Com as tags apresentadas, foi feito um exemplo de aplicação que será mostrado mais tarde, porém um trecho de código pode ser visto na Figura 3, onde um novo componente, da classe wiimote, é adicionado. 3.3 Lua NCL e scripts necessários ao NCL+ Adicionar tags com funcionamento específico é necessário, mas não suficiente para dar ao NCL a capacidade de extensão. Um dado fabricante pode desejar adicionar a tag específica x enquanto outro pode desejar adicionar a tag específica y, e ambos podem fazer isso modificando o seu middleware Ginga-NCL da forma como bem entenderem, embora ambos estivessem refazendo uma estrutura que poderia ser genérica a todos. Com a utilização de Lua como linguagem de extensão, podemos adicionar lógicas escritas em lua ao comportamento da máquina de apresentação, utilizando callbacks prédefinidos sem a necessidade de mudança de código nativo quando houvesse a necessidade de adição ou modificação do comportamento dos componentes ncl. No NCL+ isso é possível através da utilização dos scripts de comportamento especificados para cada componente genérico. A Figura 4, mostra os cabeçalhos dos callbacks que devem ser implementados em um script de comportamento. Figura 4, funções necessárias em um script de comportamento Como pode ser visto na Figura 4 as duas primeiras funções (setupareas, setupproperties) são chamadas de callbacks de inicialização, eles são executados pelo préprocessador cada vez que uma tag genericcomponent é identificada. As chamadas de inicialização passam como argumentos o id da tag e as respectivas definições de genericareas e property definidas no elemento passando toda informação relativa a tais 214

219 componentes em forma de lista para que o script de comportamento possa identificar cada um e tratá-lo de forma adequada. Mais especificamente os conteúdos de cada uma das listas é exibido na Tabela 1, que utiliza a notação de lua para facilitar a especificação. areas properties area=[(areaid={name,value})*] properties=[(propertyid=value)*] Tabela 1, especificação das listas enviadas para as funções de setup Com o conteúdo passado para as funções de setup o componente pode executar seu comportamento corretamente. Um ponto importante que devemos citar é que as execuções dos callbacks de comportamento são feitas em paralelo a execução do documento, impedindo assim que os scripts de comportamento bloqueiem o funcionamento do formatador ncl, permitindo assim que o formatador fique livre para executar outras tarefas. Após o início da execução o componente genérico pode se comportar como uma aplicação LuaNCL continuando sua execução através de timers podendo assim disparar suas âncoras na hora correta, sem ocupar a execução do formatador ncl. Para que fosse possível a um componente NCL+ postar um evento de start/stop de uma de suas âncoras, foi necessária uma simples modificação para identificar o evento, adicionando a classe de eventos nclp, na lista de classes de eventos do módulo Event do lua NCL. Dessa forma o formatador pode identificar que o evento vinha de um componente NCL+ e o transformar em um evento genérico para que seja tratado normalmente pelos links. 4. Resultados e Testes Para validação do NCL+ implementamos uma aplicação ncl comum que possui interações com eventos do controle do Nintendo Wii[6], wiimote. Através de componentes NCL+ foi definido o componente interno wiimote que faz a utilização de uma API simples de acesso ao wiimote escrita em lua. Desse modo foi possível escrever um script de comportamento que descreve o funcionamento do componente. Com o componente definido nossa aplicação consegue fazer com que a aplicação responda a eventos gerados pelo componente wiimote, bem como possa iniciar (através do rolestart), pausar, parar a captura de eventos, dentre outras possíveis funcionalidades. Figura 5, aplicação de validação implementada 215

220 Como visto na Figura 5, a aplicação é simples, apenas mostrando quatro componentes de mídia que variam de acordo com o acelerômetro do wiimote. O código mostrado na Figura 3, é o responsável pelo controle do comportamento do componente wiimote nessa aplicação. Quando o formatador ncl executa uma ação de start sobre o componente wiimote1 o callback rolestart é chamado que faz a chamada da função necessária para conectar o wiimote. Quando a conexão é feita o comportamento da aplicação é controlado pelo formatador NCL que reage através de links os eventos gerados pelo wiimote que são disparados pelo script de comportamento. 5. Conclusões Implementamos nesse trabalho um conceito novo de componentes genéricos dentro do ginga NCL, esses componentes tem seu comportamento definido por scripts escritos em lua integrados a linguagem ncl como meio de extensão da mesma. As principais contribuições dessa implementação para o Ginga-NCL estão nas possibilidades de inclusão e extensão de funcionalidades sem necessidade de modificação de código nativo, podendo o middleware evoluir sem muitos problemas de integração com o decorrer do tempo. Vimos a semelhança do método utilizado com a utilização de lua NCL diretamente em mídias comuns, porém essa prática torna o documento totalmente a mercê de transições de estado da aplicação lua. Uma grande vantagem que o NCL+ possui sobre a utilização de Lua NCL diretamente é quanto a automatização dos diagramas de fluxo de eventos da aplicação, que podem ser gerados automaticamente em documentos NCL clássicos, mas perdem essa característica quando os documentos possuem mídias lua. Embora a utilização de LuaNCL seja necessária para o NCL+, a inclusão do mesmo vem apenas acrescentar novas possibilidades aos desenvolvedores de middleware e aplicações para que os mesmos tenham flexibilidade de definir seus próprios componentes, permitindo que mesmo componentes NCL como media, context, e switch sejam especificados através de nós NCL+. 6. Referências [1]- Soares, L., Rodrigues, R., Moreno, M. Ginga-NCL: the Declarative Environment of the Brazilian Digital TV System. Journal of the Brazilian Computer Society, 2007 [2]- Vinoski, S. An Overview of Middleware. Lecture Notes in Computer Science, Springer [3]- Sun - Java Virutal Machine, disponível online em [4]- Sant Anna, F., Cerqueira, R., Soares, L. NCLua - Objetos Imperativos Lua na Linguagem Declarativa NCL. [5]- Nintendo Wii, disponível online em 216

221 1 Compressão de Vídeo baseada no Padrão H.264/AVC Utilizando o Algoritmo Diamond Search Mizael Araújo Pereira 1, Karla D. N. Ramos 1 1Laboratório LUMEN Universidade do Estado do Rio Grande do Norte Departamento de Computação Av. Ayrton Senna, Natal-RN Brasil Abstract. Among the compression standards, the standard H.264/AVC reached the highest level of processing and compression, even though it demands great computing complexity both in the coders and decoders. Acknowledging the commercial interest in this standard, many research teams have been trying to develop implementations in hardware that can solve the complexity problem and reach the requisites of the applications to which they were developed. This research worked on the development of a search module that would reach both the efficiency requisites of the compression and the speed processing requirements for an application in real time, what came up with an implementation as a diamond search algorithm. Resumo. Dentre os padrões de compressão, o padrão H.264/AVC atingiu as taxas mais elevadas de processamento e compressão, apesar de também exigir grande complexidade computacional dos codificadores e decodificadores. Diante do interesse comercial desse padrão, muitos grupos de pesquisa tem tentado desenvolver implementações em hardware para solucionar o problema da complexidade e ainda atingir os requisitos das aplicações para as quais são propostos. Essa pesquisa objetiva o desenvolvimento de um módulo de busca que atenda tanto aos requisitos de eficiência de compressão quanto ao requisito de velocidade de processamento para uma aplicação que exige resultados em tempo real. Por esses motivos, definiu-se pela implementação do algoritmo de busca diamond search. Esta pesquisa recebeu o apoio financeiro da Fundação de Apoio à Pesquisa do Estado do Rio Grande do Norte - FAPERN 217

222 2 1. Introdução Um sistema de emissora de televisão digital, que executa processamento, compressão e descompressão de imagens, praticamente em tempo real, necessita que todas essas operações sejam executadas a uma velocidade de 30 figuras por segundo, de maneira que o receptor obtenha uma imagem no nível de qualidade exigido pelo mesmo. Diante da necessidade do desenvolvimento de módulos que obtenham resultados satisfatórios e rápidos, esta pesquisa está voltada para o desenvolvimento de componentes, que agilizem o processo de compressão, mais especificamente o processo de busca. Apesar da complexidade elevada do padrão H.264/AVC, torna-se vital o aumento no grau de compressão das imagens, possibilitando o envio de uma quantidade menor de informação e agilizando a recepção de dados do lado do receptor. O módulo do algoritmo de busca, parte integrante do processo de estimação de movimento [Zandonai, D. 2003] de um sistema de compressão de vídeo, é um dos maiores responsáveis pelo desempenho e também eficiência da compressão. Portanto, este módulo é o foco desse trabalho. A partir do estudo de alguns algoritmos de busca, e considerando o objetivo da pesquisa, o algoritmo diamond search foi selecionado. Este algoritmo foi implementado em VHDL e comparado, quanto a velocidade de processamento, com o algoritmo fullsearch (busca completa) [Zandonai, D. 2003]. O algoritmo full-search é conhecido por obter sempre o resultado ótimo de uma busca. Visando apresentar o desenvolvimento dos módulos supracitados, este resumo estendido está dividido em três seções, cuja seção 2 traz informações sobre a técnica de compressão de vídeo e a seção 3 apresenta o algoritmo diamond search utilizado para otimizar o processo de compressão comparado ao algoritmo da busca completa. A seção 4 apresenta os resultados da pesquisa realizada. 2. Compressão de Vídeo O processamento de imagem é importante para a compressão e descompressão, pois o objetivo principal de um processamento de imagens é identificar redundâncias contidas nas imagens, de modo que um mesmo elemento possa ser codificado e associado a várias outras imagens, de forma a reduzir a quantidade de informação a ser armazenada. A explicação para a relação entre a eficiência da compressão e a identificação de redundâncias reside no fato de que um vídeo é composto por uma seqüência de figuras apresentadas seqüencialmente, logo, para que o vídeo tenha coerência como um todo existe a necessidade que cada uma das cenas tenha uma relação entre si. Com base nessa propriedade torna-se possível comprimir o vídeo em menos dados do que as versões originais se forem devidamente exploradas as redundâncias existentes de uma cena para outra. 218

223 3 Feito esse processo, não será mais necessário armazenar todos os dados de todas as figuras, apenas alguns dados de algumas figuras e vários dados menores relacionados ao direcionamento, de modo que a maioria das imagens possam ser remontadas usando dados de outras imagens tendo apenas que direcionar partes dessas imagens adequadamente, como no processo de montagem de um quebra-cabeça. Vale salientar que a remontagem da imagem é um processo reservado somente ao aparelho responsável por realizar a descompressão(decodificador, assim como o que é mostrado em [ITU-T Recommendation H.264/AVC. 2007]), e que o aparelho deverá estar em posse do usuário final que poderá conduzir a descompressão e a exibição de informação simultaneamente. 3. Algoritmo de Busca Para se buscar redundâncias entre imagens é necessário comparar partes de uma imagem com partes de outra imagem (figura de referência), contudo a primeira imagem é uma imagem redundante em potencial em relação à última imagem. Para isso torna-se necessário dividir a imagem em partes ou "unidades de processamento". Todavia, a unidade de processamento usada no processamento das imagens no padrão H.264/AVC é conhecida como macrobloco, e trata-se de um quadrado com 16x16 pixels extraídos da figura a ser comprimida. Durante o processo de compressão de vídeo, vários processos menores podem ser analisados, como o processo de busca, o processo de cálculo de SAD (Sum of Absolute Difference), o processo de construção da stream de dados descrita em [ITU-T Recommendation H.264/AVC. 2007] e por fim os processos de codificação e quantização da informação. O processo de cálculo de SAD é o processo que realiza a comparação entre duas partes. O processo de codificação é o processo responsável por diminuir a quantidade de dados armazenados usando como referência a forma como os dados são representados (zeros e uns). A quantização é o processo que torna a informação digital (valores discretos), tornando a informação apta a ser enviada. O processo da construção da stream de dados é a responsável por dispor as informações de modo que o receptor possa compreender. O processo de busca, elemento foco desta pesquisa, é um processo que dita quais partes da figura de referência serão comparadas com a parte em questão da figura em processo de compressão (cada pedaço da figura a ser comprimida passa por esse processo até ter toda a figura devidamente processada). O algoritmo de busca é um algoritmo com efeito decisivo na velocidade do sistema, já que, dependendo de como o algoritmo é feito, menos ou mais quadros terão que ser analisados. O algoritmo de busca conhecido como full search se baseia em testar todas as possibilidades existentes dentro da figura de referência, para cada macrobloco a ser processado pela figura a ser comprimida. Dessa forma, a quantidade de comparações realizadas pelo módulo de SAD torna-se proibitivo e muito demorado. O algoritmo estudado é conhecido como diamond search, e se baseia em obter o 219

224 4 macrobloco mais redundante possível, partindo de uma determinada área. O processo de busca pára tão logo esta região seja encontrada. Como é de se esperar, o macrobloco encontrado nem sempre é o mais semelhante possível ao macrobloco de referência, contudo, são realizadas aproximadamente oito iterações para encontrá-la não importando o tamanho da imagem. O algoritmo toma como ponto de partida o centro da figura de referência, e a busca realizada por ele têm duas fases diferentes, sendo que a primeira delas é mais abrangente. Nove macroblocos são analisados na primeira fase da pesquisa, sendo eles o macrobloco do meio e os macroblocos adjacentes (considerando cima, baixo, esquerda, direita, e diagonais). A segunda fase da pesquisa é bem mais restrita e analisa apenas quatro macroblocos além do macrobloco central, sendo que os outros macroblocos são o macrobloco de cima, o de baixo, o da esquerda e o da direita. Outra característica importante a considerar é a distância entre o macrobloco central e os macroblocos adjacentes escolhidos. A distância entre eles deverá ser sempre maior durante a busca abrangente do que durante a busca restrita, de modo que, durante essa pesquisa em particular, a distância escolhida para a busca abrangente é de dois pixels enquanto a distância escolhida para a busca restrita é de apenas um pixel. O processo de busca sempre começa com a busca abrangente. Um endereço de macrobloco é enviado ao módulo de SAD, para que o mesmo possa realizar uma comparação. Ao fim da comparação de todos os macroblocos pertencentes à busca abrangente, poderá se passar para a busca restrita, caso o macrobloco mais semelhante seja o bloco do meio. Caso contrário, a busca abrangente terá de ser realizada novamente tomando como macrobloco central o macrobloco que foi definido como mais semelhante. Da mesma forma que funciona a busca abrangente funciona a busca restrita. Contudo, caso seja encontrado o macrobloco central como macrobloco mais semelhante, nesse caso, o processo de busca será finalizado para aquele macrobloco e o sistema atuará tomando aquele macrobloco como o mais semelhante. Quando o macrobloco é encontrado, o sistema deverá proceder com a produção de vetores de movimento (usados para posicionar o macrobloco durante o processo de descompressão) e representações de resíduo (a diferença entre o macrobloco verdadeiro e o macrobloco semelhante escolhido) e posicionar tudo isso na stream de dados daquela figura para proceder com a codificação. O algoritmo desenvolvido em VHDL é composto por estados, sendo o primeiro estado o responsável por organizar os valores de inicialização do sistema. O segundo estado é responsável pelo envio dos dados e do recebimento da resposta do módulo SAD (o SAD de uma partição de sub-macrobloco enviado e já calculado), de modo que o processo continue para o terceiro estado. Uma característica importante da compressão de vídeo H.264/AVC é que, quando necessário, os macroblocos podem ser divididos em blocos menores, de modo que mais vetores de movimento sejam usados para representá-los (divisão dinâmica de macroblocos), como mostrado por (Lin Huang, 2004). Essa técnica melhora a 220

225 5 compressão, e justifica por que o algoritmo de busca desenvolvido sempre envia partições de sub-macroblocos [ITU-T Recommendation H.264/AVC. 2007] para o módulo SAD. Neste caso, cada fragmento de macrobloco pode ser analisado separadamente e se juntar ou não ao macrobloco final que será codificado na stream de dados. O terceiro estado controla se o macrobloco está completamente calculado ou não, enquanto o quarto e o quinto estados são os responsáveis por direcionar os endereços de outros macroblocos da busca atual, ou, se todos os endereços da busca atual já foram calculados, passar para a fase de busca seguinte, ou simplesmente encerrar a busca (caso não haja estado seguinte). É também no quarto e quinto estado que ocorre a comparação entre o macrobloco central com todos os outros macroblocos adjacentes, procedendo a partir desse ponto uma troca de macrobloco central, somente se for encontrado um macrobloco menor do que o central. 4. Considerações Finais Foi desenvolvido um módulo de busca em VHDL, implementando o algoritmo diamond search de forma seqüencial, para em um segundo momento ser desenvolvida a alternativa paralela. O módulo em VHDL do diamond search trabalha usando como ponto de referência um frame do respectivo vídeo, sendo necessário que haja comunicação entre esse módulo e um módulo de memória, além de um módulo de cálculo aritmético de SAD. Para estender a forma de busca seqüencial para paralela, a implementação do sistema funcionaria paralelamente baseando-se no fato de que uma figura que tenha sido colocada na memória terá N endereços de memória associados a cada um de seus N pixels, o que nos leva à possibilidade de usar cada módulo para cada parte da memória até um determinado número. A alteração necessária seria a colocação de mais módulos de busca diamante (diamond search), sendo cada um deles relacionado a um ou mais módulos de cálculo de SAD (para evitar problemas de concorrência, teoricamente um módulo de SAD para cada módulo de diamond search). Cada módulo de diamond search, por sua vez, terá que estar limitado dentro daquele espaço de memória recluso ao invés de estar limitado à figura. Alternativa similar seria delimitar uma figura diferente para cada módulo, tendo efeito similar ao anterior, mas sem que exista a restrição dos limites das bordas das figuras. O teste de desempenho do algoritmo foi feito baseando-se em frames de tamanho 32x32 pixels e tem como critério de avaliação a velocidade necessária para realizar os processamentos necessários tomando nota a velocidade de clock usada na implementação em hardware e os dados de hardware usados para processar a 221

226 6 implementação em software. A versão em software foi executada em um computador com o sistema operacional windows XP professional com processadores AMD Athlon X2 de 3200 Mhz de clock, enquanto a implementação em VHDL foi processado com clock de um ciclo a cada 10 us. Em relação aos resultados calculados, vemos que a implementação em software calcula um frame a cada 149,62 ms, enquanto a implementação em VHDL realiza a mesma marca em aproximadamente 473,2 us. Concluindo, a implementação em VHDL realiza as operações em aproximadamente 0, segundos enquanto a implementação em software o faz em 0,149 segundos, mostrando a diferença de velocidade entre suas operações. 5. Agradecimentos Sinceros agradecimentos aos alunos dos Laboratórios LUMEN-UERN e LASIC-UFRN pelo apoio dado a essa pesquisa. 6. Referências Zandonai, D. (2003) Uma arquitetura de hardware para estimação de movimento aplicada à compressão de vídeo digital, Dissertação (Mestrado em ciência da Computação) Universidade Federal do rio grande do sul UFRS, Rio Grande do Sul, ITU-T Recommendation H.264/AVC.(2007) International Telecommunication Union. (03/05) : advanced video coding for generic audiovisual services, Brown, S., Vranesic, Z. (2005), Fundamentals of Digital Logic with VHDL Design, Second Edition, Mc Graw-Hill, Lin Huang. (2004) Variable-size block selection in h Trabalho de aluno. Allen Dewey.(1997) Analysis and design of digital systems with vhdl. Boston: PWS, David P.;Douglas T.(1997) Vhdl made easy. New Jersey: Prentice hall PTR,

227 Um Mecanismo para Programação Multithreaded em Arquitetura Multicore Benedito Barbosa Ribeiro Neto 1, Adalton de Sena Almeida 2 1 Instituto Federal de Educação, Ciência e Tecnologia (IFPI) Teresina PI Brasil 2 Universidade Federal de Pernambuco (UFPE) Recife PE Brasil Abstract. In order to promote the use of parallel programming, this paper aims to propose a mechanism for multithreaded programming that allows the programmer to produce a correct code, robust and secure. To evaluate its performance and use of hardware resources available, was used to generate batches of a health plan as the specific context of implementation. In addition to improving existing applications and / or provide new implementations, this paper aims to stimulate the identification of design patterns that make parallel programming easier to understand, easy to develop and maintain. Resumo. Visando difundir o uso de programação paralela, este trabalho tem por objetivo propor um mecanismo para programação multithreaded que permita ao programador produzir um código correto, robusto e seguro. Para avaliar o seu desempenho e o uso dos recursos de hardware disponíveis, utilizou-se a geração de lotes de um plano de saúde como contexto específico de implementação. Além de melhorar as aplicações existentes e / ou proporcionar novas implementações, este trabalho pretende incentivar a identificação de padrões de projeto que tornem a programação paralela mais compreensível, fácil de desenvolver e manter. 1. Introdução Durante as últimas décadas, o desempenho alcançado pelos microprocessadores cresceu exponencialmente. Esse crescimento deveu-se principalmente ao avanço da tecnologia de fabricação que possibilitou a construção de transistores menores e mais rápidos. No entanto, mesmo seguindo a Lei de Moore 1, fatores novos estão limitando o crescimento do desempenho dos microprocessadores: aumento da energia dissipada, limite na extração de paralelismo no nível de instruções e complexidade de projeto. A tendência atual é desenvolver projetos mais simples, com freqüência de operação mais baixa, e integrar em um mesmo chip dois ou mais núcleos de processamento (RIGO et al, 2007). Em arquiteturas de um só núcleo (singlecore), o aumento da freqüência de operação dos microprocessadores implicava um aumento proporcional no desempenho do software existente. Em arquiteturas de múltiplos núcleos (multicore), isso deixa de ser verdade. Para fazer uso do potencial oferecido pelo hardware atual, o software deve ser paralelizado (RIGO et al, 2007). 1 Em 1965, Gordon Moore especulou que o número de transistores utilizados em cicuitos integrados iria dobrar anualmente. Em 1975, ele alterou sua projeção, estipulando que esse número dobraria em intervalos de dois anos. Essa previsão, conhecida como Lei de Moore, tem-se mantido até os dias atuais e se tornou a força motora que alavancou o avanço da indústria de semicondutores (RIGO et al, 2007). 223

228 O modelo paralelo de programação é tão antigo quanto o modelo seqüencial, mas é inerentemente mais difícil, principalmente quanto ao desafio de se produzir um código correto, robusto e seguro. O modelo mais utilizado atualmente é o multithreaded, no qual um processo é uma abstração para um programa em execução, e uma thread é um segmento de execução independente dentro de um processo. O sucesso do modelo multithreaded decorre da associação quase direta entre as abstrações oferecidas pelo modelo e a forma como o hardware atual as implementa (RIGO et al, 2007). Este trabalho tem por objetivo propor um mecanismo para programação multithreaded que permita ao programador produzir um código correto, robusto e seguro. Para avaliar o seu desempenho e o uso dos recursos de hardware disponíveis, utilizou-se a geração de lotes de um plano de saúde como contexto específico de implementação. Além de melhorar as aplicações existentes e/ou proporcionar novas implementações, este trabalho pretende incentivar a identificação de padrões de projeto que tornem a programação paralela mais compreensível, fácil de desenvolver e manter. 2. Materiais e Métodos Segundo Rigo et al (2007), é comum paralelizar iterações de um laço, pois cada iteração independente pode ser executada por uma thread. Laço é uma estrutura de repetição presente em linguagens de programação, composta por uma condição e um bloco de código. Essa estrutura pode ser pré-testada, pós-testada, com variável de controle ou usada para iterar itens de uma coleção. Desenvolvido em JAVA, a geração de lotes do IAPEP Saúde é um exemplo de fluxo seqüencial formado pela iteração de itens de uma coleção. O IAPEP Saúde é o plano de assistência familiar oferecido pelo Instituto de Assistência e Previdência do Estado do Piauí (IAPEP) aos servidores públicos estaduais. Cada segurado tem acesso à atendimentos médicos e odontológicos através dos prestadores credenciados. Cada atendimento, representado por uma guia médica ou odontológica, armazena a data de atendimento do segurado e o valor total dos procedimentos realizados por ele. A guia é o instrumento utilizado para auditoria e pagamento do prestador. A geração de lotes facilita o trabalho dos auditores, pois cada lote reúne as guias registradas por um prestador em uma determinada competência. Para o IAPEP Saúde, competência é o prazo entre os dias 26 do mês anterior e 25 do mês atual, estabelecido para o registro de guias. Após o final de uma competência, é necessário gerar um lote para cada prestador. A Figura 01 apresenta as classes envolvidas nesse fluxo. Figura 01 Diagrama das classes envolvidas na geração de lotes. 224

229 Na Figura 01, o método buscarguias() definido na classe Prestador retorna todas as guias registradas por um prestador em uma competência. Essas guias são associadas a um lote por meio do método gerarlote(). O lote possui um identificador para garantir a sua unicidade. Além disso, ele armazena a quantidade de guias associadas, através do atributo numeroguias, e o somatório do valor total de cada uma, através do atributo valorlote. Para finalizar, o lote é salvo no banco de dados pelo método salvarlote(). A fim de paralelizar as iterações de um laço, identificou-se o Padrão Observer. Esse padrão mantém os objetos atualizados quando algo importante ocorre. Um serviço de assinatura de jornais é uma boa maneira de visualizá-lo. Nesse cenário, uma editora (sujeito) entrega novas edições de um jornal para seus assinantes (observadores). Enquanto forem assinantes, continuarão recebendo jornais. Ao cancelar a assinatura, o assinante deixa de receber os jornais (FREEMAN e FREEMAN, 2007). As figuras 02 e 03 apresentam os diagramas de classes e de seqüência do mecanismo proposto. Figura 02 Diagrama de classes modelado a partir do Padrão Observer. Figura 03 Diagrama de seqüência do mecanismo proposto por este trabalho. 225

230 De acordo com os diagramas, um objeto da classe Master (mestre) escalona uma coleção de entidades (Entity) entre dois objetos da classe Slave (escravo). Essas entidades estão organizadas em fila (Queue) e compartilham a mesma tarefa, porém sobre diferentes partes de um conjunto de dados. Essa tarefa é definida pelo método runtask(), cujos parâmetros são atribuídos no construtor da classe Master e retornados pelo método getparameters(). Cada entidade terá sua tarefa executada por um escravo em uma thread diferente, através do método run(), definido pela interface Runnable. O processamento paralelo dessas tarefas pode ser visto pelo corpo do operador par. Ao invocar o método execute(), o mestre instancia dois escravos e estabelece uma relação um-para-muitos através do método registerobserver(), conforme ao Padrão Observer. Em seguida, o método createthread() atribui uma entidade ao escravo por meio do método setentity(), além de criar e iniciar uma nova thread, que executará o método runtask() da entidade. Após concluir a execução, o escravo utiliza o método notifyobserver() para informar ao mestre que a tarefa acaba de ser concluída. O método update() indica se ainda há uma entidade na fila. Se não houver, o processamento é concluído. Caso contrário, o método getnextentity() atribui a próxima entidade. 3. Resultados e Discussão No modelo multithreaded, threads comunicam-se através da memória compartilhada. Acessos às mesmas posições de memória precisam ser explicitamente sincronizados para evitar interferências entre threads. As formas de sincronização atuais empregam bloqueios, que do ponto de vista dos processadores multicore, limitam o paralelismo (RIGO et al, 2007). Para aumentar o nível de paralelismo, o mecanismo descrito adotou um único método sincronizado: getnextentity(). Isso impede que os dois escravos executem a tarefa da mesma entidade. Dessa forma, menos bloqueios são utilizados, provendo estabilidade. Assim, o programador não precisa garantir a sincronização, pois o controle de acesso à memória compartilhada é feito automaticamente pelo mestre. Na arquitetura singlecore, o processador executa somente uma tarefa por vez. Sabendo disso, entra em cena o escalonador de threads, que reúne as threads a serem executadas e faz o processador alternar a execução de cada uma delas. Na arquitetura multicore, a diferença é que o escalonador tem dois ou mais núcleos de processamento para executar suas threads, proporcionando execuções verdadeiramente paralelas. Segundo Sierra e Bates (2007), não é possível controlar o tempo de execução de uma thread e qual será a próxima thread a ser executada. Essas escolhas são feitas pelo escalonador da Máquina Virtual JAVA (JVM) e, mais amplamente, pelo escalonador do Sistema Operacional (SO). Primeiro, a própria JVM tem que ser o processo sendo executado pelo SO. Somente depois, a execução das threads será alternada pelo processador. Para avaliar o desempenho da geração de lotes do IAPEP Saúde e o uso dos recursos de hardware disponíveis, utilizou-se um computador com 1.0 GB de memória, processador Intel de dois núcleos (2.0 GHz de freqüência cada núcleo) e sistema operacional Fedora 8. O espaço amostral para execução dos fluxos é formado por guias registradas em As figuras 04 e 05 mostram o desempenho obtido pela geração dos lotes de atendimento médico e odontológico, respectivamente. A análise dos dados se resume na comparação entre o tempo gasto pelo fluxo seqüencial e o tempo gasto pelo fluxo paralelo para geração dos lotes de cada competência. 226

231 Figura 04 Geração dos lotes de atendimento médico em Figura 05 Geração dos lotes de atendimento odontológico em Observa-se, por exemplo, que 536 prestadores registraram guias médicas em janeiro de A geração dos lotes dessa competência foi concluída após segundos pelo fluxo seqüencial, enquanto o fluxo paralelo concluiu em segundos. A diferença entre esses tempos é equivalente à 50,92% do tempo gasto pelo fluxo seqüencial. A Figura 06 mostra o uso dos núcleos de processamento durante a execução do fluxo seqüencial. De maneira alternada, cada núcleo utiliza até mais de 80% de sua capacidade de processamento. A Figura 07 mostra o uso durante a execução do fluxo paralelo. Nesse caso, cada núcleo utiliza menos de 40% de sua capacidade de processamento, permitindo que outras aplicações sejam executadas simultaneamente. Figura 06 Uso dos núcleos durante a execução do fluxo seqüencial. 227

232 Figura 07 Uso dos núcleos durante a execução do fluxo paralelo. 4. Conclusão Este trabalho propôs um mecanismo para programação multithreaded modelado a partir do Padrão Observer. Segundo Booch et al (2005), todas as aplicações bem-estruturadas são repletas de padrões. Padrões de projeto fornecem uma linguagem compartilhada que maximiza a comunicação e a troca de experiências. Uma vez que bloqueios restringem o nível de paralelismo em microprocessadores multicore, esse mecanismo mostra-se tangível por aumentar o nível de paralelismo e controlar o acesso à memória. Inicialmente, modelou-se elementos que permitem aos programadores visualizar, especificar, construir e documentar os artefatos de uma aplicação multithreaded. Esses elementos evitam, através de um único método sincronizado, interferências entre threads que compartilham um mesmo objeto. Dessa forma, menos bloqueios são usados, diminuindo o risco de erros e produzindo um código correto, robusto e seguro. Finalmente, para avaliar o desempenho desse mecanismo e o uso dos recursos de hardware disponíveis, utilizou-se a geração de lotes do IAPEP Saúde como contexto específico de implementação. Em resumo, a avaliação de desempenho mostra que o fluxo paralelo obteve melhor desempenho que o fluxo seqüencial, em todas as competências de 2008 tanto no atendimento médico quanto no odontológico. O mecanismo proposto tem melhor desempenho em aplicações que utilizam processamento de forma intensiva, pois quanto maior o número de entidades, maior o número de threads. Mesmo não sendo possível controlar o tempo de execução de uma thread e qual será a próxima thread a ser executada, verificou-se que outras aplicações terão melhor desempenho ao serem executadas simultaneamente à geração dos lotes, pois cada núcleo utiliza menos de 40% de sua capacidade de processamento. REFERÊNCIAS BIBLIOGRÁFICAS BOOCH, Grady; RUMBAUGH, James; JACOBSON, Ivar. UML: Guia do Usuário. 2. ed. Rio de Janeiro: Elsevier, FREEMAN, Eric. FREEMAN, Elisabeth. Use a Cabeça! Padrões de Projeto. 2. ed. Rio de Janeiro: Alta Books, RIGO, Sandro; CENTODUCATTE, Paulo Cesar; BALDASSIN, Alexandro. Memórias Transacionais: Uma Nova Alternativa para a Programação Concorrente Disponível em: Acesso em: 16 mar SIERRA, Kathy. BATES, Bert. Use a Cabeça! Java. 2. ed. Rio de Janeiro: Alta Books,

233 A Interoperabilidade do Padrão IEEE 1451em Redes de Sensores sem Fio Christiane de Araújo Nobre 1, Karla D. N. Ramos 1 1 Laboratório LUMEN Universidade do Estado do Rio Grande do Norte Departamento de Computação Av. Ayrton Senna, Natal-RN Brasil Abstract. This paper presents a study about wireless sensors network according IEEE 1451 standards, more specifically the IEEE and IEEE standards. Whilst the standards defines a common functionality set, commands, and Transducer Electronic Data Sheets TEDS for the family IEEE 1451, the standard defines a interface transducer NCAP and TEDS for wireless transducers. Through this studying, it is intended to develop in the hardware description language VHDL a module that represents the interoperability of IEEE standar and the Bluetooth technology supported by standard. Resumo. Este artigo apresenta um estudo sobre as redes de sensores sem fio à luz da família de padrões IEEE 1451, mais especificamente dos padrões e Enquanto o padrão define um conjunto de funcionalidades comuns, comandos e Transducer Electronic Data Sheets TEDS para a família 1451, o padrão define uma interface transdutor-ncap e TEDS para transdutores sem fio. Com base nesse estudo, pretende-se desenvolver na linguagem de descrição de hardware VHDL um módulo que represente a interoperabilidade do padrão e a tecnologia Bluetooth suportada pelo padrão Introdução Atualmente, os transdutores inteligentes desempenham um papel de importância vital em várias áreas, tais como: indústria, biomédica, aeroespacial, automação residencial. Transdutor é um dispositivo primário de detecção e atuação em determinado processo que possa interagir com o ambiente físico. O termo transdutor inteligente foi introduzido em 1982, por Ko e Fung [Ko e Fung 1982]. Um transdutor inteligente compreende um dispositivo de hardware e software, e pode ser definido como a integração de um sistema que é constituído de um sensor analógico ou digital ou elemento de atuador, um microprocessador, e uma interface de comunicação. Os fabricantes competem por disponibilizar transdutores cada vez mais inteligentes, mais baratos, compatíveis com o maior número de protocolo de rede. Esta progressiva digitalização dos sistemas de medida e controle facilita a instalação, manutenção e expansão do próprio sistema. No entanto, o mercado de transdutores inteligentes passa por um grande problema, o surgimento de diversos protocolos de rede, prejudicando a integração de produtos de diferentes fabricantes e direciona o mercado para soluções proprietárias, frequentemente mais caras e menos flexíveis. 229

234 Nesse contexto, houve a necessidade de criar um padrão de interfaceamento para transdutores inteligentes em ambiente de redes. O IEEE, Instituto de Engenheiros Elétrico e Eletrônicos e o NIST, Instituto Nacional de Padrões e Tecnologia, direcionaram esse assunto de interfaces de transdutores (sensores e atuadores) por meio da definição do padrão IEEE Este padrão tem como objetivo estabelecer uma maneira padronizada de conectar dispositivos transdutores em rede, utilizando diferentes tecnologias e buscando atingir interoperabilidade e plug and play em nível de transdutor. Na figura 3 é apresentada a arquitetura do padrão IEEE Figura 1. Arquitetura do padrão IEEE [Song, Lee, 2008] Atualmente, a família de padrões IEEE 1451 fornece um conjunto comum de protocolos para monitoramento de sistema com e sem fio para controle de aplicações. Um conjunto comum de comandos é definido pela família de padrões, onde é promovido o acesso aos sensores e atuadores interligados em diversas configurações físicas, por exemplo, ponto a ponto e configuração sem fio, e.g. [Song e Lee 2008]. Deste modo, o objetivo deste artigo é apresentar o estudo sobre a interoperabilidade entre sensores inteligentes de redes sem fio em conformidade com os padrões de interfaceamento IEEE e IEEE Esse estudo contribuirá para o desenvolvimento na linguagem de descrição de hardware VHDL de um módulo que 230

235 represente a interoperabilidade do padrão e a tecnologia Bluetooth suportada pelo padrão Além dessa primeira seção, que apresenta o contexto da pesquisa, o artigo está estruturado da seguinte maneira: seção 2 apresenta algumas pesquisas realizadas no contexto do tema abordado, a seção 3 aborda sobre a interoperabilidade entre os padrões IEEE e IEEE e o artigo é concluído na seção Trabalhos Relacionados O padrão IEEE 1451 tem como objetivo definir e descrever um conjunto comum de interfaces de comunicação para conectar transdutores a sistemas microprocessados, de instrumentação e de controle em um ambiente independente de rede de comunicação. Possibilitando o funcionamento contíguo de qualquer transdutor em qualquer rede, beneficiando a qualidade dos transdutores e a diminuição do seu preço [Song and Lee 2008]. Atualmente a IEEE 1451 tem em consideração um conjunto de padrões formado por sete partes que explicam o modelo de um transdutor inteligente e suas interfaces existentes. A tabela 1 exibe o atual estado das normas. Tabela 1 Estado dos padrões IEEE 1451 Padrão Designação Estado Common Functions, Communication Protocols, and Transducer Electronic Data Sheet (TEDS) Formats Ativo Network Capable Application Processor (NCAP) Information Model Ativo Transducer to Microprocessor Communication Protocols and Transducer Electronic Data Sheet (TEDS) Formats Ativo Digital Communication and Transducer Electronic Data Sheet (TEDS) Formats for Distributed Multidrop Systems Ativo Mixed-Mode Communication Protocols and Transducer Electronic Data Sheet (TEDS) Formats Ativo P Wireless Communication Protocols and Transducer Electronic Data Sheets (TEDS) Formats A High-speed CANOpen Based Transducer Network Interface for Intrinsically Safe and non-intrinsically Safe Applications Ativo Proposta P Transducers to Radio Frequency Identification (RFID) Systems Communication Protocols and Transducer Electronic Data Sheet Formats Proposta Um trabalho pioneiro na área de transdutores inteligentes em rede foi feito em 1995, por um grupo da Hewlett Packard HP, que criou o protótipo de um sensor 231

236 inteligente conectado em rede, onde seu objetivo era mostrar os conceitos fundamentais sobre a padronização de interfaces [Eidson e Woods 2005]. A necessidade de um protocolo padrão para a rede de sensores sem fio (WSN) crescia cada vez mais, então foi sugerido o desenvolvimento de um padrão de interfaceamento IEEE para sensores sem fio e para usar a família 802 como uma diretriz para o gerenciamento da família IEEE 1451[Gilsinn e Lee 2001]. Uma abordagem modular para o desenvolvimento do padrão IEEE para sensores sem fio baseado em Bluetooth é discutido em [Sweetser, Sweetser e Nemeth- Johannes 2006]. Uma implementação do IEEE e é apresentado em [Song e Lee 2006]. O estudo de caso [Lee e Song 2007] fornece os fundamentos e algumas diretrizes para a implementação de um aplicativo de monitoramento de sensores sem fio baseados nos padrões IEEE 1451,0 e 1451,5. O artigo [Song e Lee 2008] mostra a descrição de um serviço Web unificado para transdutores inteligentes IEEE 1451, desenvolvido no Instituto Nacional de Padrões e Tecnologia (NIST), baseado no padrão IEEE Esse trabalho foi testado com sucesso, através de estudos de casos, e houve a descrição detalhadamente do estudo de caso completo que trata a leitura de dados do transdutor. 3. Interoperabilidade entre os padrões IEEE e IEEE Os padrões IEEE 1451 apresentam características comuns, mas não obedecem a um padrão comum de funções, endereçamento, comandos, protocolos de comunicação (internos) ou TEDS. A proposta de uma norma para as TEDS inclui a criação de uma nova estrutura que descreve o meio físico utilizado denominada TEDS de camada física (Physical Layer TEDS). O TEDS é uma estrutura de memória que acompanha o transdutor, ou seja, são as especificações do transdutor escrita em formato eletrônico e armazenadas em memória não volátil, contendo dados de calibração, identificação, medição, correção de dados, e de informações pautadas com a fabricação do transdutor. Dos padrões que compõe a norma 1451, os padrões IEEE e o IEEE são os que melhor se relacionam com as características de redes de sensores sem fio, pois o IEEE serve de base para os demais padrões, e o IEEE unifica o uso da transmissão sem fio entre os dispositivos. O padrão IEEE é a norma mais importante da família IEEE 1451, recebendo uma numeração inferior as referidas antes dela, pois a mesma é uma experiência de padronização, ou seja, foi disposta para estimular a compatibilidade entre as normas IEEE 1451, disponibilizando interfaces que ajudem a disseminação de novos modelos IEEE 1451 fundamentados em meios físicos diferentes [IEEE 2007]. O padrão IEEE tem como principal objetivo o desenvolvimento de uma especificação para guiar em ambientes de rede sem fio, as aplicações da norma IEEE 1451[IEEE, 2007]. Pretende-se que a interface sem fios seja aberta, o que torna aceitável a integração das qualidades das diversas tecnologias sem fio (IEEE , BlueTooth, ZigBee), sem restringir a transdução, digitalização e condicionamento de sinal, nem tão pouco no nível físico da interface [IEEE, 2007]. 232

237 O conceito de TIM Módulo de Interface dos Transdutores e de NCAP Processador de Aplicação com Capacidade de operar em Rede foi introduzido pelo IEEE O módulo TIM descreve as funcionalidades do transdutor, a sua interface digital de comunicação com o processador de rede e a sua memória descritiva, conhecida como TEDS. Por sua vez, o módulo NCAP é um nó com capacidade de processamento local, que é "visto" como sendo um ponto de inteligência distribuída, ou seja, denomina o processador e o hardware associado que faz a interface entre o módulo do transdutor e a rede de controle, executando funções de aplicação e conversão de dados além de alimentar o módulo TIM. Além disso, foi definido no padrão as APIs disponíveis entre os diversos grupos de modelos, o conjunto de comandos, a estrutura das mensagens trocadas entre o NCAP e o TIM, os modos de operação e transferência, o formato das TEDS e a forma de acesso a eles, e também, as funções e serviços providos ao NCAP pelo módulo de comunicação. O padrão IEEE foi descrito em conformidade com a norma IEEE , prevendo a definição das TEDS de camada física para as diversas tecnologias mencionadas anteriormente, e escolhidas conforme a expectativa de sua utilização pelo mercado. O grande diferencial da abordagem da IEEE em relação às redes de sensores sem fio tradicionais é a presença do NCAP que permite uma interface transparente entre os transdutores e a rede de controle. Através dele é possível integrar os transdutores sem fio às redes de controle já existentes, agregando as mesmas funcionalidades da tecnologia sem fio sem a necessidade de se redefinir o sistema instalado. E também, o IEEE define o conceito de WTIM (Módulo de interface dos transdutores sem fio), que é um TIM baseado na norma IEEE , mas com a capacidade de comunicação em redes sem fio. Além disso, o padrão mostrar as tecnologias de radiofrequência, Dot5AR, e faz a descrição dos aspectos físicos da interface de comunicação, definido no modulo de comunicação do IEEE Como os padrões IEEE e IEEE estão em conformidade, pretendese promover a interoperabilidade entre os transdutores e as redes sem fio, sem a necessidade de se preocupar com a disponibilidade de transdutores adequados a tal rede. 4. Conclusão Este trabalho apresentou as normas que compõem o padrão IEEE 1451, mais especificamente os padrões IEEE e , além de aplicá-las em rede de sensores sem fio, que é um dos principais temas da área tecnológica. Apesar de ser considerado um padrão bastante complexo, as peculiaridades apresentadas pelos padrões trazem várias vantagens e melhorias quando utilizadas com a rede de sensores sem fio. Portanto, a existência de um conjunto padronizado de estruturas, interfaces e formatos de comunicação, tornou possível manter a interoperabilidade entre os sensores e que o sistema pudesse reconhecer e trabalhar com novos sensores de maneira ágil. As TEDS são uma das principais criações do padrão IEEE 1451, pois facilitou a criação de redes de sensores sem fio, através da capacidade de se auto-descreverem. Logo, a família IEEE 1451 tornou-se uma ótima opção para ser utilizada em conjunto com as redes de sensores sem fio (RSSF). 233

238 A partir do estudo realizado, foi adquirido um conhecimento preliminar do padrão IEEE 1451, o qual será aprofundado por meio do desenvolvimento de um módulo em linguagem de descrição de hardware VHDL para aplicações de redes de sensores sem fio, permitindo a interoperabilidade proposta pelo padrão IEEE e baseada no padrão IEEE Bluetooth. Referências Ko, W. H. e Fung, C. D. (1982), VLSI and intelligent transducers, sensors and actuators, pp Song, E.Y. e Lee, K. (2008), Understanding IEEE1451-networked smart transducer interface standard-what is a smart transducer, p Instrumentation & Measurement Magazine. IEEE standard for a smart transducer interface for sensors and actuators - Common functions, communication protocols, and transducer electronic data sheet (TEDS) formats. New York: IEEE (IEEE Std ). Batista, E. A. (2004), Emprego da tecnologia Java para implementar a parte lógica de um processador de aplicação com capacidade de operar em rede de comunicação (NCAP), em conformidade com o padrão IEEE f. Dissertação (Mestrado em Engenharia Elétrica) - Faculdade de Engenharia de Ilha Solteira, Universidade Estadual Paulista, Ilha Solteira. Edison, J. e Woods, S.P. (2005), A research prototype of a networked smart sensor system. Papers in PDF format, Measurement Systems Department-Instruments and Photonics Laboratory (HP). Disponível em: <www.hpl.hp.com/techreports/95/hpl pdf>. Acesso em: Gilsinn, J.D. e Lee, K. (2001). Wireless interfaces for IEEE 1451 sensor networks. SIcon 01 Sensors for industrial conference, Rosemont, Illinois, USA. Sweetser, D., Sweetser, V. e Nemeth-Johannes, J. (2006), A modular approach to IEEE wireless sensor development, Proceedings of 2006 IEEE Sensors Applications Symposium, p

239 Migração de um Sistema de Dimensionamento de Poços de Bombeio Mecânico para Dispositivos Móveis Matheus A. de Sousa 1, Thais Batista 1, Nélio Cacho 2 1 Departamento de Informática e Matemática Aplicada Universidade Federal do Rio Grande do Norte (UFRN) 2 Escola de Ciência e Tecnologia Universidade Federal do Rio Grande do Norte (UFRN) Abstract. This paper describes the development of an application for mobile devices based on an existing system for desktop platforms. This paper describes some lessons learned to migrate a sucker-rod pumping calculation system for mobile platforms. Resumo. Este artigo descreve o desenvolvimento de uma aplicação para dispositivos móveis baseado em um sistema já existente para plataformas de desktop, mostrando quais as alterações necessárias para migrar um sistema de cálculos de bombeio mecânico para plataformas de dispositivos móveis. 1. Introdução Os aplicativos móveis vêm ganhando espaço nas empresas, desenvolvendo novos produtos ou convertendo aplicações existentes de outras plataformas, obtendo maior competitividade no mercado e apresentando diferencial tecnológico. No contexto da área de petróleo, os benefícios que um aplicativo de dispositivo móvel trazem são essenciais, pois permite que o engenheiro ou técnico de petróleo possa gerenciar equipamentos ou poços de uma determinada área estando próximo ao poço ou equipamento. Dessa forma, vários problemas podem ser evitados ou corrigidos de forma eficaz em tempo hábil de evitar possíveis perdas. Nesse cenário, esse trabalho tem como objetivo desenvolver uma aplicação móvel, o BMMobile, que visa prover ferramentas em dispositivos móveis como celulares, para auxiliar um engenheiro ou técnico de petróleo no gerenciamento de poços que usam bombeio mecânico como método de elevação. Este artigo está estruturado da seguinte forma: A seção seguinte descreve o funcionamento do dimensionamento de bombeio mecânico e mostra a arquitetura do BMMobile; O seção 3 relata a implementação do BMMobile, descrevendo casos de uso, requisitos funcionais e de qualidade, a arquitetura elaborada para suportar as variabilidades para suportar vários tipos de dispositivos móveis, as alterações realizadas para migrar os cálculos para a plataforma de dispositivos móveis; A conclusão e expectativas com o desenvolvimento desse sistema estão descritas na seção Descrição da Ferramenta O sistema de dimensionamento de bombeio mecânico tem por objetivo determinar o conjunto de equipamentos do sistema e o regime de bombeio (curso e cpm, unidade de frequência de bombeamento) necessários ao atendimento da vazão de elevação de 235

240 petróleo. Esta funcionalidade é necessária, pois os equipamentos de elevação de petróleo não devem ser exigidos além do seu limite e um melhor atendimento da vazão do projeto leva a uma melhor extração de petróleo. Por apresentar acesso às informações fornecidas pela internet no dimensionamento de bombeio mecânico, o usuário consulta um poço e realiza o cálculo do dimensionamento de bombeio mecânico tendo como resultado uma serie de configurações possíveis para o gerenciamento de um equipamento. O estilo arquitetural utilizado no sistema é o MVC (Model View Controller), onde cada camada representa uma funcionalidade no sistema. Na camada de modelo encontram-se dados referentes ao modelo da aplicação como coluna haste, bomba de fundo, dentre outros. Na camada de controle encontram-se classes que fazem chamadas aos cálculos de dimensionamento de bombeio mecânico. A camada de visão é encontrada classes contendo interface gráfica de dispositivos móveis. A figura 1b mostra a arquitetura do BMMobile. Infelizmente, o sistema de dimensionamento de bombeio mecânico não pode ser utilizado diretamente em dispositivo móveis, devido as restrições de conexão e processamento. Desta forma, o objetivo deste trabalho foi adaptar as funcionalidades da aplicação que executa na plataforma deskotp para suportar as características de dispositivos com restrições de conexão e processamento. Essas adaptações são detalhadas na seção seguinte. 3. BMMobile O BMMobile é um sistema que tem por objetivo realizar cálculos e exibir uma série de configurações possíveis para o gerenciamento do bombeio mecânico. Esse sistema deve suportar os diversos tipos de dispositivos móveis. Dessa forma o aplicativo utiliza conceito de linhas de produto [Clements and Northrop, 2001] que tem como objetivo atender uma determinada família de sistemas em um determinado segmento de mercado. Além dos cálculos utilizados na plataforma desktop, novas funcionalidades e características foram adicionadas para a plataforma móvel, como: o recebimento e envio de resultados dos cálculos, dessa forma o engenheiro poderá enviar resultados dos cálculos para um outro mais próximo ao poço ou equipamento, realizando o gerenciamento de forma mais rápida. As novas características foram: (i) programação utilizando JME (Java Móbile Edition) [Java ME, 2009], uma vez que os cálculos foram desenvolvidos na linguagem Java; (ii) segurança no envio e recebimento de mensagens, evitando o acesso de terceiros aos resultados dos cálculos; (iii) suportar diversos tipos de dispositivos móveis; (iv) o uso de perfis para determinar que engenheiro ou técnico possa realizar quais cálculos Casos de Uso Os casos de uso são utilizados para mostrar as ações e os atores que as executam. A figura 1a mostra o diagrama de caso de uso do BMMobile. 236

241 Figura 1. a) Casos de uso do sistema; b) Arquitetura do sistema. Os casos de uso exibir resultados dos cálculos, enviar e receber dados para o dimensionamento, armazenamento de resultados de cálculos foram adicionados para suportar funcionalidades adicionais para a plataforma de dispositivos móveis Modelo de Features. O produto gerado do BMMobile deverá atender as características de diversos dispositivos móveis, dessa forma as features desse sistema estão distribuídas da seguinte forma: (i) Capacidade de processamento cada produto gerado deverá corresponder a uma determinada capacidade de tipo especifico de dispositivo; (ii) Comunicação dentre as várias formas de comunicação existentes, redes sem fio, bluetooth, um produto deverá oferecer suporte para o tipo de comunicação de um dispositivo especificado; (iii) Tamanho da tela, (iv) tipo de teclado, (v) suporte a gráfico são características do modelo de cada aparelho, onde um produto deverá atender as especificações de um determinado dispositivo. A figura 2a mostra o modelo de features elaborado. 237

242 Figura 2. A direita o modelo de features e a esquerda a arquitetura elaborada contendo as variabilidades 3.4 Arquitetura Para atender a todos os requisitos e variabilidades elaboradas para a linha de produto BMMobile usando a arquitetura desenvolvida (figura 1b), a figura 2b mostra a arquitetura elaborada com as características para cada tipo de dispositivo móvel. Na figura 2b foram utilizados componentes para representar as variabilidades, usando estereótipos e dependência da UML para representar as dependências e as restrições das variabilidades. 3.5 Implementação da Ferramenta Além de mudanças arquiteturais, a migração requereu também mudanças em nível de código. Apesar de as duas plataformas escolhidas utilizarem a linguagem Java, a plataforma ME do Java [Java ME, 2009] não suporta a maioria das funcionalidades da plataforma SE (Standard Edition) [Java SE, 2009] da mesma linguagem. Dessa forma a migração foi realizada alterando alguns recursos utilizados nos cálculos para serem suportados na plataforma ME. As alterações realizadas nos cálculos são descritas a seguir: 238

243 O Java ME não suporta a classe ArrayList e a interface List, ambas do pacote java.util, utilizados no cálculos. Dessa forma foi necessário substituir essas classes por outra que apresentasse mesma função e fosse suportada por ambas as plataformas. A classe escolhida foi a Vector, do mesmo pacote. A figura 3 mostra o código do cálculo da coluna haste. A figura 3a mostra o código antes e a 3b após a alteração. /* Lista das Secoes de hastes */ private List<SecaoMaster> listasecoes; (a) /* Lista das Secoes de hastes */ private Vector listasecoes; Figura 3. a) mostra o código antes E b) apos a alteração A figura 3a também mostra outra incompatibilidade entre as duas plataformas, o Java ME não aceita o generics [Generics, 2009], funcionalidade criada na versão 1.5 do Java SE, que tem como objetivo definir um tipo especifico para uma coleção de dados. O Java ME não suporta o autoboxing [AutoBoxing, 2009] da versão 1.5 do Java SE, ou seja, ele não reconhece a diferença entre tipo primitivo para tipo wrapper. Dessa forma é necessário utilizar conversões para os tipos primitivos e wrapper. A figura 4a mostra uma conversão de tipo primitivo para wrapper e a figura 4b a conversão inversa dos tipos. private static Double [] diametrospistao = {Double.valueOf(""+1.06), Double.valueOf(""+1.25),Double.valueOf(""+1.50), Double.valueOf(""+1.75),Double.valueOf(""+2.00), Double.valueOf(""+2.25),Double.valueOf(""+2.50), Double.valueOf(""+2.75),Double.valueOf(""+3.25), Double.valueOf(""+3.75), Double.valueOf(""+4.75)}; (a) (b) tensaoruptura= Double.parseDouble(""+graus[i][1]); (b) Figura 4. Conversão de tipos O Java ME não suporta anotações (Anotations) e propriedades (Properties) da plataforma Java SE 1.5, utilizados nos cálculos, porém não adaptações a serem realizadas nesses casos. A solução foi a retirada dos elementos contidos nos códigos. No caso das propriedades as mensagens contidas foram colocadas diretamente no código. Há alguns desafios a serem enfrentados, como a forma de disponibilizar um gráfico ou exibir uma série de dados em uma tela consideravelmente pequena e de diversos tamanhos como os de dispositivos móveis. O BMMobile já realiza o dimensionamento de bombeio mecânico, porém muitos trabalhos ainda estão por ser feitos, como a implementação da linha de produto, pois o aplicativo deverá funcionar para cada tipo de dispositivo móvel especifico e a implementação dos demais cálculos que compõem o sistema. A figura 5 mostra a ferramenta BMMobile mostrando o resultado do dimensionamento de bombeio mecânico. 239

244 Figura 5. Resultado do cálculo de dimensionamento de bombeio mecânico 4. Conclusão O presente trabalho apresentou como foram realizadas as modificações para migrar o dimensionamento de bombeio mecânico, cálculo desenvolvido para uma plataforma de desktop utilizando a linguagem Java, para a plataforma de dispositivos móveis da mesma linguagem. As alterações foram realizadas no nível de código, verificando as similaridades e diferenças entre as duas plataformas e alterando o código dos cálculos para serem suportados pela plataforma de dispositivos móveis. Vários trabalhos ainda deverão ser realizados para o termino da implementação da ferramenta, desde a finalização de todos os cálculos como o desenvolvimento de uma linha de produto para este sistema, de forma a permitir que o mesmo funcione em diversos tipos de aplicativos móveis, não sendo necessária o desenvolvimento separado para cada tipo de dispositivo. Referencias Clements, Northrop. Software Product Lines: Practices and Patterns, Addison- Wesley, K. Czarnecki, Overview of Generative Software Development, Proceedings of Unconventional Programming Paradigms, Mont Saint-Michel, France (2004), pp Czarnecki, K., Helsen, S.: Feature-Based Survey of Model Transformation Approaches, IBM Systems Journal, 45, 3, , Parnas,D.L.(1976).On the design and development of program families. IEEE Trans.Softw.Eng.,2(1):1 9. Java SE. Java SE Overview at a Glance, disponível em: <http://java.sun.com/javase/>, Acesso em <10 de 2009> Java ME. Java ME: the Most Ubiquitous Application Platform for Mobile Devices, disponível em: <http://java.sun.com/javame/index.jsp>, Acesso em <10 de 2009> AutoBoxing. Autoboxing, disponível em: <http://java.sun.com/j2se/1.5.0/docs/guide/language/autoboxing.html>, Acesso em <10 de 2009>. Generics. Generics, disponível em: Acesso em <10 de 2009>. 240

245 Um roteador de baixo consumo baseado na placa BeagleBoard João M. de Araújo 1, Marcus B. de Moura 1 e Moroni N. Vieira 1 1 Faculdade de Excelência Educacional do Rio Grande do Norte (FATERN) Natal RN Brasil Abstract. This paper describes the use of the card BeagleBoard, of low energy consumption and low cost, as a router of a computer network. We use the Debian Linux distribution as operating system and software Iptables to perform routing. We installed the router in a network with three computers for one week and results were quite satisfactory, so that we can consider that the card can be used as a router for small networks, at least. We are doing more tests on a larger network and with other routing software to better analyze the behavior of the router. Resumo. Este trabalho descreve a utilização da placa BeagleBoard, de baixo consumo e baixo custo, como roteador em uma rede de computadores. Utilizamos a distribuição Linux Debian como sistema operacional e o software Iptables para realizar o roteamento. Instalamos o roteador em uma rede com três computadores durante uma semana e os resultados foram bastante satisfatórios, de maneira que podemos considerar que a placa pode ser utilizada como roteador de pequenas redes, pelo menos. Estamos realizando mais testes em uma rede maior e com outros software de roteamento para analisar melhor o comportamento do roteador. 1. Introdução Nos dias atuais, onde o consumo de energia é um fator importante para o dimensionamento e utilização de componentes elétricos, é interessante buscarmos alternativas que apresentem baixo consumo de energia. Um desses componentes, utilizados em redes de computadores, são os roteadores. Os roteadores disponíveis no mercado, por exemplo roteadores Cisco, podem apresentar baixo consumo; porém são dispendiosos. Uma outra alternativa seria a utilização de computadores convencionais com um software de roteamento instalado [Freitas 2002, Vyatta 2009], a desvantagem dessa abordagem é o consumo de energia de um computador convencional. No presente trabalho apresentamos uma alternativa que apresenta baixo consumo de energia e as funcionalidades desejáveis em um roteador. A alternativa consiste na utilização da placa mãe BeagleBoard [BeagleBoard 2009a] recentemente introduzida no mercado e comercializada pela empresa DigiKey. A placa mãe na verdade é um computador completo incluindo um processador OMAP3530 fabricado pela Texas Instruments, com 128 MB de memória RAM e 256 MB de memória Flash. Como uma primeira aproximação, efetuamos a instalação da distribuição Debian, para ser utilizado como sistema base e configuramos o software de roteamento do próprio Linux (IPTables) de maneira a obter um sistema embarcado equivalente a um roteador. 241

246 Esse trabalho está dividido como segue. Na próxima seção apresentamos a placa BeagleBoard e suas principais características juntamente com a instalação do sistema operacional Debian. Na seção 3 mostramos a configuração do roteador propriamente dito, incluindo a recompilação do kernel e a configuração das regras de roteamento. Finalmente, apresentamos nossas conclusões na seção A placa BeagleBoard e a instalação do Linux A placa BeagleBoard é uma placa mãe compacta contendo um processador OMAP3550 da Texas Instruments de 600MHz (Fig. 1), capaz de rodar vários sistemas operacionais, Linux, Android, Windows Embebed, QNX Neutrino [BeagleBoard 2009a]. Essa placa vem sendo utilizada e testada em uma quantidade razoável de projetos [BeagleBoard 2009b] e seu processador é utilizado em netbooks e celulares [Alecrim 2009]. Figura 1. Principais características da BeagleBoard Para o nosso trabalho em particular, foi necessário adquirir alguns componentes adicionais, pois a placa mãe vem apenas com o processador e memórias incluídos. A lista de componentes adicionais é a seguinte: Gabinete Cartão de memória micro SD, para ser utilizado como disco do sistema. Hub Usb com alimentação externa. Duas placas de redes USB. Fonte de 5V para alimentação da placa. O preço de aquisição do conjunto foi relativamente baixo. O conjunto completo, com os componentes adicionais, custou em torno de US$ incluindo taxas de importação e despesas de envio. Considerando o baixo aquecimento de todo o conjunto envolvendo a Beagleboard, um simples gabinete em termoplástico reciclável é suficiente para prover proteção e oferecer um volume de ar interno que supra as necessidades de refrigeração. Utilizamos um gabinete em termoplástico reciclável em sua peça inferior, de cor preta, e termo plástico virgem em sua peça superior, como tampa, de coloração transparente (Fig. 2). Esse recipiente foi projetado originalmente para acomodar pequenas peças metálicas, mas serviu bem ao propósito de abrigar o conjunto. 242

247 EPOCA'09 - Escola Potiguar de Computação e suas Aplicações Em relac a o a fonte de alimentac a o, os requisitos ele tricos para toda a placa sa o da ordem de apenas 2,5 Watts hora, alimentada com uma tensa o de 5 VCC, o que nos da 0,5 A de corrente. Utilizamos uma fonte de alimentac a o chaveada Hayama CHUB 0520, de fabricac a o nacional e estabilizada, oferecendo uma corrente ma xima de 2 A. Essa fonte tem uma tensa o de entrada entre 85VCA e 265VCA, com saı da de 5VCC e e capaz de prover, nominalmente, quatro vezes a corrente necessa ria. Isso e positivo, porque permite a alimentac a o de outros dispositivos ele tricos perife ricos a BeagleBoard, tais como HUBs USB, ou ate mesmo uma placa filha, garantindo, assim, que na o haja diferenc as de potenciais ele tricos. O subsistema de armazenamento externo, baseado em uma interface de carta o SD, SDHC ou MMC, pode apresentar um gargalo de desempenho sobre o pro prio carta o a ser utilizado. Assim, para se utilizar a Beagleboard em qualquer projeto que exija um tra fego minimamente razoa vel de entrada e saı da de dados por esse subsistema, faz-se necessa rio o emprego de um carta o SDHC de pelo menos 180x. Um carta o SDHC de 200x suporta taxas de leitura da ordem de 30 MB/seg, o que embora na o seja compara vel a s velocidades de discos rı gidos convencionais, e um valor bem razoa vel para a Beagleboard. Existem carto es SDHC que sustentam taxas de transfere ncias de 90 MB/seg, em um padra o 600x. Tais carto es utilizam dois canais independentes de entrada e saı da de dados. Uma outra opc a o e a utilizac a o de pendrives velozes. Estes sa o menos dispendiosos e de fa cil aquisic a o. Figura 2. Placa BeagleBoard montada em um gabinete pla stico Apo s a montagem da placa ma e em um gabinete adequado, efetuamos a instalac a o do sistema operacional Debian seguindo as instruc o es detalhadas na pa gina WEB A instalac a o do sistema foi em modo texto via a interface serial disponı vel na placa, como iremos utilizar a placa como um servidor na o houve necessidade de utilizarmos a interface gra fica disponı vel. A instalac a o ocorreu sem maiores problemas e algum tempo depois esta vamos com o sistema operacional instalado e configurado. O pro ximo passo foi a configurac a o do sistema como um roteador propriamente dito, que descrevemos na pro xima sec a o. 3. Configurac a o do Kernel Linux e das regras de roteamento O kernel instalado com o sistema operacional na sec a o anterior na o foi compilado com a opc a o de roteamento. De maneira que foi necessa rio efetuarmos uma recompilac a o 243

248 do kernel para permitir que a placa opere roteando pacotes. Existem várias maneiras de recompilarmos o kernel para o processador OMAP, inclusive utilizando um PC, onde faríamos a chamada compilação cruzada (CROSS_COMPILE). Ou seja, compilamos o kernel em uma arquitetura (x86) mas o resultado compilado seria para outra arquitetura (arm). Porém, optamos por fazer a compilação na própria placa BeagleBoard, seguindo as instruções da página WEB Kernel Build. Abaixo segue um resumo do procedimento adotado. Os comandos, linhas precedidas por #, foram executados como usuário root na BeagleBoard, a partir do diretório /root. 1. Instalação dos pacotes e compiladores necessários para download e compilação do kernel # apt-get install git-core gcc wget kernel-package fakeroot build-essential \ libncurses5-dev 2. Download do kernel com o gerenciador de versões git [Hamano et al. 2009] # git-clone git://git2.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap-2.6.git # cd linux-omap-2.6/ # git checkout 58cf2f1 -b v cf2f1 # git archive --format=tar --prefix=v cf2f1/ v cf2f1 \ gzip >../v cf2f1.tar.gz # git checkout master # git branch v cf2f1 -D # cd.. 3. Cópia e aplicação de um patch necessário # wget # wget 4. Extração e aplicação do patch # tar -xf v cf2f1.tar.gz # cd v cf2f1/ # patch -p1 <../v cf2f1-oer44.1.diff 5. Configuração do kernel # cp../defconfig.config # make menuconfig 6. Compilação do kernel e módulos # make CROSS_COMPILE= uimage # make CROSS_COMPILE= modules # make CROSS_COMPILE= modules_install O primeiro dos comandos no item 5 acima permite que iniciemos a configuração do kernel a partir de uma configuração básica apropriada para a placa BeagleBoard, de outra maneira teríamos que configurar todas as opções do kernel, que são muitas e poderia nos levar a erros. O segundo comando do item 5 abre um menu com as opções de configuração do kernel. A opção que ativamos foi a de roteamento, o que equivale a alterar a linha CONFIG_IP_ADVANCED_ROUTER no arquivo.config, deixando-a da seguinte maneira: CONFIG_IP_ADVANCED_ROUTER=y A compilação do kernel e módulos na placa levou um tempo razoável, cerca de 3 horas, mas funcionou bem já na primeira tentativa. Após a compilação do kernel, basta copiar o arquivo /root/v cf2f1/arch/arm/boot/uimage para a partição do cartão de memória onde está instalado o kernel, no nosso caso a primeira partição. Após a cópia e um reboot, temos a versão do kernel executando na placa e com suporte ao IPTables (Fig. 3). 244

249 bb: # uname -a Linux bb #1 PREEMPT Sat Oct 10 11:02:30 BRT 2009 armv7l GNU/Linux Figura 3. Comando uname -a, após a recompilação do kernel #!/bin/bash # variaveis que definem as placas de redes ifinternet="eth1" # placa de rede para a internet iflocal="eth0" # placa de rede para a rede interna iniciar(){ # Ativa o compartilhamento e o roteamento modprobe iptable_nat echo 1 > /proc/sys/net/ipv4/ip_forward iptables -t nat -A POSTROUTING -o $ifinternet -j MASQUERADE # os dois comandos seguintes protegem contra IP spoofing echo 1 > /proc/sys/net/ipv4/conf/default/rp_filter iptables -A INPUT -m state --state INVALID -j DROP } parar(){ iptables -F iptables -F -t nat } case "$1" in "start") iniciar ;; "stop") parar ;; "restart") parar; iniciar ;; *) echo "Utilize os parametros start ou stop" esac Figura 4. Script para compartilhamento da conexão e ativação do NAT 245

250 Com o kernel habilitado para o iptables, podemos utilizar os procedimentos comuns para roteamento de pacotes com o Linux. Nos testes iniciais, configuramos o roteador de maneira a compartilhar a internet em uma pequena rede com 3 computadores clientes. A configuração para essa situação é bastante simples, pois estamos fazendo apenas o roteamento com o NAT, para isso, criamos um script que é executado na inicialização do sistema(fig. 4). Os testes mostraram-se bastantes satisfatórios, o sistema funcionou sem interrrupções durante uma semana e as máquinas clientes acessaram a rede externa normalmente, sem problemas. Nosso objetivo agora é testar o comportamento da placa em uma rede maior e implementar algum sistema de roteamento com mais recursos como o Vyatta [Vyatta 2009], esta parte do trabalho está em andamento e pretendemos concluí-lo em breve. 4. Conclusões Neste trabalho trabalho apresentamos um roteador baseado na placa BeagleBoard e no sistema operacional Linux. A instalação e configuração dos softwares necessários são relativamente simples e conseguimos obter um roteador com baixíssmo consumo. O que é um resultado importante, uma vez que a economia de energia é um fator determinante para seleção de dispositivos elétricos. Além do baixo consumo, ainda temos bastante flexibilidade em termos de roteamento uma vez que estamos utilizando o Linux e existe uma ampla gama de softwares disponíveis. Pretendemos continuar a investigar esse tema e testar o funcionamento da placa em uma rede maior, além de instalar um software de roteamento com mais recursos como o Vyatta [Vyatta 2009], a instalação e configuração estão em andamento e esperamos concluí-las em breve. Referências Alecrim, F. (2009). Beagleboard - hello linux kernel world. franciscoalecrim.com/down/fisl/beagle-devel.pdf. Palestra apresentada no 10 o Fórum Internacional de Software Livre. BeagleBoard (2009a). BeagleBoard (2009b). Freitas, A. E. S. (2002). linux.html. Hamano, J. C. et al. (2009). Vyatta (2009). Website. 246

251 TV-Turismo: Uma Aplicação Turística para TV Digital utilizando Ginga-NCL Aparecida L. de Medeiros¹, Mariana R. S. dos Santos¹, Neuma M. M. Florêncio¹, Sarah R. da Rocha Silva ¹, Aquiles M.F. Burlamaqui 2 ¹ Universidade do Estado do Rio Grande do Norte (UERN) Santa Cruz RN Brazil ² Laboratório NatalNet Universidade Federal do Rio Grande do Norte (UFRN) Natal RN Brazil {aparecida-lm, marianaregina_soares, Abstract. This article describes possible uses of the infrastructure that Interactive Digital TV gives us for the dissemination of tourist information sites organized in the form of an interactive program to run on television sets and mobile receivers (cell phones, pdas, etc.). Once implemented, such a program, called TV-tourism can be accessed by tourists on their phones and any viewer through their televisions, using it to listen to broadcast from local stations. Resumo. Este artigo descreve possíveis utilizações da infra-estrutura que a TV Digital Interativa nos proporciona para a divulgação de informações turísticas locais organizadas no formato de um programa interativo a serem executados em televisores e receptores móveis (celulares, pdas, etc). Uma vez implementado, tal programa, chamado TV-Turismo, poderá ser acessado por turistas através de seus celulares e por todo e qualquer telespectador através de seus televisores, utilizando para isso o canal de broadcast das emissoras locais. 1. Introdução A Televisão Digital Interativa (TVDI) gratuita está cada vez mais próxima da nossa realidade. Com a implantação do Sistema Brasileiro de TV Digital (SBTVD), além de assistir a programação de TV, o telespectador poderá interagir, em tempo real, com os mais diversos serviços e aplicações. Muito se tem falado deste tema, porém poucos tratam da interatividade e usabilidade dessa nova mídia. O aparelho mais presente na rotina dos brasileiros tem sido um vínculo de oportunidades para atender as necessidades de seus usuários. Por isso sua presença é constante no meio da sociedade, abrangendo diversas áreas de seu cotidiano, quer seja no meio educativo, comunicativo informativo e até mesmo cultural. Contudo podemos destacar a TVDI como potencializadora de aprendizado. A TV Digital permite um passo além: proporciona uma experiência intensa, com 247

252 possibilidade de se aproximar, tirar dúvidas, olhar novamente, receber explicação de outro espectador, tudo proporcionado dos seus recursos interativos, fazendo assim a real diferença entre a TV Digital e a analógica. Através desses recursos interativos foram idealizadas as aplicações que trazem um pouco do teor computacional proporcionado por um computador. Nessa linha de pensamentos desenvolvemos uma aplicação que irá auxiliar o telespectador no seu cotidiano uma vez que as aplicações vêm pra somar essa interatividade. Nos canais de TV Digital paga (Sky, Cabo, etc) encontramos uma grande diversidade de canais, onde muitos deles são temáticos, onde 100% da programação são preenchidas com um único tipo de programa. Alguns desses temas incluem: desenhos animados, noticiários, vendas e filmes. Outro tema existente são os canais com informações turísticas, neles são apresentadas informações sobre a gastronomia, história, pontos turísticos e costumes da população local de diversos locais ao redor do mundo. Graças ao SBTVD, esses programas turísticos poderão ser explorados de novas maneiras, fazendo assim com que se tenha mais conhecimento sobre todas as regiões turísticas que o Brasil em sua extensão tem para mostrar. Visando aproveitar e divulgar o grande potencial turístico do Rio Grande do Norte, procuramos desenvolver uma aplicação que explore o potencial cultural que a TV Digital nos oferece através da interação imediata com o conteúdo, utilizando a linguagem NCL. Demos o nome a essa aplicação de TV-Turismo. 2. TV-Turismo O projeto é o de desenvolvimento de serviços interativos para a TV digital centrado em cidades e/ou monumentos históricos do Brasil que têm como eixo uma pedagogia de mostrar as pessoas o que Brasil tem de melhor. A TV-Turismo consiste em facilitar a interatividade e conhecimento, de maneira que faça com que o telespectador se familiarize com a mídia quanto aos aspectos culturais existentes no nosso país. Motivando assim a sociedade a explorar as riquezas culturais, possibilitando ainda que o telespectador/usuário viaje pelo Brasil e porque não dizer pelo mundo sem sair da sua poltrona. Em seu desenvolvimento, inicialmente foi utilizada apenas a linguagem declarativa NCL para construção dessa aplicação, uma linguagem de programação declarativa baseada em XML, projetada para suprir todas as funcionalidades necessárias à implementação de aplicativos na TV Digital. Para validação do nosso programa utilizamos a cidade de Santa Cruz, localizada no agreste do Rio Grande do Norte. A aplicações consiste em programa interativo com informações sobre a história, gastronomia, lazer e lugares onde ir na cidade, ver figura

253 A imagem de Santa Rita de Cássia vem sendo erguida a algum tempo na cidade de Santa Cruz (RN), a 111 km da Capital do RN. A estátua vem sendo observada como sendo a maior estátua católica do mundo. Para se ter uma idéia, a estátua do Cristo Redentor, no Rio de Janeiro (RJ), mede 38 m de altura e a estátua de Santa Cruz (RN), vem com uma medida de altura de 42 m. Figura 1 - Screenshot do programa TV Turismo (Santa Cruz-RN) Na figura acima temos um menu de informações relacionados ao contexto turístico dessa cidade.observe que a opção história esta selecionada, e ao escolher esta opção o usuário terá um breve histórico do turismo religioso desta cidade. Esse menu além da História é composto pela gastronomia (Opção que mostra os melhores pratos e as comidas típicas desta localidade). Lazer (Descreve o que a cidade tem de atrativo e lazer). Onde ir (Expõe os vários pontos de visita/cartão postal). Além da versão para receptores fixos, o TV-Turismo também foi pensado para ser utilizado em dispositivos móveis. Esses dispositivos podem ser celulares, PDAs, Net Books entre outros. O uso desses dispositivos permite que os telespectadores possam estar em movimento enquanto assiste a um programa. Dentro desse cenário, o TV- Turismo possibilitará que turistas que estejam se locomovendo pela cidade de aproveitarem para receberem informações atualizadas sobre os pontos turísticos daquela localidade, ver Figura

Aplicação de arquitetura orientada a serviços na modelagem de um sistema de monitoramento de ovinos e bovinos confinados

Aplicação de arquitetura orientada a serviços na modelagem de um sistema de monitoramento de ovinos e bovinos confinados Aplicação de arquitetura orientada a serviços na modelagem de um sistema de monitoramento de ovinos e bovinos confinados Juciara Nepomuceno de Souza, Kleber Padovani de Souza, Leonardo Souza Silva 1 Universidade

Leia mais

ConBus: Uma Plataforma de Middleware de Integração de Sensores para o Desenvolvimento de Aplicações Móveis Sensíveis ao Contexto

ConBus: Uma Plataforma de Middleware de Integração de Sensores para o Desenvolvimento de Aplicações Móveis Sensíveis ao Contexto UNIVERSIDADE FEDERAL DE GOIÁS INSTITUTO DE INFORMÁTICA MARCIO PEREIRA DE SÁ ConBus: Uma Plataforma de Middleware de Integração de Sensores para o Desenvolvimento de Aplicações Móveis Sensíveis ao Contexto

Leia mais

APLICAÇÕES PARA CASAS INTELIGENTES EM AMBIENTES PERVASIVOS

APLICAÇÕES PARA CASAS INTELIGENTES EM AMBIENTES PERVASIVOS APLICAÇÕES PARA CASAS INTELIGENTES EM AMBIENTES PERVASIVOS RESUMO Alessandro Lumertz Garcia 1 Anderson Yanzer Cabral 2 Este artigo apresenta tipos de aplicações que podem existir nas casas inteligentes,

Leia mais

For-All - Uma Plataforma para Sistemas Pervasivos Orientados a Serviço

For-All - Uma Plataforma para Sistemas Pervasivos Orientados a Serviço For-All - Uma Plataforma para Sistemas Pervasivos Orientados a Serviço Elenilson Vieira da S. Filho 1, Ângelo L. Vidal de Negreiros 1, Alisson V. Brito 2 1 Departamento de Informática Universidade Federal

Leia mais

Integração da Informação e do Conhecimento no Contexto da Copa do Mundo e os Jogos Olímpicos no Brasil

Integração da Informação e do Conhecimento no Contexto da Copa do Mundo e os Jogos Olímpicos no Brasil Integração da Informação e do Conhecimento no Contexto da Copa do Mundo e os Jogos Olímpicos no Brasil Ivan Guilherme 1, Jonas Queiroz 1, Caio Marques 2 1 Universidade Estadual Paulista, IGCE, DEMAC, Caixa

Leia mais

3 Trabalhos Relacionados

3 Trabalhos Relacionados 35 3 Trabalhos Relacionados Alguns trabalhos se relacionam com o aqui proposto sob duas visões, uma sobre a visão de implementação e arquitetura, com a utilização de informações de contexto em SMA, outra

Leia mais

Uma Ontologia para Gestão de Segurança da Informação

Uma Ontologia para Gestão de Segurança da Informação Uma Ontologia para Gestão de Segurança da Informação Paulo Fernando da Silva, Henrique Otte, José Leomar Todesco, Fernando A. O. Gauthier Programa de Pós-Graduação em Engenharia e Gestão do Conhecimento

Leia mais

Computação Sensível ao Contexto

Computação Sensível ao Contexto Computação Sensível ao Contexto Percepção de Contexto em Ambientes Domiciliares Modelagem de Contexto Modelagem de Contexto + Modelagem de Usuário Fabrício J. Barth novembro de 2004 Sumário O que já foi

Leia mais

MAPEAMENTO E LOCALIZAÇÃO DE REGIÕES DE INTERESSE UTILIZANDO REALIDADE AUMENTADA EM DISPOSITIVOS MÓVEIS COM PLATAFORMA ANDROID

MAPEAMENTO E LOCALIZAÇÃO DE REGIÕES DE INTERESSE UTILIZANDO REALIDADE AUMENTADA EM DISPOSITIVOS MÓVEIS COM PLATAFORMA ANDROID MAPEAMENTO E LOCALIZAÇÃO DE REGIÕES DE INTERESSE UTILIZANDO REALIDADE AUMENTADA EM DISPOSITIVOS MÓVEIS COM PLATAFORMA ANDROID Alessandro Teixeira de Andrade¹; Geazy Menezes² UFGD/FACET Caixa Postal 533,

Leia mais

Aplicação de um Metamodelo de Contexto a uma Tarefa de Investigação Policial

Aplicação de um Metamodelo de Contexto a uma Tarefa de Investigação Policial Aplicação de um Metamodelo de Contexto a uma Tarefa de Investigação Policial Lucas A. de Oliveira, Rui A. R. B. Figueira, Expedito C. Lopes Mestrado em Sistemas e Computação Universidade de Salvador (UNIFACS)

Leia mais

Service Oriented Architecture (SOA)

Service Oriented Architecture (SOA) São Paulo, 2011 Universidade Paulista (UNIP) Service Oriented Architecture (SOA) Prof. MSc. Vladimir Camelo vladimir.professor@gmail.com 04/09/11 vladimir.professor@gmail.com 1 04/09/11 vladimir.professor@gmail.com

Leia mais

Musert: Um Museu Virtual em 3D com Recomendação Personalizada de Conteúdo

Musert: Um Museu Virtual em 3D com Recomendação Personalizada de Conteúdo Musert: Um Museu Virtual em 3D com Recomendação Personalizada de Conteúdo Íthalo Bruno Grigório de Moura 1,2, João de Deus Lima 1, Francisco Milton Mendes Neto 1,2, Paulo Sérgio Sousa Maia 2 1 Programa

Leia mais

Faculdade de Tecnologia Senac RS (FATEC/RS) Porto Alegre RS Brasil. {fdalosto, hunderc, Smayres}@gmail.com

Faculdade de Tecnologia Senac RS (FATEC/RS) Porto Alegre RS Brasil. {fdalosto, hunderc, Smayres}@gmail.com Validação de modelo para registro de freqüência utilizando computação pervasiva e tecnologia RFID Camila San Martin Ayres, Fábio Dal Osto, Hunder Everton Correa Jr. Faculdade de Tecnologia Senac RS (FATEC/RS)

Leia mais

DESENVOLVENDO APLICAÇÃO UTILIZANDO JAVA SERVER FACES

DESENVOLVENDO APLICAÇÃO UTILIZANDO JAVA SERVER FACES DESENVOLVENDO APLICAÇÃO UTILIZANDO JAVA SERVER FACES Alexandre Egleilton Araújo, Jaime Willian Dias Universidade Paranaense (Unipar) Paranavaí PR Brasil araujo.ale01@gmail.com, jaime@unipar.br Resumo.

Leia mais

Gerenciamento de Redes

Gerenciamento de Redes Gerenciamento de Redes As redes de computadores atuais são compostas por uma grande variedade de dispositivos que devem se comunicar e compartilhar recursos. Na maioria dos casos, a eficiência dos serviços

Leia mais

SOA: Service-oriented architecture

SOA: Service-oriented architecture SOA: Service-oriented architecture Roteiro Breve História O que é Arquitetura de Software? O que é SOA? Serviços Infraestrutura Composição Sua empresa está preparada para SOA? Breve História Uma empresa

Leia mais

MedEl: Uma solução de E-Learning utilizando tecnologia Microsoft ASP.NET

MedEl: Uma solução de E-Learning utilizando tecnologia Microsoft ASP.NET MedEl: Uma solução de E-Learning utilizando tecnologia Microsoft ASP.NET Átila Correia Cunha 1, 2, Glaucon Henrique Mauricio Maia 1, 2, Waner Ferreira Tavares 1, 2, Jorge Bergson¹, Rui Gomes Patrício 3

Leia mais

Sistemas Distribuídos

Sistemas Distribuídos Sistemas Distribuídos Computação Aula 01-02: Introdução 2o. Semestre / 2014 Prof. Jesus Agenda da Apresentação Definição e surgimento de Sistemas Distribuídos Principais aspectos de Sistemas Distribuídos

Leia mais

Localização, Mapas e Contexto: Um Framework para Desenvolvimento de Aplicações baseadas em Mapas Contextuais

Localização, Mapas e Contexto: Um Framework para Desenvolvimento de Aplicações baseadas em Mapas Contextuais Localização, Mapas e Contexto: Um Framework para Desenvolvimento de Aplicações baseadas em Mapas Contextuais Heitor Menezes de O. Pereira 1, Ricardo C. Antunes da Rocha 1 1 Instituto de Informática Universidade

Leia mais

ARQUITETURA DE SISTEMAS. Cleviton Monteiro (cleviton@gmail.com)

ARQUITETURA DE SISTEMAS. Cleviton Monteiro (cleviton@gmail.com) ARQUITETURA DE SISTEMAS Cleviton Monteiro (cleviton@gmail.com) Roteiro Definição Documento de arquitetura Modelos de representação da arquitetura Estilos arquiteturais Arquitetura de sistemas web Arquitetura

Leia mais

Tipos de Sistemas Distribuídos

Tipos de Sistemas Distribuídos (Sistemas de Informação Distribuída e Pervasivos) Sistemas Distribuídos Mauro Lopes Carvalho Silva Professor EBTT DAI Departamento de Informática Campus Monte Castelo Instituto Federal de Educação Ciência

Leia mais

5 Framework para coordenação e mediação de Web Services para ambientes de aprendizado à distância

5 Framework para coordenação e mediação de Web Services para ambientes de aprendizado à distância 5 Framework para coordenação e mediação de Web Services para ambientes de aprendizado à distância O capítulo anterior apresentou uma discussão sobre a inclusão dos chamados learning services no processo

Leia mais

Conteúdo. Disciplina: INF 02810 Engenharia de Software. Monalessa Perini Barcellos. Centro Tecnológico. Universidade Federal do Espírito Santo

Conteúdo. Disciplina: INF 02810 Engenharia de Software. Monalessa Perini Barcellos. Centro Tecnológico. Universidade Federal do Espírito Santo Universidade Federal do Espírito Santo Centro Tecnológico Departamento de Informática Disciplina: INF 02810 Prof.: (monalessa@inf.ufes.br) Conteúdo 1. Introdução 2. Processo de Software 3. Gerência de

Leia mais

Introdução. Definição de um Sistema Distribuído (1) Definição de um Sistema Distribuído(2) Metas de Sistemas Distribuídos (2)

Introdução. Definição de um Sistema Distribuído (1) Definição de um Sistema Distribuído(2) Metas de Sistemas Distribuídos (2) Definição de um Sistema Distribuído (1) Introdução Um sistema distribuído é: Uma coleção de computadores independentes que aparecem para o usuário como um único sistema coerente. Definição de um Sistema

Leia mais

Um Framework para Carregamento Dinâmico e Transição Suave entre Mapas Contextuais

Um Framework para Carregamento Dinâmico e Transição Suave entre Mapas Contextuais Um Framework para Carregamento Dinâmico e Transição Suave entre Mapas Contextuais Danilo Inácio de Souza Resende, Heitor Menezes de O. Pereira, Ricardo C. Antunes da Rocha 1 Instituto de Informática Universidade

Leia mais

7 Utilização do Mobile Social Gateway

7 Utilização do Mobile Social Gateway 7 Utilização do Mobile Social Gateway Existem três atores envolvidos na arquitetura do Mobile Social Gateway: desenvolvedor do framework MoSoGw: é o responsável pelo desenvolvimento de novas features,

Leia mais

PROJETO DE REDES www.projetoderedes.com.br

PROJETO DE REDES www.projetoderedes.com.br PROJETO DE REDES www.projetoderedes.com.br Centro Universitário de Volta Redonda - UniFOA Curso Tecnológico de Redes de Computadores 5º período Disciplina: Tecnologia WEB Professor: José Maurício S. Pinheiro

Leia mais

acoplamento Exprime o grau de conexão entre os módulos; os módulos de um software devemapresentar um baixo coeficiente de acoplamento.

acoplamento Exprime o grau de conexão entre os módulos; os módulos de um software devemapresentar um baixo coeficiente de acoplamento. SOA Arquitetura Orientada a Serviços Conceitos e Aplicações Prof. MSc. Edilberto Silva edilms@yahoo.com/ http://edilms.eti.br Gestão de TI Conceitode SOA SOA - Service OrientedArchitecture (Arquitetura

Leia mais

Metas de um Sistema Distribuído

Metas de um Sistema Distribuído Metas de um Sistema Distribuído Sistemas Distribuídos Mauro Lopes Carvalho Silva Professor EBTT DAI Departamento de Informática Campus Monte Castelo Instituto Federal de Educação Ciência e Tecnologia do

Leia mais

Comparativo entre Projetos de Infraestrutura Computacional Pervasiva para Ambientes Clínicos

Comparativo entre Projetos de Infraestrutura Computacional Pervasiva para Ambientes Clínicos Comparativo entre Projetos de Infraestrutura Computacional Pervasiva para Ambientes Clínicos Marcelo Lopes Kroth 1, Iara Augustin 2 1, 2 Grupo de Sistemas de Computação Móvel (GMob), Universidade Federal

Leia mais

Desenvolvendo uma Arquitetura de Componentes Orientada a Serviço SCA

Desenvolvendo uma Arquitetura de Componentes Orientada a Serviço SCA Desenvolvendo uma Arquitetura de Componentes Orientada a Serviço SCA RESUMO Ricardo Della Libera Marzochi A introdução ao Service Component Architecture (SCA) diz respeito ao estudo dos principais fundamentos

Leia mais

Prof. Marcelo de Sá Barbosa SISTEMAS DISTRIBUIDOS

Prof. Marcelo de Sá Barbosa SISTEMAS DISTRIBUIDOS Prof. Marcelo de Sá Barbosa SISTEMAS DISTRIBUIDOS Objetos distribuídos e invocação remota Introdução Comunicação entre objetos distribuídos Chamada de procedimento remoto Eventos e notificações Objetos

Leia mais

Desenvolvendo e Integrando Serviços Multiplataforma de TV Digital Interativa

Desenvolvendo e Integrando Serviços Multiplataforma de TV Digital Interativa Desenvolvendo e Integrando Serviços Multiplataforma de TV Digital Interativa Agenda Introdução Aplicações interativas de TV Digital Desafios de layout e usabilidade Laboratório de usabilidade Desafios

Leia mais

3 Um Framework Orientado a Aspectos para Monitoramento e Análise de Processos de Negócio

3 Um Framework Orientado a Aspectos para Monitoramento e Análise de Processos de Negócio 32 3 Um Framework Orientado a Aspectos para Monitoramento e Análise de Processos de Negócio Este capítulo apresenta o framework orientado a aspectos para monitoramento e análise de processos de negócio

Leia mais

Modelos e Arquiteturas de Sistemas Computacionais

Modelos e Arquiteturas de Sistemas Computacionais Modelos e Arquiteturas de Sistemas Computacionais Prof. Ricardo J. Rabelo UFSC Universidade Federal de Santa Catarina DAS Departamento de Automação e Sistemas SUMÁRIO Importância da definição da Arquitetura

Leia mais

Processos (Threads,Virtualização e Migração de Código)

Processos (Threads,Virtualização e Migração de Código) Processos (Threads,Virtualização e Migração de Código) Roteiro Processos Threads Virtualização Migração de Código O que é um processo?! Processos são programas em execução. Processo Processo Processo tem

Leia mais

FACULDADE DE ADMINISTRAÇÃO E NEGÓCIOS DE SERGIPE - FANESE CURSO SUPERIOR DE TECNOLOGIA em Gestão da Tecnologia da Informação

FACULDADE DE ADMINISTRAÇÃO E NEGÓCIOS DE SERGIPE - FANESE CURSO SUPERIOR DE TECNOLOGIA em Gestão da Tecnologia da Informação FACULDADE DE ADMINISTRAÇÃO E NEGÓCIOS DE SERGIPE - FANESE CURSO SUPERIOR DE TECNOLOGIA em Gestão da Tecnologia da Informação 1 Ruironaldi dos Santos Cruz ARTIGO ARQUITETURA ORIENTADA A SERVIÇO SOA SERVICE

Leia mais

Sistemas Distribuídos. Introdução

Sistemas Distribuídos. Introdução Sistemas Distribuídos Introdução Definição Processos Um sistema distribuído é um conjunto de computadores independentes, interligados por uma rede de conexão, executando um software distribuído. Executados

Leia mais

Figura 1 - Arquitetura multi-camadas do SIE

Figura 1 - Arquitetura multi-camadas do SIE Um estudo sobre os aspectos de desenvolvimento e distribuição do SIE Fernando Pires Barbosa¹, Equipe Técnica do SIE¹ ¹Centro de Processamento de Dados, Universidade Federal de Santa Maria fernando.barbosa@cpd.ufsm.br

Leia mais

Estudo comparativo entre tecnologias Java: Applet e JWS.

Estudo comparativo entre tecnologias Java: Applet e JWS. Estudo comparativo entre tecnologias Java: Applet e JWS. Clara Aben-Athar B. Fernandes¹, Carlos Alberto P. Araújo¹ 1 Centro Universitário Luterano de Santarém Comunidade Evangélica Luterana (CEULS/ULBRA)

Leia mais

3 Serviços na Web (Web services)

3 Serviços na Web (Web services) 3 Serviços na Web (Web services) 3.1. Visão Geral Com base na definição do Word Wide Web Consortium (W3C), web services são aplicações autocontidas, que possuem interface baseadas em XML e que descrevem

Leia mais

O que é o Virto ERP? Onde sua empresa quer chegar? Apresentação. Modelo de funcionamento

O que é o Virto ERP? Onde sua empresa quer chegar? Apresentação. Modelo de funcionamento HOME O QUE É TOUR MÓDULOS POR QUE SOMOS DIFERENTES METODOLOGIA CLIENTES DÚVIDAS PREÇOS FALE CONOSCO Suporte Sou Cliente Onde sua empresa quer chegar? Sistemas de gestão precisam ajudar sua empresa a atingir

Leia mais

8 Bibliografia. ACEAUME, E. et al. On The Formal Specification of Group Membership Services. INRIA, 1995, 15 p. Relatório Técnico TR95-1534.

8 Bibliografia. ACEAUME, E. et al. On The Formal Specification of Group Membership Services. INRIA, 1995, 15 p. Relatório Técnico TR95-1534. Bibliografia 88 8 Bibliografia ACEAUME, E. et al. On The Formal Specification of Group Membership Services. INRIA, 1995, 15 p. Relatório Técnico TR95-1534. AMBRIOLA, V.; TORTORA, G. Advances in Software

Leia mais

Uma Ontologia Genérica para a Análise de Domínio e Usuário na Engenharia de Domínio Multiagente

Uma Ontologia Genérica para a Análise de Domínio e Usuário na Engenharia de Domínio Multiagente Uma Ontologia Genérica para a Análise de Domínio e Usuário na Engenharia de Domínio Multiagente Carla Gomes de Faria1, Ismênia Ribeiro de Oliveira1, Rosario Girardi1 1Universidade Federal do Maranhão (UFMA)

Leia mais

Framework de comunicação para Webservices 2P2

Framework de comunicação para Webservices 2P2 Universidade Federal de Ouro Preto - UFOP Instituto de Ciências Exatas e Biológicas - ICEB Departamento de Computação - DECOM Framework de comunicação para Webservices 2P2 Aluno: Brayan Vilela Alves Neves

Leia mais

INFRAESTRUTURA PARA INOVAÇÃO BPM e SOA

INFRAESTRUTURA PARA INOVAÇÃO BPM e SOA INFRAESTRUTURA PARA INOVAÇÃO BPM e SOA Palestrante: Eduardo José Ribeiro de Castro, MSc. eduardo@quaddract.com.br 25/08/2009 1 Objetivo Geral APL Brasília Capital Digital Desenvolver entre as empresas

Leia mais

1 http://www.google.com

1 http://www.google.com 1 Introdução A computação em grade se caracteriza pelo uso de recursos computacionais distribuídos em várias redes. Os diversos nós contribuem com capacidade de processamento, armazenamento de dados ou

Leia mais

4 Trabalhos Relacionados

4 Trabalhos Relacionados 4 Trabalhos Relacionados Os trabalhos apresentados nesta seção são os que buscam de alguma forma resolver as questões levantadas nos capítulos 1 e 2 e possuem alguma semelhança entre si. Eles serão comparados

Leia mais

Aplicação de Métodos baseado em Processos de Negócio para Desenvolvimento de Serviços

Aplicação de Métodos baseado em Processos de Negócio para Desenvolvimento de Serviços Aplicação de Métodos baseado em Processos de Negócio para Desenvolvimento de Serviços Luan Lima 1, Ricardo Diniz Sul 1,2, Leonardo Guerreiro Azevedo 1,2,3 1 Departamento de Informática Aplicada (DIA) Universidade

Leia mais

UNIVERSIDADE FEDERAL DE SANTA CATARINA CURSO DE GRADUAÇÃO EM SISTEMAS DE INFORMAÇÃO. Contribuições do MDA para o desenvolvimento de software

UNIVERSIDADE FEDERAL DE SANTA CATARINA CURSO DE GRADUAÇÃO EM SISTEMAS DE INFORMAÇÃO. Contribuições do MDA para o desenvolvimento de software UNIVERSIDADE FEDERAL DE SANTA CATARINA CURSO DE GRADUAÇÃO EM SISTEMAS DE INFORMAÇÃO Contribuições do MDA para o desenvolvimento de software Anna Carla Mohr Verner Helder Eugenio dos Santos Puia Florianópolis,

Leia mais

Projeto de Sistemas Distribuídos. Prof. Andrêza Leite andreza.lba@gmail.com

Projeto de Sistemas Distribuídos. Prof. Andrêza Leite andreza.lba@gmail.com Projeto de Sistemas Distribuídos Prof. Andrêza Leite andreza.lba@gmail.com Agenda Introdução Exemplos de Sistemas Distribuídos Compartilhamento de Recursos e a Web Principais Desafios para a Implementação

Leia mais

Ferramentas Web para controle e supervisão: o que está por vir

Ferramentas Web para controle e supervisão: o que está por vir Artigos Técnicos Ferramentas Web para controle e supervisão: o que está por vir Marcelo Salvador, Diretor de Negócios da Elipse Software Ltda. Já faz algum tempo que ouvimos falar do controle e supervisão

Leia mais

Cloud Computing. Andrêza Leite. andreza.lba@gmail.com

Cloud Computing. Andrêza Leite. andreza.lba@gmail.com Cloud Computing Andrêza Leite andreza.lba@gmail.com Roteiro O que é cloud computing? Classificação O que está 'por traz' da cloud? Exemplos Como montar a sua? O que é cloud computing? Cloud Computing O

Leia mais

INDICE 3.APLICAÇÕES QUE PODEM SER DESENVOLVIDAS COM O USO DO SAXES

INDICE 3.APLICAÇÕES QUE PODEM SER DESENVOLVIDAS COM O USO DO SAXES w w w. i d e a l o g i c. c o m. b r INDICE 1.APRESENTAÇÃO 2.ESPECIFICAÇÃO DOS RECURSOS DO SOFTWARE SAXES 2.1. Funcionalidades comuns a outras ferramentas similares 2.2. Funcionalidades próprias do software

Leia mais

Proposição de Novos Serviços para o SEMSuS: Middleware para Redes de Sensores sem fio baseado em Serviços Semânticos

Proposição de Novos Serviços para o SEMSuS: Middleware para Redes de Sensores sem fio baseado em Serviços Semânticos Proposição de Novos Serviços para o SEMSuS: Middleware para Redes de Sensores sem fio baseado em Serviços Semânticos Marianna Angélica de Araújo 1, Francisco Cassimiro Neto 2, Cláudia Maria Fernandes Araújo

Leia mais

UFG - Instituto de Informática

UFG - Instituto de Informática UFG - Instituto de Informática Especialização em Desenvolvimento de Aplicações Web com Interfaces Ricas EJB 3.0 Prof.: Fabrízzio A A M N Soares professor.fabrizzio@gmail.com Aula 5 Servidores de Aplicação

Leia mais

Projetos I Resumo de TCC. Luiz Rogério Batista De Pieri Mat: 0413829 5

Projetos I Resumo de TCC. Luiz Rogério Batista De Pieri Mat: 0413829 5 Projetos I Resumo de TCC Luiz Rogério Batista De Pieri Mat: 0413829 5 MAD RSSF: Uma Infra estrutura de Monitoração Integrando Redes de Sensores Ad Hoc e uma Configuração de Cluster Computacional (Denise

Leia mais

Web Semântica e Matching de Ontologias: Uma Visão Geral

Web Semântica e Matching de Ontologias: Uma Visão Geral Web Semântica e Matching de Ontologias: Uma Visão Geral Hélio Rodrigues de Oliveira Departamento de Computação Universidade Federal do Ceará heliorodrigues@lia.ufc.br Bernadette Farias Lóscio Departamento

Leia mais

Arquiteturas Orientadas a Serviços ESB. Enterprise Service Bus. Prof. Ricardo J. Rabelo DAS5316 Integração de Sistemas Corporativos

Arquiteturas Orientadas a Serviços ESB. Enterprise Service Bus. Prof. Ricardo J. Rabelo DAS5316 Integração de Sistemas Corporativos ESB Enterprise Service Bus Prof. Ricardo J. Rabelo DAS5316 Integração de Sistemas Corporativos Resumo Introdução Definição Problemas atuais e Vantagens Evolução do ESB ESB versus EAI, MOM, Workfow, SOA

Leia mais

Em Busca de uma Arquitetura de Referência para Frameworks de Aplicação Dirigidos por Modelos para Sistemas de Informação

Em Busca de uma Arquitetura de Referência para Frameworks de Aplicação Dirigidos por Modelos para Sistemas de Informação Em Busca de uma Arquitetura de Referência para Frameworks de Aplicação Dirigidos por Modelos para Sistemas de Informação Valdemar Vicente GRACIANO NETO 1 ; Juliano Lopes DE OLIVEIRA 1 1 Instituto de Informática

Leia mais

ADAPTANDO UMA APLICAÇÃO PARA CLOUD: UMA ANÁLISE ENTRE OS ESFORÇOS UTILIZADOS

ADAPTANDO UMA APLICAÇÃO PARA CLOUD: UMA ANÁLISE ENTRE OS ESFORÇOS UTILIZADOS ADAPTANDO UMA APLICAÇÃO PARA CLOUD: UMA ANÁLISE ENTRE OS ESFORÇOS UTILIZADOS Cleverson Nascimento de Mello¹, Claudete Werner¹, Gabriel Costa Silva² ¹Universidade Paranaense (Unipar) Paranavaí PR Brasil

Leia mais

2 Conceitos relativos a Web services e sua composição

2 Conceitos relativos a Web services e sua composição 15 2 Conceitos relativos a Web services e sua composição A necessidade de flexibilidade na arquitetura das aplicações levou ao modelo orientado a objetos, onde os processos de negócios podem ser representados

Leia mais

Convergência tecnológica em sistemas de informação

Convergência tecnológica em sistemas de informação OUT. NOV. DEZ. l 2006 l ANO XII, Nº 47 l 333-338 INTEGRAÇÃO 333 Convergência tecnológica em sistemas de informação ANA PAULA GONÇALVES SERRA* Resumo l Atualmente vivemos em uma sociedade na qual o foco

Leia mais

MONITOR E PREDITOR DE CONECTIVIDADE WIRELESS BASEADA EM LOCALIZAÇÃO GPS

MONITOR E PREDITOR DE CONECTIVIDADE WIRELESS BASEADA EM LOCALIZAÇÃO GPS MONITOR E PREDITOR DE CONECTIVIDADE WIRELESS BASEADA EM LOCALIZAÇÃO GPS Aluna: Eleonora Cominato Weiner Orientador: Markus Endler Introdução A palavra mobilidade ganha mais importância a cada instante,

Leia mais

Bem-vindo à apresentação do SAP Business One.

Bem-vindo à apresentação do SAP Business One. Bem-vindo à apresentação do SAP Business One. Neste tópico, responderemos à pergunta: O que é o Business One? Definiremos o SAP Business One e discutiremos as opções e as plataformas disponíveis para executar

Leia mais

INTEGRE Diversas fontes de informações em uma interface intuitiva que exibe exatamente o que você precisa

INTEGRE Diversas fontes de informações em uma interface intuitiva que exibe exatamente o que você precisa INTEGRE Diversas fontes de informações em uma interface intuitiva que exibe exatamente o que você precisa ACESSE Informações corporativas a partir de qualquer ponto de Internet baseado na configuração

Leia mais

Semântica para Sharepoint. Busca semântica utilizando ontologias

Semântica para Sharepoint. Busca semântica utilizando ontologias Semântica para Sharepoint Busca semântica utilizando ontologias Índice 1 Introdução... 2 2 Arquitetura... 3 3 Componentes do Produto... 4 3.1 OntoBroker... 4 3.2 OntoStudio... 4 3.3 SemanticCore para SharePoint...

Leia mais

Automatizando o Data Center

Automatizando o Data Center Este artigo examina uma arquitetura alternativa que suporte a automação do data center e o provisionamento dinâmico sem a virtualização do sistema operacional. por Lori MacVittie Gerente Técnico de Marketing,

Leia mais

Padrões Arquiteturais e de Integração - Parte 1

Padrões Arquiteturais e de Integração - Parte 1 1 / 58 - Parte 1 Erick Nilsen Pereira de Souza T017 - Arquitetura e Design de Aplicações Análise e Desenvolvimento de Sistemas Universidade de Fortaleza - UNIFOR 11 de fevereiro de 2015 2 / 58 Agenda Tópicos

Leia mais

UFG - Instituto de Informática

UFG - Instituto de Informática UFG - Instituto de Informática Especialização em Desenvolvimento de Aplicações Web com Interfaces Ricas EJB 3.0 Prof.: Fabrízzio A A M N Soares professor.fabrizzio@gmail.com Aula 14 SOA e ESB Service-Oriented

Leia mais

Desenvolvimento de Sistemas Orientados a Objetos com UML UP/RUP: Projeto

Desenvolvimento de Sistemas Orientados a Objetos com UML UP/RUP: Projeto Desenvolvimento de Sistemas Orientados a Objetos com UML UP/RUP: Projeto Engenharia de Software I Informática 2009 Profa. Dra. Itana Gimenes RUP: Artefatos de projeto Modelo de Projeto: Use-Case Realization-projeto

Leia mais

EIMOBILE INSTITUIÇÕES DE ENSINO MOBILE

EIMOBILE INSTITUIÇÕES DE ENSINO MOBILE UNIVERSIDADE CATÓLICA DE PELOTAS CENTRO POLITÉCNICO TECNOLOGIA EM ANÁLISE E DESENVOLVIMENTO DE SISTEMAS EIMOBILE INSTITUIÇÕES DE ENSINO MOBILE por Miguel Aguiar Barbosa Trabalho de curso II submetido como

Leia mais

XDR. Solução para Big Data.

XDR. Solução para Big Data. XDR Solução para Big Data. ObJetivo Principal O volume de informações com os quais as empresas de telecomunicações/internet têm que lidar é muito grande, e está em constante crescimento devido à franca

Leia mais

ARQUITETURA TRADICIONAL

ARQUITETURA TRADICIONAL INTRODUÇÃO Atualmente no universo corporativo, a necessidade constante de gestores de tomar decisões cruciais para os bons negócios das empresas, faz da informação seu bem mais precioso. Nos dias de hoje,

Leia mais

Modelo de Controle de Acesso para uma Arquitetura Orientada a Serviços Visando a Integração de Aplicações de Comando e Controle

Modelo de Controle de Acesso para uma Arquitetura Orientada a Serviços Visando a Integração de Aplicações de Comando e Controle Modelo de Controle de Acesso para uma Arquitetura Orientada a Serviços Visando a Integração de Aplicações de Comando e Controle Márcio Araújo Varchavsky, Eduardo Martins Guerra, Clóvis Torres Fernandes

Leia mais

Requisitos de Software. Requisitos de Software. Requisitos de Software. Requisitos de Software. Requisitos de Software. Requisitos de Software

Requisitos de Software. Requisitos de Software. Requisitos de Software. Requisitos de Software. Requisitos de Software. Requisitos de Software INSTITUTO FEDERAL DE EDUCAÇÃO, CIÊNCIA E TECNOLOGIA DO RIO GRANDE DO NORTE Curso Técnico em Informática ENGENHARIA DE SOFTWARE Prof.: Clayton Maciel Costa clayton.maciel@ifrn.edu.br Clayton Maciel Costa

Leia mais

Padrões de Projeto Implementados em Infraestrturas de Componentes

Padrões de Projeto Implementados em Infraestrturas de Componentes Padrões de Projeto Implementados em Infraestrturas de Componentes Paulo Pires paulopires@nce.ufrj.br http//genesis.nce.ufrj.br/dataware/hp/pires 1 distribuídas baseadas em componentes Comunicação transparente,

Leia mais

Adaptatividade e interoperabilidade em ambientes de e- learning utilizando tecnologias da web semântica

Adaptatividade e interoperabilidade em ambientes de e- learning utilizando tecnologias da web semântica Adaptatividade e interoperabilidade em ambientes de e- learning utilizando tecnologias da web semântica Aluno: José dos Reis Mota Orientadora: Márcia Aparecida Fernandes Pós-Graduação em Ciência da Computação

Leia mais

Serviço de Controle e Programação para Dispositivos Remotos para Aplicações Interativas e Imersivas na TV Digital

Serviço de Controle e Programação para Dispositivos Remotos para Aplicações Interativas e Imersivas na TV Digital Serviço de Controle e Programação para Dispositivos Remotos para Aplicações Interativas e Imersivas na TV Digital Eduardo Agostinho¹, Victor Nogueira³, Samuel Azevedo³, Luiz Marcos Gonçalves³, Anelisa

Leia mais

Uma introdução à Web Semântica no domínio dos Sistemas de Informações Geográficas

Uma introdução à Web Semântica no domínio dos Sistemas de Informações Geográficas Uma introdução à Web Semântica no domínio dos Sistemas de Informações Geográficas Angelo Augusto Frozza, Rodrigo Gonçalves {frozza,rodrigog}@inf.ufsc.br Universidade Federal de Santa Catarina UFSC Florianópolis

Leia mais

Notas da Aula 15 - Fundamentos de Sistemas Operacionais

Notas da Aula 15 - Fundamentos de Sistemas Operacionais Notas da Aula 15 - Fundamentos de Sistemas Operacionais 1. Software de Entrada e Saída: Visão Geral Uma das tarefas do Sistema Operacional é simplificar o acesso aos dispositivos de hardware pelos processos

Leia mais

Características Básicas de Sistemas Distribuídos

Características Básicas de Sistemas Distribuídos Motivação Crescente dependência dos usuários aos sistemas: necessidade de partilhar dados e recursos entre utilizadores; porque os recursos estão naturalmente em máquinas diferentes. Demanda computacional

Leia mais

O padrão RDF na descrição de imagens

O padrão RDF na descrição de imagens O padrão RDF na descrição de imagens Edeilson Milhomem da Silva 1, Parcilene Fernandes de Brito 1 1 Sistemas de Informação Centro Universitário Luterano de Palmas (CEULP/ULBRA) Cx. Postal 160 77054-970

Leia mais

CLOUD COMPUTING. Andrêza Leite. andreza.leite@univasf.edu.br

CLOUD COMPUTING. Andrêza Leite. andreza.leite@univasf.edu.br CLOUD COMPUTING Andrêza Leite andreza.leite@univasf.edu.br Roteiro O que é cloud computing? Classificação O que está 'por traz' da cloud? Exemplos Como montar a sua? O que é cloud computing? Cloud Computing

Leia mais

Table 1. Dados do trabalho

Table 1. Dados do trabalho Título: Desenvolvimento de geradores de aplicação configuráveis por linguagens de padrões Aluno: Edison Kicho Shimabukuro Junior Orientador: Prof. Dr. Paulo Cesar Masiero Co-Orientadora: Prof a. Dr. Rosana

Leia mais

Um Processo para Desenvolvimento de Aplicações Web Baseado em Serviços. Autores: Fábio Zaupa, Itana Gimenes, Don Cowan, Paulo Alencar e Carlos Lucena

Um Processo para Desenvolvimento de Aplicações Web Baseado em Serviços. Autores: Fábio Zaupa, Itana Gimenes, Don Cowan, Paulo Alencar e Carlos Lucena Um Processo para Desenvolvimento de Aplicações Web Baseado em Serviços Autores: Fábio Zaupa, Itana Gimenes, Don Cowan, Paulo Alencar e Carlos Lucena Tópicos Motivação e Objetivos LP e SOA Processo ADESE

Leia mais

Pontifícia Universidade Católica do Rio Grande do Sul Faculdade de Informática / Campus Global

Pontifícia Universidade Católica do Rio Grande do Sul Faculdade de Informática / Campus Global Pontifícia Universidade Católica do Rio Grande do Sul Faculdade de Informática / Campus Global Sistema de Aproveitamento de Disciplinas da Faculdade de Informática da PUCRS: uma sistemática de gerência

Leia mais

COMPARANDO APLICAÇÃO WEB SERVICE REST E SOAP

COMPARANDO APLICAÇÃO WEB SERVICE REST E SOAP COMPARANDO APLICAÇÃO WEB SERVICE REST E SOAP Cleber de F. Ferreira¹, Roberto Dias Mota¹. ¹Universidade Paranaense (Unipar) Paranavaí PR Brasil cleberferreirasi@hotmail.com, motaroberto@hotmail.com Resumo.

Leia mais

Otimização dos processos de integração de sistemas de informação por meio de barramento de serviços

Otimização dos processos de integração de sistemas de informação por meio de barramento de serviços Otimização dos processos de integração de sistemas de informação por meio de barramento de serviços Celly de Siqueira Martins, André Lara Temple de Antonio Diretoria de Soluções em Billing Fundação CPqD

Leia mais

Apêndice A. Documento de Especicação de Requisitos de Software do Classroom experience

Apêndice A. Documento de Especicação de Requisitos de Software do Classroom experience Apêndice A Documento de Especicação de Requisitos de Software do Classroom experience 103 Especificação dos Requisitos do Software < Classroom experience > Versão 2.0 Preparado por < Taffarel Brant Ribeiro,

Leia mais

Projeto Demoiselle. Para perguntas e respostas, utilizem a lista de discussões de usuários da comunidade: demoiselle-users@lists.sourceforge.

Projeto Demoiselle. Para perguntas e respostas, utilizem a lista de discussões de usuários da comunidade: demoiselle-users@lists.sourceforge. Projeto Demoiselle Para perguntas e respostas, utilizem a lista de discussões de usuários da comunidade: demoiselle-users@lists.sourceforge.net Palestrantes: Antônio Carlos Tiboni Luciana Campos Mota 20/07/2009

Leia mais

Sistemas Distribuídos Capítulos 3 e 4 - Aula 4

Sistemas Distribuídos Capítulos 3 e 4 - Aula 4 Sistemas Distribuídos Capítulos 3 e 4 - Aula 4 Aula passada Threads Threads em SDs Processos Clientes Processos Servidores Aula de hoje Clusters de Servidores Migração de Código Comunicação (Cap. 4) Fundamentos

Leia mais

3 Requisitos não-funcionais de ferramentas de autoria hipermídia

3 Requisitos não-funcionais de ferramentas de autoria hipermídia Requisitos não-funcionais de ferramentas de autoria hipermidia 34 3 Requisitos não-funcionais de ferramentas de autoria hipermídia Na literatura são vários os trabalhos que discutem os requisitos funcionais

Leia mais

Alinhando a infra-estrutura de aplicações com os negócios através de Application Delivery orientado a serviços

Alinhando a infra-estrutura de aplicações com os negócios através de Application Delivery orientado a serviços Alinhando a infra-estrutura de aplicações com os negócios através de Application Delivery orientado a serviços Visão Geral Desafio Solução Uma implementação SOA (Service Oriented Architecture) bem-sucedida

Leia mais

Uso de taxonomias na gestão de conteúdo de portais corporativos.

Uso de taxonomias na gestão de conteúdo de portais corporativos. Gestão de Conteúdo web através de ontologias: conceitos e aplicações Fernando Silva Parreiras Contextualização O que? Uso de taxonomias na gestão de conteúdo de portais corporativos. Quem? Gerentes, consultores

Leia mais

SISTEMAS DISTRIBUIDOS

SISTEMAS DISTRIBUIDOS 1 2 Caracterização de Sistemas Distribuídos: Os sistemas distribuídos estão em toda parte. A Internet permite que usuários de todo o mundo acessem seus serviços onde quer que possam estar. Cada organização

Leia mais

Comunicação Comunicação é o ato de transmissão de informações de uma pessoa à outra. Emissor: Receptor: Meio de transmissão Sinal:

Comunicação Comunicação é o ato de transmissão de informações de uma pessoa à outra. Emissor: Receptor: Meio de transmissão Sinal: Redes - Comunicação Comunicação é o ato de transmissão de informações de uma pessoa à outra. Comunicação sempre foi, desde o início dos tempos, uma necessidade humana buscando aproximar comunidades distantes.

Leia mais

1 Introdução. O sistema permite:

1 Introdução. O sistema permite: A intenção deste documento é demonstrar as possibilidades de aplicação da solução INCA Insite Controle de Acesso - para controle de conexões dia-up ou banda larga à Internet e redes corporativas de forma

Leia mais

Arquitetura de Software: Uma Central para Gestão da execução de serviços

Arquitetura de Software: Uma Central para Gestão da execução de serviços Arquitetura de Software: Uma Central para Gestão da execução de serviços ADILSON FERREIRA DA SILVA Centro Paula Souza São Paulo Brasil afs.software@gmail.com Prof.a. Dr.a. MARILIA MACORIN DE AZEVEDO Centro

Leia mais

Engenharia de Ontologias Seminário UPON

Engenharia de Ontologias Seminário UPON Engenharia de Ontologias Seminário UPON Núcleo de Estudos em Modelagem Conceitual e Ontologias Bruno Nandolpho Machado Vinícius Soares Fonseca Professor: Ricardo de Almeida Falbo Agenda RUP Método UPON

Leia mais