iii escola regional de informÁtica regional norte … · instituto nokia de tecnologia - indt...

III ESCOLA REGIONAL DE INFORMÁTICA REGIONAL NORTE ��

AMAZONAS E RORAIMA

De 17 de abril a 19 de abril de 2013 Boa Vista – RR

ANAIS

Editora Sociedade Brasileira da Computação – SBC

Organizadores José Laurindo Campos dos Santos

Paulo Roberto Farah

Realização Estácio | Atual

Instituto Nacional de Pesquisas da Amazônia – INPA

Promoção Sociedade Brasileira da Computação – SBC

! ii!

!!!!!!!!!!!!!!!!!!!!!

!!!

A532!!!!! Anais! da! III! Escola! Regional! de! Informática:! Regional! Norte! 1:!Amazonas!e!Roraima!(1.!:!2013!:!Boa!Vista,!RR).!!

!!!!!!!!!!!!!!!!!!!!!!!1º!Anais!da!III!Escola!Regional!de!Informática:!Regional!Norte!1:!Amazonas!e!Roraima!/!Organização:!José!Laurindo!Campos!dos!Santos,!Paulo!Roberto!Farah.!RRR!Boa!Vista!:!Sociedade!Brasileira!de!Computação,!2013.!!1!ERbook.!

ISBN!978R85R7669R282R9!!!!!!!!!!!!!!!!!!!!!!!!!!1.!Informática!R!Anais.!2.!Computação.!I.!Santos,!José!Laurindo!

Campos!dos.!II.!Farah,!Paulo!Roberto.!III.!Título.!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!CDD!001.642!

!

! iii!

ANAIS

III ESCOLA REGIONAL DE INFORMÁTICA REGIONAL NORTE 1

AMAZONAS E RORAIMA

http://www.inpa.gov.br/erin2013/

ISBN: 978-85-7669-282-9

Boa Vista – RR, 17 a 19 de abril de 2013

! iv!

Comissão Organizadora

Coordenação:

Prof. Dr. José Laurindo Campo dos Santos (INPA) Email: [email protected]

Prof. MSc. Paulo Roberto Farah (Faculdade Estácio Atual) Email: [email protected]

Instituições organizadoras:

Instituto Nacional de Pesquisas da Amazônia – INPA.

Faculdade Estácio Atual.

Promoção: Sociedade Brasileira da Computação – SBC

Apoio:

Universidade do Estado de Roraima – UERR

Instituto Nokia de Tecnologia - iNdT

Responsável pelo Evento:

Secretaria Regional Norte I – Amazonas e Roraima.

! v!

Editores dos Anais da III ERIN – 2013 Prof. Dr. José Laurindo Campos dos Santos (INPA) Prof. MSc. Paulo Roberto Farah (Estácio Atual)

! vi!

Comitê Científico

Coordenador de Programa

Paulo Roberto Farah (Faculdade Estácio Atual - FEA)

Coordenador do Evento

José Laurindo Campos dos Santos (Instituto Nacional de Pesquisas da Amazônia – INPA)

Membros do Comitê

Alexandre Cardoso, Universidade Federal de Uberlândia Edgar Lamonier, Universidade Federal de Uberlândia Fabio Parreira – Universidade Federal de Santa Maria

Gracieth Valenzuela, Faculdade Estácio Atual José Laurindo Campos dos Santos, Instituto Nacional de Pesquisas da Amazônia

Luciano Ferreira Silva, Universidade Federal de Roraima Marcos Wagner, Instituto Federal de Educação, Ciência e Tecnologia de Goiás

Ornélio Hinterholz Júnior, Faculdade Estácio Atual Paulo Roberto Farah, Faculdade Estácio Atual

Wender Silva, Faculdade Estácio Atual / Universidade Estadual de Roraima

! vii!

Apresentação

Segundo o Plano Nacional de Educação, as instituições de ensino superior, por estarem no núcleo estratégico do sistema de educação superior, têm importância decisiva no desenvolvimento humano, pois são elas que formam a base do desenvolvimento científico e tecnológico, permitindo assim um maior dinamismo das sociedades atuais. Dentre as várias formas dessas instituições atingirem este objetivo, destaca-se a diversificação da oferta de ensino através da disponibilização de cursos modulares, cursos de extensão e eventos técnico científicos que viabilizem maior flexibilidade e ampliação na educação continuada dos discentes do ensino superior.

A Lei de Diretrizes e Bases da Educação Nacional (Lei n º 9.394, de 20 de dezembro de 1996), decretada e sancionada pelo então Presidente da República, em seu artigo 43º estabelece que a educação superior tem por finalidade:

I. Promover a divulgação de conhecimentos culturais, científicos e técnicos que constituem patrimônio da humanidade e comunicar o saber através do ensino, de publicações ou de outras formas de comunicação;

II. Suscitar o desejo permanente de aperfeiçoamento cultural e profissional e possibilitar a correspondente concretização, integrando os conhecimentos que vão sendo adquiridos numa estrutura intelectual sistematizadora do conhecimento de cada geração;

III. Estimular o conhecimento dos problemas do mundo presente, em particular os nacionais e regionais, prestar serviços especializados à comunidade e estabelecer com esta uma relação de reciprocidade;

IV. Promover a extensão, aberta à participação da população, visando à difusão das conquistas e benefícios resultantes da criação cultural e da pesquisa científica e tecnológica geradas na instituição.

Esses itens corroboram a necessidade de uma educação diversificada e continuada no ensino superior no território nacional, com vistas a promover o pleno desenvolvimento do educando, seu preparo para o exercício da cidadania e sua qualificação para o trabalho. Esse projeto visa atender às recomendações do Plano Nacional de Educação e à Lei de Diretrizes e Bases da Educação Nacional, especificamente no que tange à atualização técnico científica; à divulgação de atividades de pesquisa; ao incentivo do espírito de pesquisa de vanguarda entre discentes, docentes e profissionais de informática e da computação; ao acesso a novas tendências tecnológicas; e ao intercâmbio entre as instituições de ensino superior da região. O projeto, com base no documento publicado pela SBC, Grandes Desafios da Pesquisa em Computação no Brasil 2006-2016, no que diz respeito à multidisciplinaridade e a interação com a indústria, visa fomentar a pesquisa de boa qualidade e a interação entre a indústria e a academia para o desenvolvimento tecnológico de qualidade.

! viii!

O projeto, intitulado III Escola Regional de Informática da Região Norte I (III ERIN 2013) abordará temas de relevância para a região, como: TV Digital, Jogos e Entretenimento, Bioinformática, Linguagem de Programação, Recuperação da Informação, Programação Paralela, Sistemas distribuídos, Sistemas Embarcados, etc. Haverá, através de palestras, apresentações de trabalhos de iniciação científica e de conclusão de curso de vários discentes das várias instituições de ensino superior. Além disso, serão ministrados mini cursos por docentes e profissionais. Ao final do evento será realizada uma mesa redonda com o objetivo de debater assuntos de interesse da comunidade acadêmica e profissional.

O III ERIN objetivou levar conhecimento, informar e debater temas relevantes da área de informática que estejam em evidência no país e no exterior para o enriquecimento acadêmico e profissional dos docentes, discentes e profissionais, bem como proporcionar o fortalecimento do intercâmbio entre as universidades, as instituições, as indústrias e as empresas da região.

São objetivos fundamentais os seguintes itens:

! Oferecer aos pesquisadores, professores, estudantes e profissionais de informática e áreas afins da região, oportunidades de conhecer alguns tópicos relevantes que estejam em evidência no país e no exterior, com vistas a contribuir para sua atualização técnico-científica por meio de minicursos, palestras e debates;

! Divulgar as atividades de pesquisa desenvolvidas pelos docentes e discentes dos cursos de Informática e áreas afins;

! Incentivar o espírito de pesquisa de vanguarda entre estudantes e profissionais de informática, fazendo com que entrem em contato com o estado da arte dos vários segmentos de pesquisa de Informática no Brasil;

! Proporcionar o acesso a novas tendências e o intercâmbio entre as universidades e instituições de ensino superior através da divulgação das principais atividades acadêmicas desenvolvidas por elas;

! Promover a colaboração com outras entidades interessadas nos programas de ensino de computação e informática, nos projetos de pesquisa e de extensão, visando, inclusive, a possibilidade de filiar-se a entidades nacionais que tenham o mesmo objetivo.

A Comissão Organizadora

III ERIN - 2013

! ix!

Índice OS DESAFIOS PARA A MOBILIZAÇÃO DE APLICAÇÕES BASEADAS EM PLATAFORMA WEB Celly de Siqueira Martins, André Lara Temple de Antonio e Carlos Antonio de Oliveira

1

ANÁLISE E CARACTERIZAÇÃO DE DESEMPENHO DO FIREWALL IPTABLE/NETFILTER Wagner Rodrigo de Morais, Demétrio do Nascimento Lopes e Paulo Roberto Farah

14

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 e Willian Eduardo de Moura Casante

24

ARQUITETURA E INTERFACE PARA DISTRIBUIÇÃO DE AMBIENTE DE REALIDADE AUMENTADA POR MEIO DO ARTOOLKIT INTEGRADA A PLATAFORMA CORBA APLICADADOS NA EDUCAÇÃO Wender Silva e Paulo Roberto Farah

34

UMA ABORDAGEM DE CÓDIGO ÚNICO PARA APLICAÇÕES INDEPENDENTES DE PROVEDOR DE BASES DE DADOS RELACIONAIS Willian Eduardo de Moura Casante

53

APRESENTAÇÃO E ESTUDO DE CASO DE METODOLOGIA DE ANÁLISE PARA SISTEMAS DE GESTÃO DO CONHECIMENTO EM EMPRESAS DE PEQUENO E MÉDIO PORTE Sergio Luiz Pereira e Bruno Morozini

61

MAIN, A APLICABILIDADE DE AGENTES INTELIGENTES COMO ESTIMULADORES DA INTERATIVIDADE EM AMBIENTES VIRTUAIS DE APRENDIZAGEM Marcio André Andrade Silva e Marcelo Batista de Souza

71

DESENVOLVIMENTO DE UM APLICATIVO PARA IDENTIFICAR DISCENTE COM PROBLEMA DE COMPREENSÃO DE TEXTO Wollace de Souza Picanço e Anderson F. Esteves, Ricardo da Silva Barboza e Wanderlan Albuquerque

81

ALERT@ME, UM SISTEMA DE NOTIFICAÇÃO INTELIGENTE QUE UTILIZA AMBIENTE VIRTUAL DE APRENDIZAGE, TECNOLOGIA MULTIAGENTE E SERVIÇOS DE MENSAGENS CURTAS Romero G. da Silva, Marcelo Batista de Souza e Thais Oliveira Almeida

90

! x!

TECNOLOGIAS MÓVEIS NO AUXÍLIO AO GERENCIAMENTO PATRIMONIAL DE EMPRESAS Gabriel Sampaio La Greca de Paiva, Thais Oliveira Almeida e Wender Antonio da Silva

101

APLICAÇÃO DA REALIDADE VIRTUAL NO AUXÍLIO AO PROCESSO DE ENSINO-APRENDIZAGEM DA GEOMETRIA ESPACIAL Maykon Diego Silva Ribeiro e Wender Antonio da Silva

109

NOVAS CONTRIBUIÇÕES E IMPLEMENTAÇÕES A UM MODELO FORMAL DE ONTOLOGIA DE DOMÍNIO PARA BIODIVERSIDADE Janaína M. P. Nascimento, Delano Campos de Oliveira, Clodomir S Souza Junior, Fábio A. E. Mendes, Marcos Paulo Alves de Sousa, Andréa Corrêa Flôres Albuquerque e José Laurindo Campos dos Santos

118

ESTUDO DA APLICABILIDADE DE GRUPOS DE RESPOSTA E INCIDENTES DE SEGURANÇA (CSIRT) NO AMBIENTE COMPUTACIONAL DO INPA Cicero Paes Leite, José Laurindo Campos dos Santos, Rosana Noronha Gemaque e Ricardo Luís da Costa Rocha

124

GERAQUEST: UM SISTEMA PARA PESQUISAS DE OPINIÃO ATRAVÉS DE DISPOSITIVOS MÓVEIS – UMA PROPOSTA PARA MELHORAR A ACURACIDADE DA COLETA E DO PROCESSAMENTO DE DADOS João Ferreira e Sérgio Mendonça

133

Os desafios para a mobilização de aplicações baseadas em plataforma Web

Celly de Siqueira Martins�, André Lara Temple de Antonio��H�Carlos Antonio de Oliveira�

��Fundação CPqD – Centro de Pesquisa e Desenvolvimento em Telecomunicações Campinas – SP – Brasil

{celly, andret, coliveir}@cpqd.com.br

Abstract. The use of mobile devices, such as tablets and smarphones, has significantly increased over the last years, and is changing the way people relate to one another, to their jobs and to leisure. Wireless devices come in multiple shapes and sizes and such diversity in technology brings new challenges to the Information Technology sector, which are now addressed by the Mobile Computing Technology professionals. This paper describes the evolution of mobile devices, types of mobile applications and the main challenges within the mobile computing context, in addition to two applications with different solutions, one of them migrated from a Web platform.

Resumo. O uso de dispositivos móveis, tais como tablets e smartphones, tem aumentado significativamente nos últimos anos e está transformando a forma de as pessoas se relacionarem com o trabalho, com os amigos e até mesmo com a prática de lazer. Esses dispositivos utilizam recursos de tecnologia sem fio e são apresentados em diversos formatos e tamanhos. A tecnologia de computação móvel surgiu para tratar essa diversidade tecnológica e traz novos desafios à área de tecnologia da informação. Neste artigo, é apresentada a evolução dos dispositivos móveis, são definidos os tipos de aplicativos móveis e os principais desafios da computação móvel, bem como são demonstradas duas aplicações com distintas soluções, uma delas migrada a partir de uma plataforma Web.

1. IntroduçãoO acesso à Internet a baixo custo a partir das redes sem fio, tais como Wi-Fi ou WiMAX, e o aumento significativo de dispositivos móveis com capacidade de processamento e comunicação estão provocando uma mudança na forma de desenvolver aplicações para esses dispositivos. Novos problemas e desafios surgiram para os profissionais da área de tecnologia de informação (TI) para tratar esse assunto denominado computação móvel.

A computação móvel está provando ser um dos avanços tecnológicos atuais mais promissores na área de engenharia e ciência da computação. Com o advento e a

,6%1�� $QDLV�GD�,,,�(VFROD�5HJLRQDO�GH�,QIRUPiWLFD��5HJLRQDO�1RUWH��$PD]RQDV�H�5RUDLPD�

�

proliferação mundial de dispositivos móveis com capacidade de processamento, equipados com interfaces de comunicação sem fio, possibilitando acessar a Internet e executar sistemas e aplicações inovadoras de software, a computação tornou-se verdadeiramente difundida [Figueiredo e Nakamura 2003; Reis, Carmo e Soto 2013; Santos 2002].

Hoje em dia é comum ver pessoas sentadas em salas de aeroportos, restaurantes, hotéis, salas de reuniões e até mesmo em espaços abertos, ou durante uma viagem de carro, ônibus ou avião, acessando seus dispositivos móveis para verificar seus e-mails e compromissos, consultar saldos bancários, obter notícias sobre o tempo, executar tarefas do trabalho, jogar, ouvir música ou apenas conversar com os amigos. A computação móvel está incluída em diversos aspectos da vida humana, e traz novas formas de trabalhar e novos estilos de vida.

A maior vantagem para os usuários de dispositivos móveis é acessar seus recursos e serviços sem a necessidade de manter-se conectado a uma infraestrutura fixa e, em geral, estática. O acesso pode ser feito em qualquer lugar e a qualquer momento. A computação móvel possibilita aos usuários esse acesso independentemente de sua localização, podendo, inclusive, estar em movimento [Mateus e Loureiro 2013; Ogliari et al. 2006; Rishpater 2001; Silva 2005].

2. Evolução dos dispositivos móveisAs plataformas de redes móveis, os dispositivos móveis a elas conectados e os aplicativos móveis executados evoluíram a um ritmo incrível, desde os primeiros aparelhos de telefone celular rudimentares até os mais modernos, elegantes e sofisticados aparelhos de dispositivos móveis.

Os aplicativos móveis não surgiram recentemente. Várias versões e plataformas têm sido desenvolvidas nas últimas décadas e sua evolução foi e está sendo muito rápida. A evolução dos aplicativos móveis para telefones celulares está dividida em cinco eras: modelo tijolo, modelo barra de chocolate, suporte ao protocolo WAP, smartphones e tela de toque [Fling 2009; Tracy 2012].

A era de celulares com tela de toque e a era de smartphones são as mais recentes para a tecnologia de dispositivos móveis, precedidas pelas eras celulares com suporte ao protocolo WAP, modelo barra de chocolate e modelo tijolo, respectivamente nesta ordem. A evolução desses aplicativos ocorre rapidamente, uma vez que as duas eras mais recentes tiveram início a partir de 2002 e a mais antiga em 1973, quando foram dados os primeiros passos em direção ao desenvolvimento de dispositivos móveis.

A Tabela 1 apresenta a evolução dos aplicativos móveis para telefones celulares agrupada em eras e exibe os respectivos períodos com datas aproximadas e suas principais características.

Tabela 1. A evolução dos aplicativos móveis para telefones celulares – adaptada de Fling (2009) e Tracy (2012)

ERA PERÍODO CARACTERÍSTICAS

Modelo tijolo 1973-1988 Baterias enormes e de baixa duração.

Modelo barra de chocolate 1988-1998 Serviços de dados muito limitados.


�

Suporte ao protocolo WAP 1998-2002 Telas pequenas e comunicação sem fio.

Smartphones A partir de 2002

Melhor controle de mensagens e gerenciamento de informações pessoais. Sistemas operacionais Java-ME, Windows Mobile, Palm OS e RIM.

Tela de toque A partir de 2002

Sistemas operacionais iOS e Android.

A primeira era dos aplicativos móveis foi a de modelo tijolo, caracterizada pelo surgimento dos primeiros aparelhos de telefone celular, cujo formato e peso lembrava um tijolo. Esses aparelhos usavam baterias enormes e de baixa duração. O serviço de voz foi o único disponível nessa era.

A segunda era foi a de modelo barra de chocolate, na qual os celulares frequentemente apresentavam o formato de uma barra de chocolate: eram finos, retangulares e alongados. Esses celulares possuíam um serviço de dados muito limitado. Os aplicativos móveis nessa época eram precários e desenvolvidos para aparelhos mais rudimentares.

A era seguinte foi a dos telefones celulares baseados em protocolo Wireless Application Protocol (WAP), capazes de suportar a linguagem Wireless Markup Language (WML), que é um subconjunto da linguagem Hypertext Markup Language (HTML), sendo mais específica para o tratamento de comunicação sem fio. Os aplicativos móveis ainda eram precários, as telas eram pequenas e os implementadores precisavam considerar separadamente alguns itens, tais como a variação dos tamanhos de telas e o tratamento de telas Web.

A penúltima era foi a dos smartphones, em que os aparelhos passaram a ter um maior controle sobre os aplicativos móveis e mantiveram o foco no controle de mensagens e no gerenciamento de informações pessoais, tais como calendários e contatos. Os sistemas operacionais mais difundidos nessa época eram Java-ME, Windows Mobile, Palm OS, RIM, entre outros.

A era mais recente, a dos telefones celulares com tela de toque, é a que mais populariza o uso de dispositivos móveis. A quantidade e o tipo de dispositivo móvel se multiplicaram rapidamente com o lançamento de tela de toque e com tamanhos de tela relativamente grandes. Os sistemas operacionais mais difundidos nessa época são iOS e Android.

Os dispositivos móveis conhecidos como tablets também se popularizaram rapidamente. São relativamente leves e apresentados em tamanhos maiores. Tais dispositivos possuem as funções gerais de computadores, sendo que o controle de mensagens e o gerenciamento de informações pessoais são executados como aplicativos e não como funcionalidades do aparelho. Esses dispositivos geralmente suportam as redes sem fio em vez de serem puramente concebidos para utilização em redes de celulares 3G ou 4G.


�

A variedade de dispositivos móveis é enorme. A Figura 1 ilustra uma diversidade desses dispositivos existentes no período entre 1990 e 2000.

Figura 1. Diversidade de dispositivos móveis entre 1990 e 2000 [Helal, Bose e Li 2012]

3. Aplicativos móveisOs aplicativos móveis são divididos em dois tipos: aplicativos móveis Web e aplicativos móveis nativos. A seguir são apresentadas as vantagens e desvantagens de cada um desses tipos [Castledine, Eftos e Wheeler 2011; Hammershoj, Sapuppo e Tadayoni 2010; Lionbridge 2012; Longoria 2004].

3.1. Aplicativos móveis Web

Um aplicativo móvel Web é uma aplicação Web formatada para dispositivos móveis. O usuário acessa esse aplicativo por meio de um dispositivo móvel, digitando uma URL em um navegador Web. Assim como um aplicativo Web tradicional, o aplicativo móvel Web é construído com três tecnologias principais: HTML, CSS e JavaScript. No HTML são definidos os textos estáticos e as imagens; no CSS, o estilo e a apresentação e no JavaScript, as interações e animações. Uma vez que os aplicativos Web são baseados em navegadores Web, eles são independentes de plataforma e de dispositivos e podem ser executados em qualquer dispositivo móvel habilitado a acessar a Internet.

Um aplicativo móvel Web normalmente é baixado de um servidor Web a cada vez que é executado, muito embora os aplicativos criados em HTML5 possam ser projetados para utilização em dispositivos móveis sem conexão à Internet.

3.1.1. Vantagens dos aplicativos móveis Web

As principais vantagens dos aplicativos móveis Web são:

Os aplicativos móveis Web são mais baratos e sua manutenção é mais simples secomparados com os aplicativos móveis nativos. Isso ocorre pelo fato dedisporem de compatibilidade multiplataforma e não precisarem lidar com asmudanças de diferentes dispositivos móveis.


�

Facilidade de acesso – O usuário não precisa baixar uma aplicação, basta acessaruma URL por meio de um navegador Web e sempre obterá a aplicação maisatualizada para o dispositivo móvel.

3.1.2. Desvantagens dos aplicativos móveis Web

As principais desvantagens dos aplicativos móveis Web são:

Apresentam tempo de resposta mais lento pelo fato de utilizarem HTML econsequentemente dependerem da conectividade e da velocidade da rede.

Geralmente, não podem acessar as funcionalidades de hardware e de softwaredos dispositivos móveis. Se os requisitos exigirem controle de câmera ou deGPS, integração com o gerenciador de informações pessoais ou controle deaplicativo do telefone, a opção por aplicativos móveis Web deve serimediatamente descartada. O uso de jogos ou de gráficos pesados e complexos também não é suportado por esses aplicativos.

Requerem uma conexão com a Internet para funcionar – Esse problema pode sercontornado com o uso da linguagem HTML5, a versão mais recente do HTML,uma vez que permite ao dispositivo móvel funcionar sem estar conectado.

3.2. Aplicativos móveis nativos

Um aplicativo móvel nativo é construído especificamente para determinado dispositivo móvel e seu respectivo sistema operacional. Ao contrário de um aplicativo Web, que é acessado por meio da Internet, um aplicativo nativo é baixado de uma loja de aplicativos e é instalado no dispositivo móvel.

A principal vantagem dos aplicativos nativos em relação aos aplicativos Web é a capacidade de utilização de hardware e software dos dispositivos móveis. Isso significa que os aplicativos nativos podem aproveitar as tecnologias mais recentes disponíveis nesses dispositivos, tais como GPS, câmeras e programas de reconhecimento de voz. Além disso, também podem se integrar com os outros aplicativos existentes nos dispositivos, tais como: calendário, contatos e e-mails.

No entanto, se a tecnologia móvel é extremamente popular, ela está, ao mesmo tempo, em constante mudança, podendo tornar-se altamente fragmentada se considerada a diversidade de tipos de dispositivos móveis e de sistemas operacionais existente. Isso faz com que a tarefa de manter o ritmo de tecnologias emergentes seja onerosa e custosa, especialmente no caso de sistemas multiplataforma. Essa é a maior desvantagem desse tipo de aplicativo.

Esses aplicativos são mais adequados para as aplicações que exigem frequentes atualizações, como, por exemplo, jogos, placares esportivos, relatórios de tráfego e sessões de bate-papo.

3.2.1. Vantagens dos aplicativos nativos

As principais vantagens dos aplicativos nativos são:

Conteúdo mais atrativo ao usuário – Os aplicativos nativos podem utilizar osrecursos nativos do dispositivo móvel, tanto de hardware (GPS, câmera e


�

gráficos) como de software (e-mails, calendário, contatos, fotografias, vídeos e gerenciador de arquivos). Assim, o conteúdo pode ser mais atrativo e é possível tirar vantagem da capacidade do dispositivo móvel.

Habilidade de serem executados sem conexão à Internet – Como o aplicativopermanece instalado no dispositivo, ele pode ser executado mesmo que caia aconexão com a Internet. Assim, uma transferência de dados pode ser retomadaquando a conexão for restaurada. Essa habilidade é denominada funcionalidadeassíncrona.

Rapidez no tempo de resposta – Os aplicativos móveis nativos são mais rápidospois, diferentemente dos aplicativos móveis Web, não precisam ser interpretados.

Maior penetração do aplicativo no mercado – Os aplicativos nativos possuem umícone para facilitar a sua identificação e divulgação. Além disso, as lojas deaplicativos móveis avisam aos usuários sobre atualizações de seus aplicativosquando surgem novas versões. Assim, os aplicativos que são frequentementeatualizados são também apresentados aos usuários com mais frequência e, porconta disso, chamam mais a sua atenção.

Melhor divulgação do aplicativo aos usuários – Como os aplicativos móveis sãoa “atração do momento”, os usuários buscam incessantemente os aplicativos maisrecentes e que despertam seu interesse. Isso oferece mais visibilidade aosprodutos disponíveis nas lojas de aplicativos móveis e, consequentemente, maiorprobabilidade de serem descobertos.

Maior facilidade para comercialização do aplicativo – O preço é definido e onovo aplicativo incluso na lista existente na loja de aplicativos móveis. Quando ousuário efetua a compra, o dinheiro é recebido imediatamente, sendo que ésubtraído o valor da comissão. No caso de aplicações Web, é preciso criar umaforma para efetuar a cobrança de pagamento.

3.2.2. Desvantagens dos aplicativos nativos

As principais desvantagens dos aplicativos nativos são:

As informações de quem são os seus assinantes ficam públicas nas lojas deaplicativos.

Para um aplicativo nativo ser executado em diversos dispositivos são necessárias diversas versões. A natureza fragmentada desses dispositivos representadesenvolver, testar, portar e manter aplicativos para diferentes ambientes, o quepode aumentar significativamente o custo.

Manter o aplicativo nativo atualizado também é trabalhoso, requerdesenvolvimento, testes e distribuição para diferentes plataformas, ao passo queos aplicativos móveis Web são atualizados em um único site na Web.

A Tabela 2 demonstra a principal vantagem e a maior desvantagem dos aplicativos móveis nativos e dos aplicativos móveis Web.


�

Tabela 2. Principal vantagem e maior desvantagem por tipo de aplicativo

APLICATIVOS MÓVEIS NATIVOS

APLICATIVOS MÓVEIS WEB

PRINCIPAL VANTAGEM Possibilidade de utilizar os recursos nativos dos dispositivos móveis

Compatibilidade multiplataforma

MAIOR DESVANTAGEM

Necessário desenvolver um aplicativo para cada plataforma

Lentidão no tempo de resposta

4. Os desafios da computação móvelA evolução dos aplicativos móveis fez surgir novos modelos de negócio, incluindo modelos centrados de dispositivos, em que o usuário pode ter acesso a novas aplicações e serviços, conectando-se a uma loja de aplicativos de fabricantes de dispositivos móveis, como, por exemplo, Google Play Store e Apple App Store. O principal fator dessa mudança é a capacidade avançada dos dispositivos móveis de utilizar as vantagens do processo de convergência, agregando serviços e aplicações avançadas de Internet ao próprio aparelho.

No entanto, o mercado de dispositivos móveis é dominado por diferentes plataformas tecnológicas, incluindo sistemas operacionais e plataformas de desenvolvimento de software, o que gera uma variedade de diferentes soluções disponíveis no mercado. Apesar de essa fragmentação de plataformas tecnológicas promover a concorrência de mercado e propiciar avanços tecnológicos, ela cria também problemas e novos desafios para o desenvolvimento de serviços e conteúdos. Nesse caso, é preciso optar por utilizar plataformas específicas ou incluir uma carga extra nos serviços e conteúdos de forma a atender múltiplas plataformas.

Sendo assim, um dos principais desafios da computação móvel é o desenvolvimento de software em um ambiente de tecnologia altamente fragmentado e em rápida evolução. Os aplicativos móveis exigem uma razoável customização para que possam ser continuamente executados em diversas plataformas e versões, independentemente de atualizações feitas em hardwares, sistemas operacionais e navegadores Web. Mesmo em uma única plataforma – Android, Apple, Windows ou Blackberry – existem diversos itens que requerem alguma customização.

Permitir que usuários acessem informações contextualmente relevantes a qualquer momento e em qualquer lugar é uma tarefa que apresenta desafios substanciais aos profissionais da área de TI.

O aprovisionamento de mais velocidade e de maior quantidade de redes sem fio é a força motriz da computação móvel. Todavia, o que é mais importante e desafiador é projetar algoritmos e protocolos para vários aplicativos, desenvolver sistemas operacionais para pequenas dimensões, usar eficientemente interfaces de usuário de tamanhos menores e, acima de tudo, proporcionar segurança aos sistemas e aos aplicativos.


�

Os ambientes de computação móvel diferem, em alguns aspectos fundamentais, dos ambientes de sistemas distribuídos, nos quais computadores potentes são conectados em uma infraestrutura de rede fixa (a Internet, por exemplo). Os principais itens a serem tratados no âmbito de computação móvel estão listados a seguir [Figueiredo e Nakamura 2003; Hammershoj, Sapuppo e Tadayoni 2010; Kumkum 2010; Ogliari et al. 2006; Terry 2008]:

Selecionar o modelo do aplicativo móvel – É preciso escolher entre o modelonativo e o modelo Web. Para isso, algumas questões devem ser respondidas.Entre elas: O conteúdo sofre muitas alterações? O aplicativo vai utilizar recursosdo dispositivo móvel? Existe necessidade de divulgação do produto? Éimprescindível um tempo rápido de resposta? A partir das respostas a essasperguntas, é preciso ponderar as vantagens e as desvantagens de cada modelopara então selecionar o mais apropriado ao contexto.

Tratar conexões de rede sem fio – As conexões com rede sem fio costumam serintermitentes, de baixa velocidade e com alta latência. O uso da funcionalidade assíncrona pode compensar o problema de desconexão, e o aplicativo podecontinuar sendo executado até que a conexão seja retomada.

Aprimorar a interface gráfica – A interface gráfica deve ser aprimorada paratratar interfaces em dispositivos menores, cuja área de visualização da maioriados aplicativos é pequena. É preciso considerar a existência de diversos tamanhose resoluções de telas.

Tratar a entrada de dados – A entrada de dados nem sempre inclui um mouse; orecurso mais utilizado atualmente é o toque na tela.

Considerar as características dos dispositivos móveis – As características dosdispositivos móveis devem ser consideradas e tratadas. Entre elas estão autilização de recursos do aparelho, o armazenamento de dados e a dependênciade baterias para poder funcionar.

Considerar os riscos de segurança – A segurança abrange a autenticação deusuário, a integridade de dados e a prevenção a ataques maliciosos. As redes sem fio possuem uma segurança física limitada – seus nós são mais vulneráveis aosataques maliciosos. Como não há uma rede fixa, os dados são propagados pelo are podem ser interceptados facilmente se não houver um forte esquema deautenticação e criptografia.

5. Soluções para aplicativos móveisA seguir são apresentadas duas aplicações desenvolvidas para dispositivos móveis, denominadas CPqD liga+ e CPqD Selfcare Mobile.

5.1. Aplicação CPqD liga+

O custo com ligações para telefones celulares de uma mesma operadora costuma ser mais barato ou até mesmo inexistente, dependendo do plano adquirido pelo usuário. Identificar antecipadamente a operadora de um número de telefone a ser chamado pode ajudar um usuário a melhor gerenciar suas ligações e economizar recursos financeiros.


�

A aplicação liga+ foi desenvolvida com o intuito de identificar a operadora de um número a ser chamado e de todos os números de contatos de uma agenda de um dispositivo móvel [Google Play 2013]. A identificação da operadora é feita tanto para telefones celulares como para telefones fixos e, ainda, para números com portabilidade. A Figura 2 apresenta uma imagem de um dispositivo móvel acessando a aplicação CPqD liga+.

Figura 2. Dispositivo móvel acessando a aplicação CPqD liga+

Além disso, é possível visualizar estatísticas de contatos da agenda agrupadas por operadora e com um respectivo percentual dessa quantidade em relação ao total. A ordenação dessa lista é decrescente pelo valor do percentual. A Figura 3 mostra uma imagem de telas da aplicação CPqD liga+.

Figura 3. Imagem de telas da aplicação liga+

A solução adotada para o desenvolvimento dessa aplicação foi baseada em aplicativos nativos. Essa escolha deu-se fundamentalmente pela necessidade de utilizar os recursos do próprio dispositivo. A obtenção dos números da agenda é feita por meio de uma integração com o gerenciador de informações pessoais. As chamadas utilizam o discador para serem efetuadas automaticamente.


�

Foi utilizada a plataforma de desenvolvimento Android e foram criados quatro leiautes diferentes de telas para atender aos diferentes tamanhos (pequeno, normal, grande e extragrande) e às diferentes densidades (baixa, média, alta e muito alta) [Android 2013].

5.2. Aplicação CPqD Selfcare Mobile

CPqD Selfcare Mobile é um portal Web de autoatendimento voltado para o mercado corporativo e de varejo de telecom. Seu objetivo é fornecer ao cliente final uma interface amigável para consulta de faturas, controle de gastos, configurações, consulta de produtos e serviços, compra de produtos, serviços, solicitação e acompanhamento de solicitações, registro de reclamações ou elogios e demais funcionalidades que a operadora queira disponibilizar para seu cliente.

No mercado corporativo, o foco principal é a relação da operadora com grandes clientes corporativos buscando apresentar uma análise detalhada de suas faturas e de seus gastos. No varejo, um dos objetivos é consolidar a Web como o principal canal de atendimento, reduzindo os atendimentos realizados via Call Center, fornecendo serviços de valor agregado e estreitando o relacionamento com o cliente.

A aplicação CPqD Selfcare Mobile surgiu da necessidade de migrar algumas funcionalidades do mercado corporativo do produto CPqD Selfcare para dispositivos móveis. As principais funcionalidades são: consultar gráficos de consumo, consultar faturas, apresentar mensagens e efetuar login. A Figura 4 exibe telas dessas principais funcionalidades.

Figura 4. Imagem de telas da aplicação CPqD Selfcare Mobile

A solução adotada para o desenvolvimento dessa aplicação foi baseada em aplicativos Web. Essa escolha deu-se pelo fato de a aplicação não sofrer muitas alterações, o tempo de resposta não ser um requisito essencial e, principalmente, não precisar utilizar os recursos nativos dos dispositivos móveis.


��

6. ConclusãoA mobilização de aplicações baseadas em plataformas Web está em sua fase inicial e ainda são muitos os desafios existentes para os profissionais de TI. Novas soluções e novos aplicativos devem surgir ou evoluir nos próximos anos. Neste artigo foram apresentados a nova tecnologia de computação móvel e seus principais desafios, os tipos de aplicativos móveis, o histórico da evolução dos dispositivos móveis e duas aplicações desenvolvidas com diferentes soluções.

Definir o melhor tipo de aplicativo móvel a ser utilizado é o maior desafio a ser enfrentado no desenvolvimento de uma solução para dispositivos móveis. É preciso alinhar os requisitos funcionais da aplicação com as vantagens e as desvantagens de cada tipo de aplicativo e ponderar pela melhor solução.

Os aplicativos móveis Web costumam ser mais baratos por ter compatibilidade multiplataforma, mas possuem menor flexibilidade e capacidade na utilização de recursos dos dispositivos e podem apresentar lentidão no tempo de resposta. Os aplicativos móveis nativos costumam ser mais caros pelo fato de necessitar de especialistas para desenvolvimento e pela necessidade de se desenvolver um aplicativo diferente para cada plataforma. Entretanto, eles possuem uma grande vantagem no que diz respeito à possibilidade de utilizar as tecnologias dos dispositivos móveis, tornando-se mais atrativos aos usuários e apresentando rápido tempo de resposta.

7. Trabalhos futurosA tecnologia de computação móvel traz novos desafios aos profissionais da área de TI uma vez que apresenta uma grande diversidade tecnológica: redes sem fio, dispositivos móveis, tipos de aplicativo móvel, interface gráfica, segurança de acesso às informações e prevenção a ataques maliciosos. Alguns trabalhos podem ser desenvolvidos para um melhor entendimento e aplicação da computação móvel. Entre eles é possível destacar:

Estudo de HTML5 integrado a bibliotecas javascript, tais como Titanium,Rhodes e Phonegap, de forma a utilizar os recursos nativos dos dispositivosmóveis, e, ainda assim, permitir a execução multiplataforma e usar afuncionalidade assíncrona para as quedas de conexões de redes sem fio.

Estudo comparativo de diversos aplicativos existentes no mercado para auxiliarno processo de desenvolvimento de aplicativos móveis, demonstrando suasvantagens e desvantagens.

Definição de novos conceitos e formas de interface com o usuário de dispositivosmóveis.

Desenvolvimento de novas aplicações em diversos domínios do conhecimentopara explorar as possibilidades da computação móvel.

Referências Android (2013). “Grouping Resource Types”. Disponível em:

<http://developer.android.com/guide/topics/resources/providing-resources.html#AlternativeResources>. Acesso em: jan. 2013.


��

Castledine, E., Eftos, M. e Wheeler, M. (2011). “Build Mobile Websites and Apps for Smart Devices. Sitepoint.”

Google Play (2013). “liga+ CPQD”. Disponível em: <http://play.google.com/store/apps/details?id=com.cpqd.billing.operadora&feature=personalized-recommendations#?t=W251bGwsMSwyLDIxMywiY29tLmNwcWQuYmlsbGluZy5vcGVyYWRvcmEiXQ>. Acesso em: jan. 2013.

Figueiredo, C. e Nakamura, E. (2003). “Computação Móvel: Novas Oportunidades e Novos Desafios”. T&C Amazônia, ano 1, n. 2. p. 16-28, Disponível em: <http://www.fucapi.br/tec/imagens/revistas/ed02_completo.pdf>. Acesso em: jun. 2012.

Fling, B. (2009). “Mobile Design and Development”. Sebastopol, CA: O'Reilly Media, Inc. 336 p.

Hammershoj, A., Sapuppo, A. e Tadayoni, R. (2010). “Challenges for mobile application development”. In: Intelligence in Next Generation Networks (ICIN), 2010 14th International Conference on, p. 1-8. IEEE.

Helal, S., Bose, R. e Li, W. (2012) “Mobile Platforms and Development Environments”. Synthesis Lectures on Mobile and Pervasive Computing 7, n. 1. p. 1-120. Morgan & Claypool Publishers.

Kumkum, G. (2010). “Mobile Computing: Theory and Practice”. Pearson Education India.

Lionbridge (2012). “Mobile Web Apps vs. Mobile Native Apps: How to Make the Right Choice”. Disponível em: <http://en-us.lionbridge.com/kc/mobile-web-apps-vs-mobile-native-apps.htm>. Acesso em: jan. 2013.

Longoria, R. (2004). “Designing Software for the Mobile Context: A Practitioner's Guide”. Springer-Verlag. New York Incorporated. 153 p.

Mateus, G. e Loureiro, A. (2013). “Introdução à Computação Móvel”. Disponível em: <http://homepages.dcc.ufmg.br/~loureiro/cm/docs/cm_livro_1e.pdf>. Acesso em: jan. 2013.

Ogliari, R. et al. (2006). “Migrando Sistemas Legados de Tomada de Decisões para Ambientes Móveis”. In: II Congresso Sulcatarinense de Computação. Anais do II Congresso Sulcatarinense de Computação.

Reis, C., Carmo, M. e Soto, C. (2013). “Computação Móvel: Tópicos Essenciais”. Disponível em: <http://www.async.com.br/~kiko/mobilcomp/2.php>. Acesso em: jan. 2013.

Rishpater, R. (2001). “Desenvolvendo Wireless para a Web: Como enfrentar os desafios dos Projetos para a Web Sem Fio”. São Paulo, SP: Makron Books, 1ª. edição. 350 p.

Santos, A. (2002). “Adaptação de conteúdos Web para o ambiente WAP”. Porto. 113p. Dissertação (Mestrado em Tecnologia Multimídia) – Faculdade de Engenharia da Universidade do Porto (Departamento de Engenharia Electrotécnica e de Computadores), Porto, março de 2002.


��

Silva, M. (2005). “Sistema de Apoio à Publicação e Edição de Conteúdo Web para Diversos Dispositivos Utilizando Padrões”. Fortaleza. 144p. Dissertação (Mestrado em Informática Aplicada) – Universidade de Fortaleza, Fortaleza, setembro de 2005.

Terry, D. (2008). “Replicated Data Management for Mobile Computing”. Synthesis Lectures on Mobile and Pervasive Computing 3, n. 1: p.1-94.

Tracy, K. (2012). “Mobile application Development Experiences on Apple’s iOS and Android OS”. In: IEEE Potencials, p. 30-34. Disponível em: <http://ieeexplore.ieee.org/xpl/articleDetails.jsp?tp=&arnumber=6248786&contentType=Journals+%26+Magazines&queryText%3DMobile+Application+Development>. Acesso em: ago. 2012.


��

Análise e Caracterização de Desempenho do Firewall IPTables/Netfilter

Wagner Rodrigo de Morais1, Demétrio do Nascimento Lopes1�H�3DXOR�5REHUWR�)DUDK�

Faculdade Estácio Atual�� Boa Vista, Roraima - Brasil

[email protected], [email protected], [email protected]

Abstract. This paper presents overload tests to the firewall Iptables-Netfilter through scripts developed in Shell-Scripts. The experiments demonstrate how is the behavior of the firewall to process throughput requests. This work analyzes the time of answer and the tax of processing of Iptables/Netfilter, and for so much, the rules of safety of him were changed from position to each accomplished request. The goal of this work is to characterize the impact of the position of rules of filtration in packet filtering in the execution of the firewall Iptables/Netfilter version 1.4.8. Experiments were accomplished at laboratory and developed responsible scripts by the tests and the statistical analyses. Resumo. Este artigo apresenta testes de sobrecarga ao firewall Iptables-Netfilter por meio de scripts desenvolvidos em Shell-Scripts. Os experimentos demonstram o comportamento do firewall diante de várias requisições realizadas. Este trabalho analisa o tempo de resposta e a taxa de processamento do Iptables/Netfilter, e para tanto, as regras de segurança dele foram trocadas de posição a cada requisição realizada. O objetivo deste trabalho é caracterizar o impacto da posição de regras de filtragem de pacotes no desempenho do firewall Iptables/Netfilter versão 1.4.8. Para isso, foram realizados experimentos em laboratório e desenvolvidos scripts responsáveis pelos testes e as análises estatísticas.

1. IntroduçãoA ISO/IEC 27002 descreve que, apesar dos benefícios que a rede de computadores oferece às empresas, é preciso haver cautela ao utilizar a Internet e aconselhável utilizar políticas e ferramentas que proporcionem a segurança dos dados e informações, pois pessoas com conhecimentos em informática de má índole podem invadir e ter acessos às redes internas e comprometer a sua segurança.

Nesse aspecto, há vários tipos de softwares que têm como objetivo principal tornar a segurança dessas informações mais eficiente, como os Firewalls, Anti-vírus, Anti-spam, Sistema de Detecção de Intrusão (IDS), dentre outros.

Dentre os softwares citados, destaca-se o Firewall (parede de fogo). Ele tem o objetivo de permitir a entrada ou saída de pacotes (dados) desejados e bloquear os indesejados. Assim, um administrador de uma rede corporativa, por exemplo, pode


��

definir através de regras específicas do Firewall o que pode ou não acessar de e para a rede interna de uma organização (NETO, 2004).

Kurose (2010) cita que um Firewall é formado porum conjunto composto de hardware e software que isola uma rede interna da Internet geral e permite que algumas informações passem ou sejam bloqueadas. O autor descreve ainda que, com um Firewall, um administrador de rede pode controlar o acesso entre o mundo externo e o acesso à rede que ele é responsável, e assim, gerenciar o fluxo de dados.

As ações (regras) definidas pelo Firewall definem o que deve ou não ser permitido a entrar em uma rede de computadores. As regras de um firewall normalmente são escritas em um arquivo de texto (arquivo de configuração) e são configuradas linha por linha, ou seja, é uma escrita sequencial. Quando o firewall é acionado, isto é, quando chega um pacote para ser verificado, ele consulta sequencialmente regra por regra até encontrar a que corresponde ao pacote analisado (ABEDIN, 2006).

Essa escrita sequencial das regras é a principal motivação desse trabalho, pois foi analisado qual sua a influência no tempo de leitura das regras de segurança do Iptables.

O objetivo deste trabalho é caracterizar o impacto da posição de regras de filtragem de pacotes no desempenho do Firewall Netfilter versão 1.4.8. Para isso, foram realizados experimentos em laboratório, instaladas e configuradas máquinas virtuais e do Firewall Iptables. Também foram criados scripts para testar, coletar resultados e realizar análises estatísticas.

A partir dos resultados obtidos, foi observado que em mais de 90% dos casos, a diferença da média de uma requisição em regras com posições distantes, é menor do que meio segundo, sendo que a diferença de posição das regras é maior do que mil linhas inseridas no Iptables.

Também verificou-se por meio de análises estatísticas que a média do tempo de resposta foi quase que na sua totalidade homogênea, ou seja, houve pouca diferença entre cada valor do tempo de resposta e a média aritmética de todas juntas.

Considerando esses resultados, pôde-se concluir que os testes de requisições das regras do Iptables/Netfilter contribuíram de forma prática para a análise de desempenho do mesmo, levando-se em consideração que não foram encontradas pesquisas ou testes com a mesma finalidade deste trabalho. Assim, este projeto torna-se o primeiro a fazer esse tipo de pesquisa e gerar dados estatísticos de cada item analisado no objeto de pesquisa.

2. Iptables O Iptables surgiu na versão do Kernel 2.4 do linux, e é mantido até os dias atuais. O Iptables é um firewall nativo do Linux, ele tem como função manipular as regras do Netfilter, que por sua vez são usadas por administradores de redes para controlar o fluxo de entrada e saída de dados em uma rede de computadores (MELO et al., 2006).

O Netfilter é um módulo do kernel Linux, um framework, que dá suporte ao Iptables. É o programa que se usa para filtrar os pacotes, fazer Nat e logs, dentre outras tarefas. O Iptables é o software para manipular as tabelas.


��

No Linux, as funções de firewall são agregadas à própria arquitetura de Kernel, tornando-o muito superior em relação a seus concorrentes. Enquanto a maioria dos Firewalls pode ser definida como subsistema, o Linux possui a capacidade de transformar o Firewall no próprio (NETO, 2004).

Neto (2004) descreve que tudo o que chega ou sai de um computador é processado pelo Kernel, independente de sistema operacional (S.O.). A diferença é que o Linux agrega, pelo Netfilter, funções de controle de fluxo interno em termos deFirewall. “O Iptables, [...], trata-se, na verdade, de uma ferramenta Front-End para lhe permitir manipular as tabelas do Netfilter, embora o mesmo seja constantemente confundido como um Firewall por si só” (NETO, 2004, p. 25).

De forma sucinta, a sintaxe do Iptables é a seguinte: iptables [tabela] [comando] [ação] [alvo]. Onde [tabela] é uma das tabelas que compõe o Netfilter: Filter, NAT ou Mangle. O campo [comando] pode ser uma nova entrada à lista de regras, exclusão ou alteração na política de segurança. Já o campo [ação] pode especificar o protocolo a ser usado (tcp, icmp, udp, etc...), a interface (placa de rede) de entrada ou saída a ser utilizada, a origem e o destino de um pacote ao qual a regra deve ser aplicada, dentre outros (NETFILTER, 2011).

E por fim, o campo [alvo], este é utilizado para que um pacote se adeque a uma regra criada, pois ele deve ser direcionado a um alvo, e quem especifica isso é a própria regra. Alguns dos alvos (targets) são: ACCEPT: permiti a entrada/passagem do pacote em questão; DROP: descarta um pacote imediatamente; REDIRECT: realiza redirecionamento de portas com a opção –to-port; TOS: prioriza a entrada e saída de pacotes baseado em “tipo de serviço”; etc. (NETFILTER, 2011).

3. MetodologiaNesta seção é apresentada a metodologia para o desenvolvimento deste trabalho. Inicialmente será apresentado o planejamento das análises, em seguida os experimentos feitos em laboratório.

3.1 Planejamento das Análises Nos resultados são mostradas as maiores e menores médias, medianas, desvio-padrão e coeficiente de variação do tempo de resposta do Netfilter. Para indicar o comportamento do Firewall Iptables/Netfilter, foram utilizadas um número de requisições planejadas e geradas pelo shell-script scan.sh e um número de requisições respondidas pelo Firewall. Utilizando os três registros de requisições planejadas, geradas e respondidas, é possível obter o tempo que o Firewall demora para responder as requisições. As métricas de desempenho analisadas foram o Tempo de Resposta e a Taxa de Serviço (throughput) do Firewall.

Quanto à métrica de desempenho de tempo de resposta do Firewall, primeiramente, com as análises estatísticas de tendência central, foram analisadas as médias e medianas dos tempos de respostas de vinte e cinco regras do Iptables/Netfilter em posições diferentes no arquivo de configuração. Para cada posição diferente das regras foram realizadas trinta requisições sequenciais.


��

Nesse cenário, foram desenvolvidos shell-scripts (comandos em Shell) e cada um deles teve uma função específica nos experimentos. A execução deles é de maneira sequencial, pois os resultados de um são necessários para a execução do programa subsequente. Os resultados dos testes e dos cálculos foram salvos em arquivos de texto comum para então com eles, em seguida, gerar os gráficos.

No lado do servidor, computador responsável pelo recebimento das requisições enviadas pelos clientes, foi instalado o firewall Iptables/Netfilter versão 1.4.8 para processar os pacotes recebidos e gerar o log das requisições

Os logs foram feitos com alterações no Syslog, que é o gerenciador de logs do Linux, e também colocando um parâmetro no Iptables para que gerasse os logs de portas específicas. O software GnuPlot foi utilizado para gerar os gráficos dos experimentos. Ele disponibiliza vários tipos, formatos e maneiras para criação de gráficos 2D e 3D.

3.2 Experimentos Para realizar as requisições ao Firewall, foi utilizado o software Nmap na versão 5.51, o qual é uma ferramenta bastante útil quando o objetivo é enviar requisições TCP e UDP e verificar vulnerabilidades em sistemas operacionais diversos.

Nas etapas de experimentos do Iptables, foram coletados dados dos pacotes de requisições de tentativas de conexões nas portas TCP, dos serviços da porta 21 e 80, que representam os serviços de FTP e HTTP respectivamente, e negando o restante. Nesse aspecto, no computador que funcionou como servidor, as três cadeias do firewall foram configuradas para negarem todo tipo de conexão de entrada, roteamento e saída das tabelas INPUT, FORWARD e OUTPUT, respectivamente, e foram liberadas apenas as duas portas descritas anteriormente à cima.

A Figura 1 apresenta o ambiente utilizado nos experimentos. Foram utilizados três computadores, sendo dois clientes, responsáveis por enviar as requisições, cada um requisitando um serviço específico, usando o software Nmap. No lado do servidor foi instalado o Iptables, responsável pelo roteamento dos computadores clientes da rede que foi criada.


��

Durante cada requisição executada, foi utilizado o programa Vmstat, que é um programa do Linux responsável por realizar a coleta de dados do consumo de memória RAM, cache e SWAP, disco rígido, dispositivos de rede e quais processos estavam em execução no momento dos experimentos. Com isso, pode-se verificar que a execução dos scripts e o processamento das regras do Iptables consumiram pouquíssimos recursos de hardware.

Para buscar a exatidão do tempo de resposta de cada teste, foi preciso usar a opção do Nmap com o item de nanossegundos ativado. Também foram feitas alterações no TIMESTAMP - formato do horário - do Debian e colocada a opção de microssegundos, que foi convertido para nanossegundos posteriormente, para que fosse possível gerar os logs do firewall com mais precisão no tempo.

O firewall foi instalado em uma máquina virtual que possui como configuração de hardware um processador Core i5 de 2.3 GHz (apenas um núcleo em execução), 2 Gigabytes de memória RAM e operando com sistema operacional Debian 6.0.4. Já no lado do cliente, a única mudança é na memória RAM utilizada, que foram 1,5 Gigabytes.

4. Resultados dos experimentosNesta seção é apresentado os resultados deste trabalho. Inicialmente será apresentada a taxa de serviço do Iptables, e em seguida seu tempo de resposta. Nos dois casos, foram usadas as portas 21 (FTP) e 80 (HTTP), por serem muito usadas atualmente.

4.1 Taxa de serviço

Figura 1: topologia da rede utilizada nos experimentos


��

As Figuras 2 e 3 mostram as taxas de processamento de cada linha na porta 21, referente ao serviço FTP, quando as regras estavam na posição 1 e 1275, respectivamente.

As Figuras 4 e 5 mostram as taxas de processamento de cada linha na porta 80, referente ao serviço HTTP, quando as regras estavam na posição 11 e 1066, respectivamente.

Nas duas portas, nota-se que não houve diferença no tempo da taxa de processamento entre a primeira e a última regra do Iptables. Enquanto no serviço do FTP a moda foi de duas requisições por segundo, no serviço HTTP a moda foi de quatro requisições por segundo. Com isso, verifica-se que a ordem das regras do Iptables/Netfilter não diminuiu a taxa de serviço. O que ocorreu foi o contrário, pois se essa ordem das regras tivesse alguma influência sobre o taxa de processamento, a

Figura 2 - taxa de serviço do Firewall da 1º regra na porta 21





��

tendência é que quanto maior a posição de uma regra no arquivo de configuração do Firewall, menor seria a taxa de serviço do Iptables. No entanto, isso não acontece e o tempo se manteve o mesmo.

4.2 Tempo de resposta As Figuras 6 e 7 mostram a média e mediana do tempo de resposta das requisições feitas ao Firewall e direcionadas para a porta 21 referente ao serviço FTP. Cada ponto representa uma regra de segurança do Iptables em uma posição específica e os tempos na coordenada y estão em nano-segundos porque as requisições foram menores do que um segundo.

Observa-se na figura 6 que a média do tempo de reposta quando uma regra estava próximo a posição 600 foi de quase um segundo. Mas esse resultado ocorreu porque a média foi influenciada por alguns valores altos, o que torna esse valor discrepante. Para comprovar essa afirmação, a Figura 7 demonstra as medianas do tempo de resposta. Nela verifica-se que os valores das medianas de cada regra são próximos, mais especificamente os pontos próximos à regra 600, o que descarta o alto valor da média dessa regra.

A Figura 8 mostra os valores das maiores requisições e a Figura 9 ilustra os

Figura 9 - Menores tempos de resposta das requisições na porta 21

Figura 6 - Média do tempo de resposta de cada linha na porta 21

Figura 7 - Mediana do tempo de resposta de cada linha na porta 21

Figura 8 - Maiores tempos de resposta das requisições na

porta 21


��

menores. Na primeira, o maior valor está situado na regra de posição 600, que demorou aproximadamente sete segundos. Foi por esse valor que a média dessa regra foi influenciada. Já na Figura 9 é possível analisar que os valores são próximos um dos outros.

O desvio padrão dos valores das requisições sobre as médias de cada regra do Firewall está ilustrado na Figura 10. Nela pode-se analisar que a maioria dos desvios é próxima, ou seja, o valor real das requisições de cada regra não é distante de suas respectivas médias aritméticas.

As Figuras 12 e 13 mostram a média e mediana do tempo de resposta das requisições feitas ao Firewall e direcionadas para a porta 80 referente ao serviço HTTP. Cada ponto representa uma regra de segurança do Iptables em uma posição específica e os tempos na coordenada y estão em nano-segundos porque as requisições foram menores do que um segundo.

A Figura 13 demonstra as medianas do tempo de resposta. Nela, verifica-se que os valores das medianas de cada regra são próximos. Porém, houve mais variabilidade de tempos entre cada posição de uma regra quando se compara com a porta 21.

Figura 10 – Desvio padrão

Figura 13 - Mediana do tempo de resposta de cada linha na porta 80

Figura 12 - Média do tempo de resposta de cada linha na porta��

Figura– 11 Coeficiente de variação


��

A Figura 14 mostra os valores das maiores requisições e a Figura 15 ilustra os menores. Na primeira, o maior valor está situado na regra de posição 3, que demorou aproximadamente três segundos e meio. Na segunda é possível analisar que os menores valores são próximos um dos outros.

O desvio padrão dos valores das requisições sobre as médias de cada regra do Firewall está ilustrado na Figura 16. Nela pode-se analisar que a maioria dos desvios é próxima, ou seja, o valor real das requisições de cada regra não é distante de suas respectivas médias aritméticas. Na Figura 17 é demonstrado o coeficiente de variação de posição das regras na porta 80. É possível analisar que cada valor é semelhante ao outro, e com isso, verifica-se que os resultados são consistentes.

Figura 16 – Desvio padrão Figura 17 – Coeficiente de variação

Figura 15 - Menores tempos de resposta das requisições na porta 80

Figura 14 - Maiores tempos de resposta das requisições na porta 80


��

5. Considerações Finais

A utilização de Firewalls é crescente em função do aumento da utilização da Internet pela sociedade. Este artigo apresentou uma análise e caracterização de desempenho do Iptables/Netfilter versão 1.4.8. A taxa de serviço medida pelo número de requisições por segundo pelo Firewall foi uma métrica utilizada para caracterizar como ele se comportava diante das requisições executadas.

Para a execução dos testes de desempenho foram utilizados pequenos programas feitos em shell-scripts. Foi demonstrado que os shell-scripts podem ser utilizados para desenvolver pequenos aplicativos de alto desempenho.

Os testes foram planejados e executados simulando um ambiente real. Os aplicativos demonstraram que possuem a capacidade de gerarem resultados satisfatórios.

Os resultados obtidos após os testes realizados com os scripts demonstram que, independente da posição de uma regra no Firewall Iptables, os valores das requisições são próximos, ou seja, os resultados das métricas de desempenho de taxa de serviço e tempo de resposta não foram afetados pela localização da regra do Firewall.

Como possíveis trabalhos futuros, pode-se agregar sobrecarga ao Iptables e a outros Firewalls e fazer comparações entre eles. Também é interessante analisar como é o comportamento do Iptables/Netfilter se aumentar o número de suas regras desegurança.

Referências ABEDIN, Muhammad et al. “Detection and Resolution of Anomalies in Firewall

Policy Rules”, 2006. Disponível em: <http://www.utdallas.edu >. Acesso em: 13 de setembro de 2011.

KUROSE, James F.; ROSS, Keith W. Redes de computadores e a internet: uma abordagem top-down. 5 ed. São Paulo: Addison Wesley, 2010.

ISO/EC 27002, INTERNET STANDARD ORGANIZATION. Disponível em: <www.27000.org >. Acessado em: 07/03/2013. McCLURE, Stuart; SCAMBRAY, Joel; KURTZ, George. Hacking exposed:

network security secrets & solutions. 6 ed. McGraw-Hill, 2009. MELO, Sandro. “Exploração de vulnerabilidades em redes TCP/IP”. 2 ed. atualizada.

Alta Books, 2006. NETFILTER. Firewall Iptables/Netfilter. 2010. Disponível em: <

http://netfilter.org/projects/iptables/files/iptables-1.4.8.tar.bz2> Acessado em 07 de setembro de 2011.

NETO, Urubatan. Dominando Linux Firewall Iptables. Rio de Janeiro: Ciência Moderna, 2004.


��

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, Willian Eduardo de Moura Casante

Fundação CPqD – Centro de Pesquisa e Desenvolvimento em Telecomunicações Campinas – SP – Brasil

Diretoria de Soluções em Billing

{celly, andret, wcasante}@cpqd.com.br

Abstract. More and more, organizations are required to integrate information systems as well as use data in different formats. One of the greatest challenges has been to simplify this complex integration process. The ESB – Enterprise Service Bus – technology can be used to integrate heterogeneous information systems in a fast, standardized and simple way. This new technology provides an infrastructure based on a service-oriented architecture in which the interaction of services is performed through messaging, allowing data mediation, routing and transformation. This paper describes the application of the ESB in an information system, within the telecom environment.

Resumo. Cada vez mais as organizações estão tendo que integrar os sistemas de informação e lidar com os mais diversos formatos de dados. Um de seus maiores desafios tem sido simplificar esse complexo processo de integração. A tecnologia de Barramento de Serviços Corporativos pode ser utilizada para integrar sistemas de informação heterogêneos de forma simples, padronizada e rápida. Essa nova tecnologia oferece infraestrutura com Arquitetura Orientada a Serviços e interação de serviços feita por meio de mensagens, permitindo a mediação, o roteamento e a transformação de dados. Este artigo descreve a aplicação do Barramento de Serviços Corporativos em um sistema de informação no domínio de telecom.

1. IntroduçãoA Integração de Sistemas de Informação (ISI) tem por objetivo unir diferentes fontes de dados em uma única visão. À medida que a quantidade de sistemas de informação aumenta e suas bases de dados ficam mais volumosas, a ISI torna-se mais complexa e desafiante para a área de engenharia de software.

Uma ISI é considerada ideal se permite baixo acoplamento entre fontes de dados heterogêneas, facilita o gerenciamento de acesso às informações do sistema e mantém o controle dos dados [Koppal 2009].

O Barramento de Serviços Corporativos (BSC) é uma nova tecnologia que surgiu essencialmente para integrar sistemas de informação projetados com diferentes funções


��

de negócio. Uma nova abordagem da ISI inclui o uso de padrões abertos, mensagens e princípios de baixo acoplamento da Arquitetura Orientada a Serviços (AOS) [Chappell 2004].

A AOS é definida como uma coleção de serviços comunicáveis entre si. A comunicação pode envolver tanto um simples transporte de dados como diversos serviços para coordenar algumas atividades [Erl 2005].

Este trabalho tem como objetivo apresentar uma arquitetura baseada em BSC para solucionar uma questão de ISI no domínio de telecom, de forma a garantir a segurança das informações e a ser implementada rapidamente, além de realizar uma prova de conceito para validar essa tecnologia.

2. Conceito das técnicasAtualmente, as pesquisas e os estudos sobre a integração e a interoperabilidade de diferentes sistemas para compartilhar as informações e integrar as aplicações tornaram-se tópicos muito importantes no campo de negócios, fornecendo tecnologias que possibilitam a ISI.

O modelo de arquitetura ponto a ponto ainda é um modelo comumente utilizado para solucionar os problemas de integração. Esse modelo apresenta um ambiente em que a integração das aplicações é feita em uma solução única e customizada [Rademakers e Dirksen 2008]. Um exemplo desse modelo pode ser observado na Figura 1.

Figura 1. Exemplo de um modelo de arquitetura ponto a ponto

Nesse exemplo, estão integradas quatro aplicações – Cobol, Call Center, ERP e CRM – por meio de seis conexões de integração. A complexidade e o custo aumentam quando é preciso adicionar uma nova aplicação. Supondo-se ser necessário integrar uma nova aplicação às aplicações Cobol, ERP e CRM, seria preciso implementar três novas conexões de integração de forma a permitir a integração dessa nova aplicação ao ambiente existente. Essa implementação pode ser custosa e demorada, o que representa um desafio para a área de engenharia de software, uma vez que, geralmente, as integrações precisam ser implementadas rapidamente.


��

Na Figura 2 é apresentado um modelo de arquitetura que usa o BSC para integrar as aplicações. Para facilitar a comparação entre os dois modelos, são utilizadas as mesmas aplicações exibidas na figura anterior.

Figura 2. Exemplo de um modelo de arquitetura que usa BSC

O que há de mais marcante nessa figura é a redução do número de conexões de integração. A nova aplicação é conectada ao BSC por meio de um adaptador que contém protocolo e tecnologia adequados a essa aplicação. A lógica de integração entre as aplicações é implementada dentro do BSC.

A grande diferença em relação ao modelo de arquitetura ponto a ponto é que esse modelo é projetado para tratar os desafios de integração. Considerando-se que o BSC fornece todos os tipos de funcionalidades de integração, a implementação de novas conexões de integração entre aplicações torna-se muito mais fácil. O modelo de arquitetura que utiliza BSC propõe um ambiente mais flexível e, consequentemente, permite entregar os produtos mais rapidamente e com menor custo.

As aplicações são heterogêneas quando se trata de tecnologias e protocolos. E quando é preciso lidar com muitos protocolos diferentes, tais como: JMS, SOAP, HTTP, FTP, SMTP e TCP, a complexidade para implementar novas conexões de integração entre aplicações é ainda maior. O BSC fornece uma camada de mediação para acessar e converter informações para diversos protocolos e permite a comunicação entre eles com a ajuda de adaptadores [García-Jiménez, Martínez-Carreras, Gómez-Skarmeta 2010].

O BSC é dividido em múltiplas camadas de funcionamento e a própria funcionalidade de integração é desenvolvida como um serviço independente do servidor de aplicação. Assim, é possível manter um baixo acoplamento e uma comunicação


��

altamente distribuída entre serviços heterogêneos. Além disso, o BSC fornece uma AOS altamente distribuída, combinando servidor de mensagens, Web Services, roteamento inteligente baseado em conteúdo e XML para compartilhar dados entre as aplicações [Chappell 2004].

Uma definição expandida dos principais componentes do BSC é dada a seguir.

O servidor de mensagens é utilizado para mover dados entre as aplicações de forma confiável e assíncrona, e deixar transparente para a implementação do código-fonte as diferenças de protocolos de comunicação, plataformas e dependências do sistema operacional. A mediação é responsável pelas atividades de transformação, roteamento, validação e processamento de mensagens [Devmedia 2011, García-Jiménez et al 2010, Lui et al 2011].

Em um ambiente orientado a mensagens, as comunicações podem ser seguras, autenticadas e transportadas com segurança por meio de canais autenticados com certificados digitais nos dois lados da comunicação.

Os Web Services tornaram-se extremamente populares devido às suas principais características. Por terem seu transporte baseado nos mesmos protocolos da Internet, podem usufruir a infraestrutura de segurança disponível nesses protocolos, além dos padrões de segurança próprios para Web Services [Rohr 2009].

Os roteamentos podem se tornar inteligentes mediante a inserção de pontos de decisão baseados na inspeção do conteúdo do XML por meio de uma mensagem. Esse roteamento inteligente, definido administrativamente, pode ser alterado e acrescido de serviços de integração de valor adicionado, tal como transformação de dados. O BSC fornece uma rede de serviços de integração que podem ser estendidos infinitamente e ainda construídos incrementalmente.

A linguagem XML apresenta um formato de texto muito simples e flexível e tem sido amplamente utilizada na troca de uma enorme variedade de dados na Web e em outros lugares [W3C 2011]. Essa linguagem está se tornando cada vez mais um padrão no intercâmbio de informações entre aplicações organizacionais [Vargas 2007].

A linguagem XSLT foi projetada para trabalhar junto com a linguagem XPath (XML Path Language): a XPath identifica as partes de um documento XML a serem transformadas e a XSLT define como a transformação deve ser feita [Tidwell 2008].

A infraestrutura necessária para o BSC deve apresentar as seguintes características [Chappell 2004]:

contêineres de serviços escaláveis e altamente distribuídos; solicitação de serviços orientada a eventos; gerenciamento centralizado de configurações distribuídas de integração; conectividade de diversos clientes e suporte a múltiplos protocolos; roteamento dinâmico e perfeito de dados, respeitando-se os limites físicos de

implantação; segurança unificada e modelo de controle de acesso às informações; configuração distribuída e recursos de implantação, tais como: documentos

XSLT e regras de roteamento;


��

comportamento mutável de componentes de integração baseado emconfigurações e regras em vez de tratamento pelo código-fonte.

Como vantagens do BSC podem ser citadas a facilitação do reuso decomponentes de serviços, a redução do custo de manutenção dos sistemas de informação e o aumento da eficiência da troca de informações com uma alta escalabilidade. Além das vantagens de baixo acoplamento e flexibilidade, a principal vantagem do BSC é ser plug-and-play. Quando é necessário incluir um novo sistema de informação em um projeto de integração existente, deve-se apenas configurar o adaptador, conectá-lo ao barramento de serviços e acrescentar os respectivos componentes de configuração [Hui e Peipei 2009].

3. Arquitetura e prova de conceitoA seguir, é apresentada a aplicação da tecnologia BSC em um sistema de faturamento a ser utilizado em uma empresa operadora de serviços de telecomunicações para atender aos seguintes requisitos: integrar-se a uma grande quantidade de sistemas e garantir a segurança das informações. O objetivo é integrar o sistema de informação CPqD Billing a outros sistemas existentes na empresa — CRM (Customer Relationship Management), SLA (Service Level Agreement), tráfego excedente, cobrança, agentes arrecadadores, Web, impressão, financeiro, fiscal e DW (Data Warehouse). Uma representação gráfica dessa integração é apresentada na Figura 3.

O CPqD Billing é um sistema de informação cujo objetivo é dar suporte aos críticos processos de tarifação, faturamento, arrecadação, cobrança e contestação de fatura na área de telecomunicações. É flexível e está alinhado às necessidades de convergência das organizações, sendo capaz de tarifar serviços de diferentes naturezas, tais como: voz, TV a cabo, Internet e dados, e apresentá-los em uma fatura única, respeitando as regras de tributação vigentes [CPqD 2011].

Os sistemas externos invocam serviços ao CPqD Billing, utilizando Web Services e processos de negócio. Esses Web Services estão em um barramento de serviços denominado CPqD BSC. Logo, a integração desses sistemas ocorre com esse barramento, a fim de isolar e concentrar as integrações com o CPqD Billing. Com isso, pode-se implementar os serviços com as regras de integração necessárias à empresa, sem a necessidade de efetuar customizações ou novas implementações no CPqD Billing. Essas regras são implementadas no barramento de serviços, que realiza chamadas aos componentes de negócio do CPqD Billing. A Figura 4 ilustra uma representação gráfica desse cenário.

A integração mais crítica é com o CRM por haver mais serviços e por ser mais volumosa. Nesse cenário, as mensagens recebidas no BSC são eventos previamente disparados por clientes, sendo que nem sempre esses serviços podem ser efetivados imediatamente no CPqD Billing. Por exemplo, se um ciclo de faturamento estiver sendo executado, os eventos não podem afetar os dados utilizados nessa execução.


��

Figura 3. Integração do CPqD Billing a outros sistemas de informação

A proposta é enfileirar os eventos impedidos de serem executados até que sejam executados de fato. Deve-se criar um serviço com um processo de negócio para executar algumas atividades e, dependendo do resultado de cada uma, tomar uma determinada ação. Essa solução é denominada “repositório CPqD” e seu funcionamento é detalhado a seguir.

Figura 4. Integração do CPqD Billing com o CRM por meio de BSC

Assim que a mensagem é recebida pelo serviço, um processo de negócio é ativado e executa as seguintes atividades:

verifica se no repositório já existe uma mensagem anterior para o identificador decorrelação da mensagem contido na mensagem atual. Se afirmativo, enfileira essa


��

nova mensagem, que aguardará a execução das mensagens anteriores. Se negativo, segue para a próxima atividade;

verifica se existe algum ciclo de faturamento em processamento. Se afirmativo,segue para o passo seguinte. Se negativo, executa a mensagem recebida;

verifica se o identificador de correlação da mensagem está sendo considerado nociclo de faturamento em processamento. Se afirmativo, enfileira essa novamensagem, que aguardará a execução das mensagens anteriores. Se negativo,executa a mensagem recebida.

Uma representação gráfica do repositório CPqD para controlar a execução demensagens pode ser observada na Figura 5.

Figura 5. Repositório CPqD com serviço para controlar a execução de mensagens.

Após o fim de processamento do ciclo de faturamento, um processo automático ou manual poderá disparar a execução das mensagens enfileiradas. Esse processo deve levar em consideração a ordem de enfileiramento e a dependência entre mensagens de um mesmo identificador de correlação da mensagem.

Se houver mais de uma mensagem para um mesmo identificador de correlação da mensagem, a mensagem seguinte só pode ser processada quando a mensagem anterior for finalizada com sucesso. Se ocorrer algum erro de negócio no processamento de alguma mensagem, as mensagens dependentes dessa devem aguardar o reprocessamento e a finalização com sucesso da execução dessa mensagem.

Ao término da execução de cada mensagem, o barramento CPqD BSC envia uma notificação ao CRM, informando a finalização com sucesso ou com erro da mensagem em questão. A Figura 6 exibe uma representação desse processo de finalização das mensagens.


��

O CPqD BSC foi implementado com o JBoss ESB, pois a partir da utilização desse produto, uma arquitetura completa de integração pode ser implementada com base em produtos JBoss. A camada de controle de mensagens do JBoss ESB é chamada JBoss Messaging. A funcionalidade de roteamento do JBoss ESB é baseada em máquina de regras, JBoss Rules, e a funcionalidade de orquestração de serviços é fornecida pela máquina de processos jBPM. Para suportar Web Services e a lógica de implementação, são utilizados os componentes EJB (Enterprise JavaBeans) e POJO (Plain Old Java Object), implementados no servidor de aplicações JBoss.

Figura 6. Repositório CPqD com serviço para finalizar as mensagens

O JBoss Rules é responsável pelo gerenciamento e pelo processamento de regras de negócio. A especificação de requisitos de negócio é feita por meio de regras de negócio que são gerenciadas e executadas por uma máquina de regras [Browne 2009].

As tecnologias de orquestração permitem um baixo acoplamento de serviços, em um ambiente de workflow, e suas interações são coordenadas independentemente de plataforma [Zhu et al 2010].

O jBPM é um gerenciador de processos de negócio que permite modelar os objetivos de negócio, descrevendo, por meio de um fluxograma, os passos e em que ordem devem ser executados para atingir esse objetivo. Isso melhora a visibilidade da lógica de negócio e resulta em representações específicas de um domínio e de alto nível que podem ser mais facilmente entendidas pelos usuários do negócio e são mais fáceis de serem monitoradas [jBPM 2011].

Uma prova de conceito foi executada para validar o tratamento referente ao CRM. O resultado foi positivo, demonstrando ser eficiente tanto no tratamento das mensagens como na execução de serviços e envio de respostas.

A principal vantagem apresentada na arquitetura que utiliza BSC foi o desacoplamento do processo de integração a partir do código-fonte. Primeiramente,


��

foram criados os Web Services que, em seguida, foram migrados para o BSC. Na fase de criação dos Web Services, foi necessário criar manualmente as classes Java. Na fase de migração para o BSC foram criados apenas os WSDLs, sendo que as classes foram criadas automaticamente pelo sistema, demonstrando ser mais uma vantagem da utilização do BSC.

Considerando a existência de muitas alterações nas definições das integrações, essa migração passou a ser muito mais simples e rápida. Além disso, as integrações passaram a ser customizadas por empresa. Assim, o CPqD Billing pode ser configurado para ser instalado em diversas empresas, com os Web Services adequados a cada uma delas e um código-fonte mais enxuto.

4. ConclusãoAumenta a cada dia a necessidade das organizações de integrar sistemas corporativos. Nesse contexto, integrar sistemas de forma simples e aderente a padrões de mercado não é uma atividade trivial. A adoção de uma arquitetura que utiliza o BSC demonstrou ser uma técnica útil para integrar sistemas, proporcionando as seguintes vantagens: rapidez na implementação, melhor controle de segurança das informações, controle mais efetivo nas execuções dos serviços e a desobrigação da criação de código-fonte, cujo desacoplamento demonstrou ser eficiente no processo de integração de sistemas, tornando-o mais simples, rápido e com menor custo.

5. Trabalhos futurosA aplicação da tecnologia BSC é muito ampla e envolve diversas funcionalidades, tais como – roteamento de serviços, transformação de dados, segurança de acesso às informações e conectividade. Todas estas funcionalidades podem ser estudadas mais detalhadamente em um ambiente que utiliza BSC e vários outros trabalhos relacionados a essa tecnologia podem ser desenvolvidos, tais como:

utilização das ferramentas para o gerenciamento de regras de negócio egerenciamento de processos de negócio em uma arquitetura com BSC, de formaa criar um ambiente unificado que integre a combinação de paradigmas de regras,processos e eventos para a ISI;

estudo comparativo de ferramentas de BSC existentes no mercado;

estudo comparativo de desempenho de ISI que utilize uma arquitetura ponto aponto e outra com BSC.

Referências Browne, P. (2009). “JBoss Drools Business Rules”. Birmingham: Packt Publishing.

304 p.

Centro de Pesquisa e Desenvolvimento em Telecomunicações (CPqD). (2011). “CPqD Billing”. Disponível em: http://www.cpqd.com.br/solucoes-e-produtos/215-cpqd-billing-e-customer-care.html. Acesso em: 12 dez. 2011.

Chappell, D. A. (2004). “Enterprise Service Bus”. Sebastopol, CA: O'Reilly Media, Inc. 247 p.


��

Devmedia. (2011). “JBoss ESB”. In: Java Magazine, 59th edition. Disponível em: http://www.devmedia.com.br/articles/viewcomp.asp?comp=10202&tc=devad_69.htm. Acesso em: 14 dez. 2011.

Erl, T. (2005). “Service-Oriented Architecture (SOA): Concepts, Technology and Design”. Upper Saddle River, NJ, USA: Prentice Hall. 760 p.

García-Jiménez, F. J., Martínez-Carreras, M.A.; Gómez-Skarmeta, A. F. (2010). “Evaluating Open Source Enterprise Service Bus”. In: IEEE 7th International Conference on E-Business Engineering, Shangai, China. IEEE Computer Society. Disponível em: http://ieeexplore.ieee.org/ search/freesrchabstract.jsp?tp=&arnumber=5704329&openedRefinements%3D*%26filter%3DAND%28NOT%284283010803. Acesso em: 06 dez. 2011.

Hui, W. e Peipei, F. (2009). “Research of Strategic Route in Heterogeneous System Integration Based on ESB-SOA”. In: 2009 International Conference on Computational Intelligence and Software Engineering, CiSE 2009, Wuhan, China. IEEE Computer Society. Disponível em: http://ieeexplore.ieee.org/xpl/freeabs_all.jsp?arnumber=5362609. Acesso em: 05 dez. 2011.

jBPM. (2011). “jBPM Documentation”. Disponível em: http://www. jboss.org/jbpm. Acesso em: 16 dez. 2011.

Koppal, K. (2009). “Data Integration in Reporting Systems using Enterprise Service Bus”. Dissertação de mestrado em Ciência da Computação e Engenharia, The Ohio State University, Ohio, 2009.

Lui, M. et al. (2011). “Pro Spring Integration”. New York, USA: Apress. 664 p.

Rademakers, T. e Dirksen, J. (2008) “Open Source ESBs in Action”. Greenwich, CT, USA: Manning Publications. 528 p.

Rohr, E. M. Z. (2009). “Segurança em Gerenciamento de Redes Baseado em Web Services”. Dissertação de mestrado em Ciência da Computação, Instituto de Informática, Universidade Federal do Rio Grande do Sul, Porto Alegre, abril de 2009.

Tidwell, D. (2008). “XSLT”. 2nd edition. Sebastopol, USA: O'Reilly Media, Inc. 965 p.

Vargas, A. P. (2007). “Tratamento de Conflitos e Detecção de Deltas em Atualização através de visões XML”. Dissertação de mestrado em Ciência da Computação, Instituto de Informática, Universidade Federal do Rio Grande do Sul, Porto Alegre, maio de 2007.

W3C. (2011). “Extensible Markup Language (XML)”. Disponível em: http://www.w3.org/XML. Acesso em: 12 dez. 2011.

Zhu, D. et al. (2010). “Enhancing ESB based Execution Platform to Support Flexible Communication Web Services over Heterogeneous Networks”. In: 2010 International Conference on Communications, ICC, Cape Town, South Africa, IEEE Computer Society. Disponível em: http://ieeexplore.ieee.org/xpl/ mostRecentIssue.jsp?punumber=5497983. Acesso em: 16 dez. 2011.


��

Arquitetura e Interface para distribuição de Ambiente de Realidade Aumentada por meio do

ARToolKit integrada a plataforma CORBA aplicados na Educação

1

Wender A. Silva1,2, Paulo Roberto Farah2 Curso de Ciências da Computação – Universidade Estadual de Roraima

(UERR) CEP 69304-080 – Boa Vista – RR – Brasil

2Estácio Atual – Faculdade Estácio da Amazônia

CEP 69313-792 – Boa Vista – RR – Brasil

[email protected], [email protected]

Abstract

This work presents an architecture for distribution of virtual environments in Augmented Reality as a tool to support projects in education. Thus, for the creation of the software prototype, the interface of Augmented Reality is based on a study case that represents a specific area of knowledge, in this case the plant physiology. Thus was created an interface of Augmented Reality that enables user interaction with the virtual environment through menus for interaction and also by means of labels. This interface is integrated with a layer of distribution. Thus, the layer of distribution was implemented following the methodology client / server-based objects. With the implementation, the interactions made in an environment are replicated for other environments and vice versa, thereby generating a strong system applicable to education as it can provide multiple views of virtual objects on the real objects.

Resumo

Este trabalho apresenta uma arquitetura para distribuição de ambientes virtuais de Realidade Aumentada como ferramenta de apoio a projetos de ensino. Assim, para a construção do protótipo de software, a interface de Realidade Aumentada está baseada em um estudo de caso que representa uma área específica do conhecimento, neste caso, a fisiologia vegetal. Desta forma, é criada uma interface de Realidade Aumentada que possibilita a interação do usuário com o ambiente virtual por meio de menus de interação e também por meio de marcadores. Esta interface é integrada a uma camada de distribuição. Assim, a camada de distribuição é implementada seguindo a metodologia cliente/servidor baseada em objetos.


��

1.1. IntroduçãoA Realidade Virtual (RV) é, antes de tudo, uma “interface avançada do usuário” para acessar aplicações executadas no computador, tendo como características, a visualização de, e movimentação em, ambientes tridimensionais em tempo real e a interação com elementos do mesmo (Tori, Kirner e Siscoutto, 2006). Nesse aspecto pode-se considerar que a Realidade Virtual é considerada uma tecnologia revolucionária, pois possibilita a simulação de mundos reais e imaginários na tela do computador ou em outros dispositivos, criando no usuário a sensação de presença em um “mundo” virtual.Relacionado com a Realidade Virtual, a Realidade Aumentada (RA) é a inserção de objetos virtuais no mundo real por meio de um dispositivo computacional. Desta forma, a interface do usuário é aquela, que ele usa no ambiente real, adaptada para visualizar e manipular os objetos virtuais colocados no seu espaço (Azuma et al, 2001).Entende-se que a Realidade Aumentada, enriquece o ambiente físico com objetos virtuais, assim essa, foi beneficiada pelo progresso da tecnologia da computação, tornando viável aplicações desta tecnologia, tanto em plataformas sofisticadas quanto em plataformas populares. Então, diferentemente da Realidade Virtual, que transporta o usuário para o ambiente virtual, a Realidade Aumentada mantém o usuário no seu ambiente físico e transporta o ambiente virtual para o espaço do usuário, permitindo a interação com o mundo virtual, de maneira mais natural e sem necessidade de treinamento ou adaptação (Tori, Kirner e Siscoutto, 2006). Nesse contexto, novas interfaces multimodais vêem sendo desenvolvidas para facilitar a manipulação de objetos virtuais no espaço do usuário, usando as mãos ou dispositivos mais simples de interação.Assim, as pesquisas em Realidade Virtual e Aumentada vêm crescendo consideravelmente por meio de vários grupos de pesquisa ligados à indústria, ao entretenimento e, principalmente à educação. Além disso, existem muitos estudos, soluções e implementações para possibilitar que mais de uma pessoa faça parte de um Ambiente Virtual (Jing et al., 2005). Neste sentido o objeto de estudo desta pesquisa é a distribuição de ambientes de Realidade Aumentada, deixando claro que as principais pesquisas concentram-se na melhoria do processo de comunicação entre as cópias de um ambiente. Porém, dependendo da aplicação, nem sempre a preocupação será com a comunicação entre cópias de um ambiente, mas também com a comunicação entre ambientes virtuais distintos, além da colaboração nos ambientes virtuais. Sendo assim, a motivação para o desenvolvimento deste é a necessidade de pesquisas e desenvolvimento de técnicas para distribuição de ambientes virtuais para Realidade Aumentada com suporte a uma interface que possua flexibilidade considerável para interações de objetos virtuais distribuídos, onde a distribuição deve ocorrer em decorrência de interações realizadas em interfaces de Realidade Aumentada. Assim, esta pesquisa tem por objetivo apresentar uma abordagem computacional/algorítmica e, ainda, uma arquitetura que seja suficiente para suportar o funcionamento de um Ambiente Virtual de Realidade Aumentada Distribuída. Assim, para realizar esta distribuição faz-se necessário a implementação de uma interface de Realidade Aumentada que possua um nível razoável de interação.


��

1.2. Aplicações e Intervenções Educacionais com Realidade AumentadaOs sistemas virtuais possibilitam experiências com a sensação de presença, por meio da integração dinâmica de diferentes modalidades perceptivas, que envolvem imagens, sons, tato, etc. Assim, torna-se possível a capacidade de manipular, relacionada às reações sensório-motora em tempo real (Lévy, 1999). Ainda, tem-se que, por outro lado, os ambientes educativos devem oferecer condições favoráveis à criação, comportando-se como um espaço agradável e permitindo aplicações práticas e a relação do conhecimento com experiências, necessidades e realidade do aprendiz (usuário) (Billinghurst, 2005).Desta forma e, de maneira geral, a construção do conhecimento dá-se por meio da reflexão, da crítica, da identificação e da busca de resoluções dos problemas, propiciando situações que determinem o desafio-papel importante na formação de atitudes (Valente, 2001). Dentro deste contexto, os ambientes virtuais podem contribuir, estimulando a curiosidade e auxiliando no desenvolvimento da autonomia. Assim, entende-se que a aprendizagem ocorre, quando o indivíduo está engajado e utiliza de forma consciente, estratégias de resolução de problemas para a construção significativa. Assim, entende-se a possibilidade de interação entre objetos reais e virtuais, que ocorre por meio da Realidade Aumentada (RA), pode oferecer ao usuário maiores informações sensitivas, facilitando a associação e a reflexão sobre a situação. Os sistemas de Realidade Aumentada permitem que o usuário decida sobre os ambientes, compondo cenas com imagens de objetos tridimensionais geradas por computador misturadas com imagens reais, aumentando as informações do cenário e oferecendo condições para a imersão no ambiente criado (Billinghurst, 2005). Desta forma, a principal característica destes ambientes é que as informações do mundo real são utilizadas para criar um cenário incrementado com elementos gerados por computador (Dainese, 2003).Três características são responsáveis por tornar as situações com intervenção educacionais interessantes: curiosidade, fantasia e desafio. Por meio dos ambientes de Realidade Aumentada, é possível proporcionar ao aprendiz (usuário) situações lúdicas, tornando as atividades mais motivadoras (Kalawsky, 1993).Em ambientes de Realidade Aumentada, o mundo real é “aumentado” com informações que não estão presentes na cena capturada, e o usuário passa ser um elemento participativo no cenário em que imagens reais são misturadas com virtuais para criar uma percepção aumentada (Azuma, 2001). Desta forma, a interface deve ser entendida como um espaço de comunicação, um sistema semiótico, onde signos são usados para interação, possibilitando o acesso ao ambiente (Garbin et al., 2004). Assim, para garantir uma boa usabilidade, os fatores humanos devem ser respeitados. Isso remete à questão da diversidade dos usuários, suas características cognitivas, de personalidade, cultura, idade, comportamento, habilidades e necessidades especiais (Baranauskas e Rocha, 2003). Dentro deste contexto, entende-se que os estudos sobre a memória humana (principalmente a de curta duração), vêm oferecendo subsídios para soluções inteligentes sobre a interface, cuja idéia central é liberar o usuário da memorização de comandos para tornar o ambiente mais agradável e natural possível, dentro das características das ferramentas de desenvolvimento, por meio de interfaces gráficas (Pinho, 1996). Desta forma, entende-se que um ambiente educativo deve ser atrativo e, interessante, oferecendo, por meio de situações lúdicas e espontâneas, atividades que proporcionem o desenvolvimento cognitivo (Lévy, 1999). Nesse contexto, de acordo com Azuma (1997) a Realidade Aumentada enriquece o


��

ambiente real com objetos virtuais, com base em tecnologias que permitem misturar o cenário real com virtuais. Com esse fator motivacional, a Realidade Aumentada possibilita implementar ambientes que permitam a aplicação de estratégias diferenciadas para o desenvolvimento cognitivo. Desta forma, o sistema de Realidade Aumentada desta pesquisa consiste-se de três etapas: a) desenvolvimento tecnológico, b) possíveis aplicações educacionais e) teste de usabilidade do software.

1.3. Sistemas Distribuídos de Realidade Virtual e AumentadaAs aplicações de Realidade Virtual e Aumentada podem ser vistas sob um aspecto bastante amplo, variando de uma única pessoa, usando um único computador, até muitos usuários, usando um sistema distribuído (Rinaldi et al., 2006). Dentro deste contexto, os Ambientes Virtuais Distribuídos (AVD’s) vêm crescendo e apresentando um elevado potencial de aplicação. Eles são caracterizados como Ambiente Virtual (AV) interativo em que usuários dispersos geograficamente têm como objetivos a cooperação e o compartilhamento dos recursos computacionais em tempo real usando um suporte de rede de computadores para melhorar o desempenho coletivo por meio da troca de informações (Rinaldi et al., 2006).De acordo com Rinaldi et al. (2006) em AVD’s os usuários podem compartilhar um mesmo espaço tridimensional virtual de trabalho (workspace), onde poderão se auxiliar na execução de uma determinada tarefa, baseando-se nos princípios de trabalho cooperativo baseado em computador (CSCW - Computer Supported Cooperative Work). Ainda, de acordo com Ribeiro (2006) a Realidade Virtual pode empregar várias técnicas para reproduzir o mundo real e imaginário e possibilitar a manipulação e visualização de informações no computador como se fosse o mundo real. Desta forma, entende-se que a complexidade desses ambientes virtuais aumenta na medida em que essas informações tornam-se comuns a uma série de usuários, ou seja, esses ambientes são distribuídos (Ribeiro, 2006). Assim, pela sensação de compartilhamento de espaço, todos os participantes de um AVD têm a ilusão de estarem localizados no mesmo lugar, tais como na mesma sala, prédio ou região.Baseando-se nesta constatação, Rinaldi et. al. (2006) destaca que este espaço compartilhado representa um local comum, podendo ser real ou fictício. O local compartilhado deve apresentar as mesmas características a todos os participantes. Desta forma, entende-se que a comunicação dos Ambientes Virtuais pode ocorrer por meio de gestos, textos, eventos e áudio. Assim, de acordo com Rinaldi et al. (2006), um AVD consiste de quatro componentes básicos: displays gráficos, dispositivos de comunicação e controle, sistema de processamento e rede de comunicação. Estes componentes devem trabalhar juntos para fornecer a sensação de imersão em diferentes localidades.Desta forma, os modelos de comunicação em um AVD podem ser baseados no modelo Cliente/Servidor, com computação distribuída orientada a objetos. Neste sentido, Rinaldi et al. (2006) destaca que o paradigma Cliente/Servidor em um AVD implica na comunicação direta somente do cliente com o servidor ou vice-versa. Assim, entende-se que existem diversas plataformas que proporcionam essa distribuição como CORBA, RPC, Java/RMI (RAJ, 2004). Resumidamente, um AVD (Ambiente Virtual Distribuído) pode ser definido de forma simplificada como um sistema que permite vários usuários interagirem tanto com o ambiente, quanto entre “eles” em tempo real, mesmo que estes estejam em diferentes localidades geográficas (Ribeiro, 2006).


��

Então, entende-se que, como qualquer outro Ambiente Virtual, a criação de Ambientes Virtuais distribuídos está bastante ligado com realismo visual e interação. Desta forma, Rinaldi et al. (2006) destaca que assuntos como modelagem gráfica tridimensional e interação homem-máquina constituem uma parte fundamental. Em especial na elaboração de um AVD destaca-se o suporte de comunicação em rede. Por meio de uma rede é fornecida a base para que unidades computacionais heterogêneas separadas fisicamente sejam unificadas para implementar um único ambiente virtual.Assim, Rinaldi et al. (2006) destaca que geralmente o desenvolvedor procura um ambiente que lhe abstraia detalhes de comunicação. São vários os pacotes de software que oferecem tais serviços. Pode-se dividi-los em quatro categorias: sockets, toolkits, middlewares e frameworks, ainda, Riccioni (2000) relata que “os middlewares são soluções independentes de plataformas e de domínio de aplicação. Dentro deste contexto, Ribeiro (2006) destaca que a área de aplicação dos AVD’s é muito abrangente: treinamento (pilotos, militar), pesquisa, ensino à distância, comércio, cultura e engenharia. Desta forma, entende-se que o computador apresenta um grande potencial como ferramenta de apoio ao ensino, que aliada às técnicas de Realidade Virtual e colaboração, pode enriquecer e valorizar a informação transmitida, simulando realidades, muitas vezes, fora do alcance dos usuários (Ribeiro, 2006).

1.4. Arquitetura do SistemaNovas tecnologias têm sido criadas para dar suporte ao desenvolvimento de aplicações em Realidade Virtual e Aumentada (Sementille, 1999). Tradicionalmente, os displays gráficos somente eram disponíveis em estações de trabalho. Porém, atualmente os preços do hardware têm caído, a ponto de permitir que essas capacidades gráficas estejam presentes nos computadores pessoais (PC’s).

1.5.1. Tecnologias de ApoioCORBA : O padrão CORBA é uma plataforma que permite às aplicações distribuídas (local ou mesmo na internet) comunicar entre si e trocar informações em uma rede de computadores. Esta tecnologia subsidia a distribuição e é um dos principais componentes da arquitetura proposta para esta pesquisa.Visibroker: De acordo com Ribeiro (2006) pode-se afirmar que existem muitas implementações CORBA disponíveis. Para implementação deste sistema, é utilizada a implementação CORBA da BorlandTM1. O produto CORBA é chamado visibroker, que é um ORB (Object Request Broker) desenvolvido pela INPRISE (Teixeira, 2002). Para a escolha deste tipo de implementação recorre-se à Ribeiro (2006), Costa (2000) e Siqueira (2005) que relatam e comparam as arquiteturas de distribuição, demonstrando o potencial da implementação do CORBA.ARToolKit: Kirner (2008) destaca que o ARToolKit é um toolkit que viabiliza o desenvolvimento de interfaces de Realidade Aumentada. Disponível gratuitamente no site do laboratório HITLAB

2 da Universidade de Washington, o ARToolKit emprega métodos de visão computacional para detectar marcadores na imagem capturada por uma câmera. O rastreamento óptico do marcador permite o ajuste de posição e orientação para realizar a renderização do objeto virtual, de modo que esse objeto pareça estar “atrelado” ao marcador (Kirner, 2008).

1 http://info.borland.com.br


��

1.6.2. Arquitetura para Distribuição do SistemaO propósito deste tópico é a descrição de uma arquitetura que permita a existência de n computadores capazes de hospedar Ambientes de Realidade Aumentada, fazendo assim, a distribuição dos objetos virtuais visualizados e manipulados na cena. Ainda, destaca-se a implementação de uma interface que permita a interação de objetos virtuais na cena em tempo real. Desta forma, propôe-se a seguinte arquitetura para distribuição do sistema de Realidade Aumentada, conforme a Figura 5.

Figura 5. Arquitetura para a distribuição do sistema

O sistema proposto nesta pesquisa (R.A. Distribuída) é composto pelos seguintes módulos: - Interface de Realidade Aumentada: A interface propicia a manipulação dos parâmetros interativos que serão distribuídos e, também a visualização dos objetos distribuídos que podem ter sido manipulados por outros usuários.- Servidor: Servidor da aplicação recebe dos clientes e distribuí na rede de computadores as informações acerca dos objetos que devem ser tratados e visualizados nos marcadores em todas as interfaces de Realidade Aumentada. Este servidor é independente da interface de Realidade Aumentada, sendo inicializado automaticamente no computador do primeiro cliente que for ativado.- Clientes: Para cada interface R.A. têm-se um Cliente de Comunicação. Esse Cliente faz parte da camada de Realidade Aumentada Distribuída. - ARToolKit: Toolkit de código aberto para criação de ambientes de Realidade Aumentada, neste caso o produto de sua compilação é a interface de R.A.2 Laboratório de Tecnologia em Interfaces Humanas.


��

- Camada de Comunicação: Junção das implementações feitas no ARToolKit e nos Clientes de Comunicação, onde é feita a passagem dos parâmetros para distribuição da interface de Realidade Aumentada para os Clientes de Comunicação e vice-versa.Resumidamente, verifica-se que:A Figura 5 ilustra a existência de n computadores, sendo que cada computador pode hospedar apenas um único ambiente virtual de Realidade Aumentada e sempre haverá uma aplicação servidora que proverá serviços para os clientes. Cada objeto “R.A Distribuída” possui uma interface de R.A., uma Camada de Comunicação e um Cliente de Comunicação. A interface R.A. possui um ambiente baseado em um estudo de caso da fisiologia vegetal, já o Cliente de Comunicação trabalha diretamente com a distribuição. Cada interface de Realidade Aumentada pode ser executado separadamente e possui interações dentro do próprio ambiente. A distribuição ocorre quando uma interação feita por meio da oclusão for disparada. Os objetos virtuais foram modelados em VRML e carregados no ARToolKit, onde são transformados em uma matriz de pontos e vértices OpenGL. Por meio da integração das implementações realizadas no ARToolKit e na plataforma de distribuição CORBA, criou-se uma camada de comunicação.O usuário interage com um ambiente virtual em Realidade Aumentada, de tal forma que as informações capturadas pela interface de Realidade Aumentada são repassadas para a Camada de Comunicação. Desta forma, a aplicação-cliente fica lendo a Camada de Comunicação, verificando o que está sendo posicionado e, assim, enviando para a aplicação-servidora que, por sua vez disponibiliza para todas as outras aplicações-clientes. A aplicação-cliente localiza na rede de computadores uma aplicação-servidora com a ajuda do Visibroker (implementação CORBA), que responderá à requisição da aplicação-cliente. As informações de cada aplicação estarão armazenadas sempre em um objeto-servidor, porém, cada cliente armazena informações sobre sua atual situação.

1.6.3. Pipeline3 da Interface SistemaDe acordo com a Figura 6, ilustra-se o funcionamento de um Pipeline de funcionamento do algoritmo apresentado nesta pesquisa e adaptado à arquitetura do ARToolKit, onde pode-se relatar:

3 Pipeline: conjunto de processos encadeados por meio das suas saídas padrões, de forma que a saída de um processo é utilizada como entrada do processo seguinte.


��

Figura 6. Pipeline da interface R.A adaptada à Arquitetura do ARToolKit

- Camada de Comunicação: Como já mencionado no item “arquitetura para distribuição do sistema”, esta camada recebe parâmetros do Cliente de Comunicação, que por sua vez recebe os parâmetros do Servidor de Comunicação. Então estes parâmetros são lidos pela interface de Realidade Aumentada (ARToolKit) e, de acordo com o parâmetro é então feita a visualização do objeto virtual na cena para todos os clientes e interfaces R.A. que tenham o marcador de referência do objeto.- Controle de Interação: O controle realizado nas interações da interface de Realidade Aumentada é realizado por meio de várias técnicas para criar interações que permitam obter um ambiente com um nível satisfatório de interatividade. Assim, pode-se destacar as interações em tempo real na interface do sistema R.A. Distribuída: a) Transformações Geométricas; b) Colisão de Objetos Virtuais: o sistema realiza a colisão de objetos virtuais, esses objetos estão dispostos na interface em forma de menus suspensos, onde o usuário ao colidir o marcador em qualquer um dos objetos disponíveis, faz a sua captura, ou seja, o objeto virtual que está sendo visualizado na tela é instanciado para o marcador que realizou a colisão. c) Oclusão de Marcadores: ao realizar o item “b” deste parágrafo, o objeto virtual com seu respectivo marcador ao ser posicionado à frente de um outro marcador, onde o sistema de Realidade Aumentada verifica se o marcador que esta sendo sobreposto está ocluso ou não, caso a oclusão


��

tenha ocorrido, o marcador que foi ocluso recebe o objeto virtual do marcador que realizou a colisão.- Graphics User Interface (GUI): Este bloco permite ao usuário visualizar graficamente, de modo interativo e em tempo real, a entrada de dados e a saída de informações. A GUI exibe então o cenário, apresentando os ambientes virtuais em Realidade Aumentada em uma janela gráfica por meio de dispositivo de captura de vídeo e saída no monitor.

1.7. Detalhes de ImplementaçãoOs objetos virtuais visualizados no sistema de Realidade Aumentada são baseados nos conceitos da fisiologia vegetal4. Desta forma, com a concepção de objetos virtuais baseados em uma área do conhecimento específica, neste caso a biologia, pode ilustrar o potencial que este protótipo possui para a aplicação em áreas educacionais.

1.7.1. Implementação das Interações de Interface no Ambiente Virtual de R.A.Para a implementação das interações realizadas por meio de marcadores tornou-se necessário a criação de menus de interação na interface de RA, esses menus ficam visíveis na cena gráfica da aplicação sem a utilização de marcadores. A Figura 7 ilustra os objetos virtuais e seus respectivos menus.

Figura 7. Esquema dos menus interativos e seus objetos virtuaisOs menus interativos de um a três podem conter n objetos, porém para a implementação deste software, optou-se por dois objetos por menu. Já o menu interativo de número quatro funciona como um painel de controle para a realização das transformações geométricas por meio de marcadores. A Figura 8 ilustra a relação. Desta forma, dentro da função mainLoop na implementação do ARToolKit “pede-se” para visualizar os objetos na cena gráfica do vídeo. Para proporcionar a opção de dois objetos virtuais por menu, trabalha-se com estruturas de condição. E importante ressaltar que todos os objetos virtuais relacionados devem estar previamente cadastrados. Desta forma, ao incorporar os objetos virtuais, o ARToolKit por meio das bibliotecas libvrml97gl.lib e libARvrml.lib cria na função arVrml97Draw uma lista de objetos virtuais do tipo VRML e, assim por meio desta lista de objetos virtuais pode-se criar várias possibilidades de interatividade.

4 A fisiologia vegetal estuda os fenômenos vitais que concerne às plantas. Estes fenômenos podem referir-se ao metabolismo vegetal; ao desenvolvimento vegetal; ao movimento vegetal ou a reprodução vegetal.


��

Figura 8. Relação de objetos virtuais por menuPara a implementação da opção de troca de objeto virtual por menu, necessitou-se utilizar as propriedades de janelas da biblioteca glut32.lib para criação de um menu suspenso. (menu do tipo Windows). Assim, a Figura 9 ilustra o menu suspenso.

Figura 9. Menu suspenso na Interface de R.AA implementação das interações por meio de marcadores é feita pela colisão de objetos virtuais com o menu de interação quatro (menu 04). Assim, neste sentido, tem-se um marcador para cada transformada geométrica. A colisão trabalhada aqui se trata de uma colisão por aproximação, onde verifica-se a posição do objeto virtual visualizado na cena gráfica e, ao aproximar-se de um valor determinado efetua-se uma função qualquer. A cena gráfica do ARToolKit foi mapeada, assim, quando tem-se um objeto virtual, que neste caso fica invisível, atrelado a um marcador que estiver entre dois valores no eixo “X” e dois valores no eixo “Y”, tem-se efetuada uma colisão aproximada.


��

Assim, entende-se que, ao verificar tal condição, pode-se implementar qualquer tipo de ação e, neste caso, foi implementado funções para realização de transformações geométricas (escala, translação e rotação). Para interação com os menus da interface de R.A., trabalha-se com apenas um marcador para manusear todos os três menus. O marcador em formato de uma “pá” ao fazer a colisão com algum objeto virtual que esteja entre dois valores no eixo “X” e dois valores no eixo “Y”, faz a captura do objeto virtual, ou seja, cria uma instância do objeto que está sendo visualizado na cena gráfica no marcador “pá” que fez a colisão. Ainda, nesta parte da implementação são gravados alguns parâmetros para a distribuição dos objetos virtuais, desta forma, ao se verificar a colisão de algum objeto, os parâmetros do mesmo são gravados em uma variável. Mas adiante, o parâmetro desta variável é distribuído para todas as outras interfaces de RA disponíveis na rede de computadores. É importante ressaltar que existem apenas três menus de interação, porém são seis objetos virtuais para serem visualizados, ou seja, são seis objetos virtuais que podem sofrer colisão do marcador “pá”. Neste aspecto, utilizou-se de estruturas de condição para verificar qual objeto virtual está sendo visualizado no momento da colisão do marcador “pá”. Para implementação da distribuição tornou-se necessário criar uma camada para gravação e leitura dos parâmetros dos objetos virtuais que devem ser distribuídos na rede. Essa camada foi chamada de Camada de Comunicação e é composta de dois módulos. Um dos módulos é chamado de “saída”, este módulo possui duas funcionalidades: para a interface de R.A. é um módulo de leitura, já para a interface de comunicação, é um módulo de gravação. O outro módulo criado é chamado de “entrada”, este módulo também possui duas funcionalidades: para a interface de R.A. é um módulo de gravação, já para a interface de comunicação, é um módulo de leitura. Assim, tanto o código de implementação do módulo “saída”, quando o código do módulo “entrada” devem estar dentro da função “argmainLoop” implementado no ARToolKit. Para o objeto virtual escolhido ser gravado na camada de comunicação, o evento de oclusão de marcadores deve ocorrer. Para este protótipo foi cadastrado no sistema R.A Distribuída o marcador hiro. Desta forma, quando o marcador hiro for ocluso pelo marcador “pá” uma instância do objeto que está anexado ao marcador “pá” será criada no marcador hiro. E, ainda, será disparado um evento para gravação na camada de comunicação de um parâmetro referente ao objeto instanciado.

1.7.2. Implementação da Arquitetura de ComunicaçãoNa implementação da distribuição e comunicação entre os (Ambientes Virtuais) A.V’s de R.A. foi usado um ambiente de programação com suporte ao Visibroker 4.1. A Figura 10 ilustra o diagrama de blocos da plataforma CORBA 2.0. A parte comum para cliente e servidor é o ORB (Object Request Broker). O ORB trata de toda comunicação entre os objetos. Além de cuidar de todo o tráfego de mensagens e corrigir variações de plataforma. De acordo com a Figura 10, o lado do cliente consiste em duas camadas. O bloco cliente é a aplicação que foi escrita pelo desenvolvedor. A parte mais interessante é o stub. O stub é um arquivo gerado automaticamente pelo compilador de IDL (Interface Definition Language). Sua finalidade é apanhar arquivos que descrevem as interfaces do servidor e gerar código que possa interagir com o ORB da plataforma CORBA 2.0. O arquivo de stub contém uma ou mais classes que “espelham” o servidor CORBA 2.0. As classes contêm as mesmas interfaces publicadas e tipos de dados que são expostos pelo servidor. O cliente usa classes stub a fim de se comunicar com o servidor. As classes stub atuam como um proxy para os objetos servidores. O símbolo


��

arredondado no bloco de stub representa uma conexão com o servidor. A conexão é estabelecida por meio de uma chamada de ligação emitida pelo cliente. O stub invoca a chamada, por meio de sua referência ao objeto servidor, usando o ORB. Quando o servidor responde, a classe stub recebe a mensagem do ORB e entrega a resposta de volta ao cliente. O cliente também pode chamar algumas funções no ORB. O lado servidor contém uma interface ORB chamada de adaptador básico de objetos (Basic Object Adaptor – BOA). O BOA é responsável por “rotear” as mensagens do ORB para a interface de esqueleto. O esqueleto é uma classe gerada pelo compilador IDL, assim como o stub. O esqueleto contém uma ou mais classes que publicam as interfaces CORBA no lado do servidor.

Figura 10. Plataforma para distribuição CORBA 2.0Existe outro arquivo, que contém as classes que representam os detalhes funcionais do servidor. Este é conhecido como arquivo IMPL (implementação). Quando uma mensagem chega ao lado do servidor, o ORB passa um buffer de mensagem ao BOA, que, por sua vez, passa o buffer à classe do esqueleto. O esqueleto desembrulha os dados do buffer e determina qual método deve ser chamado no arquivo IMPL. O esqueleto apanha os resultados de retorno e os conduz de volta ao cliente. Como existe apenas um tipo de ambiente virtual e, neste se faz necessário distribuir por meio de replicação ou particionamento, a metodologia aplicada resume-se em implementar as duas partes (cliente e servidor), sendo que a aplicação-cliente fica junto com a aplicação do ambiente virtual de R.A., e o servidor ficaria responsável por controlar os clientes e as informações dos mesmos. A primeira aplicação iniciada na rede sempre faz a requisição de um servidor. Outras aplicações iniciadas usam o mesmo servidor. Para este protótipo, a implementação está dividida em duas fases: a) criação de uma interface para o objeto, pois todo objeto CORBA é descrito por sua interface; b) a segunda fase consiste em escrever o código respectivo a cada método declarado na interface. A aplicação servidora necessita publicar declarações de tipo, interfaces e métodos específicos num projeto puramente orientado a objeto. Esta descrição de interface foi escrita na linguagem de Definição de Interface (IDL – Interface Definition Language) e traduzida para a linguagem específica, por meio de um compilador. A idéia principal do protótipo de distribuição deste trabalho é usar um servidor para armazenar as informações de seus clientes. Porém, a abordagem (protótipo) desenvolvida possui uma característica específica. A aplicação de distribuição não está anexada na aplicação de interface de R.A., possuindo uma camada de comunicação entre as aplicações. Desta forma, os parâmetros para distribuição são gravados na camada de comunicação


��

pela interface de R.A. e, assim, a aplicação-cliente fica lendo essas informações que são enviadas para a aplicação-servidora que, por sua vez faz a distribuição para todas as outras aplicações-clientes ativadas na rede de computadores. Desta forma, em cada computador de uma rede possui uma aplicação-cliente para a distribuição, uma interface de R.A. e uma camada de comunicação para gravar e ler os objetos virtuais que deverão ser visualizados na cena gráfica.

1.8. Funcionamento do Sistema e Estudo de Caso

1.8.1. Estudo de CasoFisiologia Vegetal: Fisiologia Vegetal é a ciência que se propõe a explicar todos os processos da vida por meio de princípios da física e da química (Awad et al., 1993). Isto quer dizer que o objetivo básico da fisiologia vegetal é tentar explicar qualquer processo que se realiza na planta em bases físicas e químicas. A fisiologia vegetal é realmente o estudo da planta em trabalho (Taiz, 2006). Um dos objetivos básicos é a determinação da natureza química precisa de todos os materiais encontrados na planta e o caminho que ela segue para obtê-los ou faze-los. Isso é a bioquímica da planta. O outro objetivo é o conhecimento de toda espécie de trabalho feito pela planta (mecânico, químico,osmótico, elétrico) e a natureza da energia envolvida. Isso é a biofísica da planta. Mesmo a bioquímica da planta sempre envolve mudanças energéticas. Assim, o denominador comum de todos os aspectos da fisiologia da planta é o trabalho e a energia (Taiz, 2006).Transporte de Solutos: O sistema de condução de materiais pelos corpos dos seres vivos deve garantir a distribuição de nutrientes e retirada de substâncias tóxicas das células dos tecidos de todo o organismo (Taiz, 2006). Nos vegetais a condução de solutos (Seiva), isto é, soluções salinas e soluções açucaradas, é realizada por meio dos sistemas de vasos, que se distribuem ao longo do corpo das plantas. A distribuição de seiva bruta ou inorgânica (água e sais minerais) é realizada pelos vasos de xilema ou lenho. A distribuição de seiva elaborada ou orgânica (água e açúcares) é realizada pelos vasos de floema ou líber.

1.8.2. Camada de Distribuição

Figura 11. Cliente da aplicação de distribuição

Não há nenhuma interface na aplicação servidora, pois a mesma funciona apenas distribuindo as informações recebidas dos clientes. Já a aplicação cliente, recebe as informações enviadas pelo servidor e grava em uma Camada de Comunicação para que


��

a interface de RA leia essas informações e faça a visualização do objeto virtual na cena gráfica. Desta forma, a Figura 11 ilustra a aplicação de distribuição cliente.Onde: (1) Mostra para o usuário se a aplicação está conectada, ou não, retorna dois valores: conectado ou desconectado; (2) Mostra informações sobre a leitura e gravação na camada de comunicação, caso haja algum erro na leitura, o tipo de erro é informado; (4) Mostra qual objeto está sendo lido e enviado para a aplicação de interface de R.A. visualizar na cena gráfica. Desta forma, a camada de comunicação resume-se a dois módulos, de entrada e de saída de informações para as aplicações distribuídas e para a interface de R.A.

1.8.3. Interface de Realidade AumentadaA aplicação de interface de R.A. possui três menus visualizados na cena gráfica (sem a utilização de marcadores), cada um desses menus pode, nesta aplicação, possuir dois objetos virtuais. A Figura 12 ilustra a interface de Realidade Aumentada.

Figura 11. Aplicação de Interface de R.A

Onde: (1) Primeiro Menu: possui dois objetos virtuais, um tronco cortado com vasos de transporte de solutos no seu interior e, um objeto ilustrando apenas os vasos de transporte; (2) Segundo Menu: possui dois objetos virtuais, um galho transparente com os vasos de transporte de solutos no seu interior e, um galho sem os vasos e também sem transparência; (3) Terceiro Menu: possui um estroma com detalhamento do processo da fotossíntese e da evaporação de água no processo do transporte de solutos e, um estroma sem detalhamento; (4) Quarto Menu: possui interatividade por meio das transformações geométricas, trabalhando com colisão de marcadores. Para tanto, têm-se um marcador para casa tipo de transformada geométrica; (5) Menu Suspenso: possui as rotinas para trocar o objeto virtual de qualquer um dos três menus visualizados na cena gráfica em tempo real; (6) Objeto virtual tronco cortado sobreposto sobre a árvore real:


��

esse tronco cortado ilustra o transporte de seiva (solutos) no interior de uma árvore. Esse transporte de solutos é baseado no estudo de caso apresentado nos itens fisiologia vegetal e transporte de solutos descritos neste artigo; (7) Camada de Distribuição da Aplicação.Como ilustrado na Figura 12, ao se instanciar um objeto virtual em um dos três menus interativos, o parâmetro de referência do objeto virtual é gravado na camada de comunicação e, automaticamente a camada de distribuição faz a leitura dos parâmetros gravados e, informa para o usuário qual objeto virtual está sendo lido. Observe na Figura 12, o parâmetro do objeto virtual selecionado é o quatro. Para a distribuição, os clientes devem estar com o marcador padrão de distribuição disposto na imagem capturada pelo sistema de Realidade Aumentada. Desta forma, ao identificar o marcador padrão, já previamente cadastrado e, também identificar que existe um objeto virtual para ser visualizado, automaticamente o objeto virtual é mostrado pela interface de Realidade Aumentada sobre o marcador.

Figura 12. pegando objeto virtual no menu

A interface de Realidade Aumentada também permite a realização de transformações geométricas dos objetos virtuais selecionados na cena gráfica. As transformadas geométricas podem ser realizadas por meio de teclado, ou ainda por meio do menu interativo utilizando-se para isso marcadores previamente cadastrados. Para a utilização do menu interativo, deve-se possuir um marcador para cada transformada geométrica.

1.9. Avaliação, Resultados e Potencialidade da AplicaçãoPara a avaliação e validação da aplicação R.A. Distribuída foi elaborado, com base em preceitos da ISONORM 9241-10 Usability (Prugmper, 1999) (conjunto de normas que permite avaliar a capacidade de um sistema interativo oferecer ao usuário a possibilidade de realizar tarefas de maneira eficaz e agradável) um questionário em


��

forma de um checklist onde os usuários puderam informar suas opiniões. Este questionário teve por objetivo verificar questões sobre usabilidade do sistema desenvolvido e, ainda quando da concepção do questionário utilizou-se conceitos pedagógicos e, de software educacional (Campos, 1998). Assim, o questionário foi aplicado a uma amostra de 80 indivíduos em potencial. Foram escolhidos aleatoriamente alunos e professores do curso de informática de uma Instituição de Ensino Superior. Ainda, foram abordados pedagogos, também professores do curso de Biologia. Assim, a amostra compõe-se de: 10 professores pedagogos, 10 professores biólogos, 10 professores do curso de informática e 50 alunos dos cursos de informática. Todos foram submetidos ao software e responderam ao mesmo questionário.Desta forma, os professores do curso de pedagogia relataram que é boa a relação entre o que é proposto, e o que o software realiza, porém, ainda há a necessidade de melhorias nas questões de implementação para ser aplicado à educação. A maioria dos usuários sentiram-se satisfeitos com a distribuição realizada pelo software e, realmente entenderam o propósito da aplicação. Desta forma, entende-se que por meio deste questionário, é possível afirmar que o software RA Distribuída apresentado neste trabalho é viável e, que pode ser utilizado em aplicações educacionais de forma geral, porém, de acordo com os pedagogos, cabe uma análise mais aprofundada das questões pedagógicas/educacionais.

Figura 13. Gráfico: Visão Geral da avaliação do sistema

Em relação ao questionário geral os profissionais da biologia, pedagogia e informática entenderam ser necessário um melhor detalhamento dos objetos virtuais e, ainda, uma interface que possua mais informações sobre os objetos virtuais visualizados em cena. De forma geral, a avaliação foi positiva contendo críticas construtivas para a melhoria do software e, ainda a avaliação referente a usabilidade da interface do software obteve excelente aprovação por todos os usuários. A Figura 13 ilustra um gráfico que resume todas as 14 questões aplicadas.

1.9.1. Considerações Finais e Tendências FuturasDurante esta pesquisa, constatou-se que existem diversos ambientes virtuais distribuídos. Porém, a maioria desses ambientes apresenta foco na distribuição e comunicação de réplicas e, ainda, a maioria dos ambientes é em Realidade Virtual. Ainda, um fator de grande relevância observado é a falta de flexibilidade dos objetos virtuais em relação à sua interface e em relação a distribuição destes objetos.


��

Desta forma, esta pesquisa apresenta um sistema com grande vocação educacional que usa Realidade Aumentada de forma distribuída permitindo que vários usuários manipulem ao mesmo tempo objetos virtuais dentro de cenários reais capturados por câmeras de vídeo. Sendo assim, foi apresentada uma arquitetura para o sistema proposto e implementado um estudo de caso que apresenta o processo de transporte de solutos (seiva). Para tal, foram criadas três camadas de software para proporcionar um único ambiente de Realidade Aumentada Distribuída. Como conclusões da implementação do sistema e como tendências, pode-se citar:- A plataforma CORBA se mostrou capaz de atender os requisitos para distribuição de ambientes de Realidade Aumentada, porém, para ambientes de Realidade Aumentada com tendências futuras pode-se utilizar CORBA em tempo real para a distribuição.- A interface de Realidade Aumentada implementada proporciona um bom nível de interatividade e, possibilita a distribuição de objetos virtuais, porém, para implementação de Interfaces de Realidade Aumentada pode-se utilizar o OSGART.Desta forma, percebe-se que não há diferenças na distribuição entre ambientes de Realidade Virtual e Realidade Aumentada. Entende-se e constata-se por meio desta pesquisa que a diferença básica está na implementação das interfaces de Realidade Aumentada e Realidade Virtual, pois o que é distribuído, neste caso, são passagens de parâmetros. Neste contexto, uma implementação de interface bem feita, resulta em um ambiente virtual muito mais interativo. Assim, essas interatividades podem ser distribuídas em uma rede de computadores em forma de parâmetros. Esses parâmetros podem referir-se a objetos virtuais, transformações geométricas ou a qualquer outro aspecto relacionado aos ambientes virtuais. A distribuição de ambientes virtuais de Realidade Aumentada, quando trabalhada corretamente, com todas as requisições e restrições de usuários para inserção e manipulação de objetos virtuais na cena, pode proporcionar um ambiente altamente interativo e colaborativo. Assim, entende-se que a principal contribuição deste trabalho é a junção de um Pipeline de interações da interface de Realidade Aumentada com a Arquitetura de Distribuição feita por meio de uma Camada de Distribuição. Assim, pode-se proporcionar um ambiente virtual de Realidade Aumentada Distribuído, onde as camadas de interface de Realidade Aumentada e a Aplicação de Distribuição são conectadas por uma Camada de Comunicação. Este Ambiente de Realidade Aumentada pode ou não ser utilizado com dispositivos de projeção e de manipulação de informações tais como o capacete e luvas.

ReferênciasAwad, Marcel et al. “Introdução à Fisiologia Vegetal”. São Paulo: Nobel, 1993.Azuma, R, et al. “Recent Advances in Augmented Reality. IEEE Computer Graphics

and Applications, november/december 2001, Vol. 21, P. 34-37.Azuma, R. T.. “A Survey of Augmented Reality”, Presence: Teleoperators and Virtual

Environments, Vol. 6, P. 355- 385. 1997Baranauskas, M. C. C.; Rocha, H. V. (2003) “Design e Avaliação de Interfaces

Humano–Computador”. Campinas – SP: Nied/Unicamp, 2003.


��

Billinghurst, M. “Augmented Reality in Education”. New Horizons for Learning. Fevereiro de 2005. Disponível em: <http://www.newhorizons.org>. Acesso em: 10 fevereiro de 2008.

Billinghurst, Mark; Kato, Hirokazu e Poupyrev, Ivan. “The Magicbook: a transitional AR Interface. IEEE Computer Graphics and Applications. Projects In VR, 2001.

Campos, Fernanda. Dez etapas para o desenvolvimento de Software Educacional do tipo Hipermídia. Núcleo de Informática na Educação Especial, UFRGS, 1998. Disponível em: < http://www.niee.ufrgs.br/ribie98 >. Acesso em 16 jan. 2008.

Cardoso, Alexandre, et al. “Conceitos de Realidade Virtual e Aumentada”. In: Tecnologias para o desenvolvimento de sistemas de Realidade Virtual e Aumentada. Recife: ed. Universitária da UFPE, 2007.

Costa, Samira Rachid da. “Objetos Distribuídos: conceitos e padrões”. Instituto Nacional de Pesquisas Espaciais. Ministério da Ciência e Tecnologia, 2000.

Dainese, C.A. “Sistema de Realidade Aumentada para o desenvolvimento da criança surda”, In:VI Symposium on Virtual Reality:, 2003. Ribeirão Preto - SP. SBC, 2003. P.273-281.

Garbin, T.R., Dainese, C.A., Kirner, C., Santos, A.M., Jesus, M.A. “Avaliação de interface de um sistema de Realidade Aumentada para a criança surda com base no construcionismo Anais do 1º Workshop de Realidade Aumentada, Piracicaba, SP, maio de 2004, P. 33-36.

Hesina, Gerd; Schmalstieg, Dieter. “Distributed Applications for Collaborative Aumented Reality”. IEEE Computer Society. Virtual Reality, 2005.

Jing, Zhang; et al. “Researches on Model of Navigation in Cve”. Gis Development - Technology Laboratory, may 2005. Disponível em: <http://www.gisdevelopment.net> . Acesso em: 13 janeiro de 2008.

Kalawsky, R.S. “Exploring Virtual Reality Techniques in Education and Training: technological issues”. Advanced VR Research Centre, Lough-Borough, University of Tecnology, 1993.

Kato, H.; Billinghurst, M. et. al. “Artoolkit Version 2.52: A Software Library for Augmented Reality Applications”. HITLAB – Human Interface Technology Laboratory. Junho de 2005. Disponível em: <http://www.hitl.washington.edu/>. Acesso em: 10 janeiro de 2007.

Kirner, C. ; Tori, R. “Introdução à Realidade Virtual, Realidade Misturada e Hiper-Realidade”. In: Cláudio Kirner; Romero Tori. (ed.). Realidade Virtual: conceitos, tecnologia e tendências. 1ª ed. São Paulo, 2004, V. 1, P. 3-20.

Kirner, Cláudio. “ARToolKit versão 2.52”. Realidade Virtual e Aumentada, Abril de 2008. Disponível em: < http://www.realidadevirtual.com.br >. Acesso: maio 2008.

Lévy, Pierre. “O que é virtual?”, tradução de Paulo Neves, São Paulo: Ed. 34, 1999.Milgram, P. et. al. “Augmented Reality: a class of displays on the Reality-Virtuality

Continuum”. Telemanipulator and Telepresence Technologies, SPIE, V.2351, 1994.Pinho, Márcio Serolli. “Realidade Virtual como ferramenta de informática na

educação”. Grupo de Realidade Virtual da PUC-RS, outubro de 1996. Disponível em: <http://grv.inf.pucrs.br/educa.htm >. Acesso em: 02, jun. 2007.


��

Prugmper. Test It: ISONORM 9241/10. In: H.-J. Bullinger & J. Ziegler Eds. Proceedings of HCI International, Munich, 22-27 August 1999. Mahwah, NJ: Lawrence Erlbaum. 1999.

Ribeiro, Marcos Wagner de Souza. “Arquitetura para Distribuição de Ambientes Virtuais Multidisciplinares”, Uberlândia, Faculdade de Engenharia Elétrica - UFU, 2006, 176p.

Rinaldi, Cristina Alves; et al. “Ambientes Virtuais Distribuídos e Compartilhados”. In Tori, Romero; Kirner, Cláudio; Siscoutto, Robson. Fundamentos e Tecnologia de Realidade Virtual e Aumentada. Porto Alegre. Editora SBC, 2006.

Sementille, A. C. A “Utilização da Arquitetura CORBA na construção de Ambientes Virtuais Distribuídos”. 1999. 186f; Tese (Doutorado Em Física Computacional) – Instituto de Física de São Carlos, USP. São Carlos, 1999.

Sementille, A. C., et. al. “Ambientes Virtuais Distribuídos usando CORBA: Um Estudo de caso”. In: III Workshop de Realidade Virtual – WRV’2000, 3, 2000, Gramado-RS. Procedings. Gramado-S, 2000.P.145-156.

Siqueira, Luiz Leonardo de. “Estudo Comparativo entre Plataformas de Suporte a Ambientes Virtuais Distribuídos”, Uberlândia, Faculdade De Engenharia Elétrica – UFU, 2005, 89p.

Taiz, Lincoln. “Fisiologia Vegetal”. São Paulo: Artmed, 2006.Teixeira, S. Delphi 6, “O Guia do Desenvolvedor”. Rio de Janeiro: Campus, 2002. Tori, Romero; Kirner, Cláudio; Siscoutto, Robson. “Fundamentos e Tecnologia de

Realidade Virtual e Aumentada”. Porto Alegre: SBC, 2006.Valente, J.A. “Aprendendo para a vida: o uso da Informática na Educação especial”. In

Valente, J.A. Aprendendo para a vida: os computadores na sala de aula. São Paulo. Cortez Editora, P.29-42, 2001.

Zhou, Zhiying; et al. “Interactive Entertainment Systems Using Tangible Cubes”. IEEE Computer Society. Virtual Reality, 2004.


��

Uma abordagem de c

´

odigo ´unico para aplicac

˜

oes

independentes de provedor de bases de dados relacionais

Willian Eduardo de Moura Casante

1

1Fundacao CPqD – Centro de Pesquisa e Desenvolvimento em TelecomunicacoesRod. SP-340 km 118,5 CEP 13.086-902 – Campinas – SP – Brasil

[email protected]

Abstract. Relational databases uses specific SQL extensions for their productfunctions, which makes the development of complex applications unfeasiblemainly because compatibility with more than one relational database would re-quire specific codes for each database. This paper describes the developmentof multi-database applications based on a methodology of creation of the ins-tallation artifacts for the database and a technique to develop multi-databasesources codes.

Resumo. Os bancos de dados relacionais fornecem funcionalidades especıficasde produtos atraves de extensoes da linguagem SQL, inviabilizando o desenvol-vimento de aplicacoes complexas e compatıveis com mais de um banco de da-dos relacional sem que essas aplicacoes tenham codigo especıfico para cada umdeles. Este artigo aborda o desenvolvimento de aplicacoes totalmente indepen-dentes de banco de dados atraves de uma metodologia de criacao de artefatosde instalacao da estrutura de dados e de uma tecnica de desenvolvimento decodigo-fonte independentemente de produto.

1. Introduc

˜

ao

A linguagem SQL (Structured Query Language) [Chamberlin et al. 1981] e uma lingua-gem de pesquisa e definicao de estrutura de dados, inicialmente criada para SGBDs (Sis-temas Gerenciadores de Banco de Dados), fortemente inspirada na algebra relacional[Elmasri et al. 2005].

Necessidades nao mapeadas no padrao SQL desenvolvido e aceito pela industriaexigiram dos fabricantes de SGBDs a definicao de construcoes SQL especıficas para seusprodutos e a criacao de extensoes da linguagem que possibilitam o acesso das suas funci-onalidades proprietarias.

Essas diferencas entre as diversas implementacoes da linguagem SQL prejudicamo desenvolvimento de um sistema computacional compatıvel com dois ou mais SGBDspois, para cada SGBD atendido, um conjunto de arquivos especıficos para aquele deveraser mantido, tanto para a instalacao do sistema quanto para o funcionamento correto deseu codigo-fonte.

2. An

´

alise da incompatibilidade entre SGBDs

Um sistema computacional que realiza o armazenamento de suas informacoes em SGBDspossui seus arquivos de instalacao organizados em DDLs (Data Definition Language) eDMLs (Data Manipulation Language).


��

DDL e um arquivo de metadados, que define a estrutura das tabelas de um bancode dados, composto por comandos SQL como, por exemplo, CREATE, ALTER e DROP.Os arquivos do tipo DDL sao os primeiros a serem executados durante a instalacao de umsistema computacional, visto que criam o arcabouco do sistema no SGBD.

DML e um arquivo de dados, cuja estrutura respeita fielmente a estrutura definidaem seu respectivo arquivo DDL. Durante o desenvolvimento de um sistema pode, se ne-cessario, inicializar o banco de dados; essa inicializacao e colocada em arquivos do tipoDML. Os arquivos DML possuem comandos de INSERT, UPDATE, DELETE e SELECT,tambem utilizados de forma embutida dentro do codigo-fonte do sistema.

2.1. A estrutura dos dados em um SGBD

Durante a analise de um sistema, uma das tarefas e a definicao de seu modelo de bancode dados. Essa definicao normalmente envolve a construcao de entidades basicas dosistema, em uma linguagem visual de alto nıvel, como, por exemplo, o modelo deentidades e relacionamentos [Barbieri 1994] ou a UML (Unified Modeling Language)[Jacobson et al. 1996]. Um exemplo simples de modelo UML pode ser observado naFigura 1. Atraves desse modelo inicial, os analistas de sistemas realizam um aprofunda-mento na modelagem, atraves da definicao de todas as entidades e de seus relacionamen-tos, para que o sistema possa ser construıdo sobre esse modelo proposto. Conforme osistema e desenvolvido, novas entidades e relacionamentos sao incluıdos e estes, detalha-dos e entao o sistema evoluıdo para os contemplar.

Figura 1. Exemplo de modelagem via UML

A partir da definicao grafica das entidades do modelo de banco de dados, um espe-cialista devera gerar um ou mais arquivos DDL, contendo os comandos SQL equivalentes


��

para a criacao daquele modelo em um SGBD especıfico. Existem ferramentas que ge-ram automaticamente esses arquivos a partir dos diagramas propostos, que estao fora doescopo deste artigo.

Um sistema que se propoe a ser instalado em mais de um SGBD apresenta algumasestrategias que podem ser adotadas, para a criacao de seus arquivos DDL:

• Criacao de um ou mais arquivos DDL por SGBD – exige a replicacao de artefatosde trabalho (arquivos DDL) para cada um dos SGBDs; adiciona risco de erro naconversao, caso realizada de forma manual, como o risco da falta de sincronia en-tre as atualizacoes dos artefatos. Como exemplo, um profissional obtem uma DDLpara o SGBD Oracle e deve converte-la para funcionar no SGBD PostgreSQL ecausa um erro ao nao trocar NUMBER(20) por NUMERIC(20);

• Criacao de um unico arquivo DDL para um SGBD e utilizacao de uma ferra-menta de conversao para os outros SGBDs – a conversao por ferramenta mitigaos possıveis erros porem adiciona um passo a geracao do pacote de instalacao dosistema: a conversao dos arquivos DDL. A existencia de uma ferramenta que rea-lize essa conversao, bem como sua aquisicao, caso seja comercial, e um requisitoprimario, que pode ser substituıdo pelo desenvolvimento da propria ferramenta,como realizado no desenvolvimento da ferramenta JExodus [Neto and Passos ];

• Geracao automatica de modelo atraves de codigo-fonte – alguns arcaboucos deprogramacao (por exemplo a especificacao EJB (Entity JavaBean) do Java EE[Patel et al. 2006]) permitem a definicao de entidades programaticas e a geracaodo modelo de banco de dados de forma transparente. Esse formato nao e apro-veitavel em sistemas que necessitam controlar com precisao seus modelos debanco de dados ou realizar atualizacoes pois a instalacao e a definicao do mo-delo ficam a encargo do arcabouco. Pode haver conflito no que diz respeito aseguranca, onde a instalacao da estrutura do banco de dados ficar a cargo de umadministrador do SGBD, ou durante a execucao, se o sistema obtiver uma conexaona qual apenas controla a atualizacao dos dados neste SGBD.

2.2. A manutenc

˜

ao dos dados em um SGBD

A definicao da estrutura, ou modelo, de um sistema em um SGBD, conforme descritona Subsecao 2.1, devera permitir a insercao, alteracao, exclusao e consulta dos dadospresentes nessa estrutura. Para realizar essas operacoes existem os comandos DML.

A instalacao de um sistema pode necessitar de dados iniciais, inseridos durante apropria instalacao ou configurados por uma equipe de implantacao, dados estes presentesem scripts DML e tambem, durante a utilizacao do sistema, realiza esses comandos noSGBD para que os dados sejam manipulados na citada estrutura.

Portanto, podemos listar dois cenarios a serem tratados:

• A criacao dos dados iniciais em uma estrutura, durante a instalacao de um sis-tema, cujos comandos DML deverao ser compatıveis com diversos SGBDs ouconvertidos conforme necessidade;

• O ciclo de producao do sistema, pos-instalacao, no qual o sistema emitira co-mandos DML para a manipulacao dos dados presentes na estrutura instalada. Es-ses comandos deverao ser genericos ou estruturados de forma que o sistema nao


��

conheca as diferencas entre os diversos SGBDs e suas peculiaridades, permitindoque o codigo-fonte, geralmente em linguagem de alto nıvel (como o Java), sejaunico e independente de SGBD.

2.3. Linguagens espec´ıficas

Cada SGBD pode prover uma ou mais linguagens de programacao especıficas, conheci-das como linguagem de script, nas quais e possıvel adicionar logica de programacao alemdos comandos DDL e DML. Essas linguagens (por exemplo, o PL/SQL do SGBD Ora-cle [Feuerstein 2002]) possuem sintaxe proprietaria e muitas vezes de difıcil conversaoautomatica entre os diversos SGBDs.

Podem ser definidas funcoes (Stored Procedures), diretamente no SGBD,utilizando-se essas linguagens de programacao e realizar a chamada dessas funcoes di-retamente do codigo-fonte do sistema.

3. Arquiteturas pass´ıveis de utilizac

˜

ao

Enumeram-se algumas possıveis arquiteturas de acesso e manutencao dos dados demultiplos SGBDs, para um sistema de software:

• Desenvolvimento tradicional – com projeto de banco de dados, geracao de ar-quivos DDL e DML, controle manual das alteracoes e controle de arquivos porSGBD;

• Arcabouco de desenvolvimento, como o Ruby on Rails [St.Laurent et al. 2012] ouo Java Persistence API [Patel et al. 2006], nos quais o proprio arcabouco trata acriacao e a evolucao do banco de dados;

• Metodologia proposta neste artigo, que unifica os itens citados anteriormente namanutencao de uma unica base de artefatos relativos a base de dados.

4. Adotando uma metodologia ´unica

A metodologia, proposta na Figura 2, une o desenvolvimento tradicional aos arcaboucosde desenvolvimento, aproveitando o seu melhor sem limitar-se as fronteiras impostas pe-los arcaboucos, facilitando assim o uso em sistemas de grande porte, que exigem a mode-lagem de bases de dados extremamente complexas.

A premissa para o desenvolvimento do sistema e a capacidade de este ser execu-tado em dois ou mais SGBDs. Se essa necessidade nao existir, o desenvolvimento tradi-cional podera ser adotado. Do mesmo modo, se a complexidade da estrutura de dados forbaixa, independentemente do tamanho do sistema, sera possıvel utilizar por completo ecom todas as vantagens, um dos arcaboucos de desenvolvimento agil (como, por exemplo,o Ruby on Rails).

4.1. Definic

˜

ao de um SGBD “base”

Antes de iniciar o desenvolvimento, para determinar o SGBD “base”, no qual os arqui-vos DML e DDL serao escritos, deverao ser realizados uma pesquisa e um estudo dasferramentas disponıveis para conversao de cada SGBD suportado pelo sistema. Muitasferramentas requerem de licenca de uso, o que deve ser levado em conta na analise e natomada de decisao. Pode-se chegar a conclusao de que nao ha ferramenta compatıvel comos requisitos impostos, e, nesse caso, sera utilizada a conversao manual. E recomendaveladicionar ao projeto o risco de defeitos causados pela conversao manual dos artefatos.


��

Figura 2. Metodologia sugerida para o desenvolvimento do sistema

4.2. Definic

˜

ao dos arcaboucos de programac

˜

ao

Uma vez conhecida a linguagem de programacao na qual o sistema sera desenvolvido,aconselha-se escolher tambem um arcabouco de abstracao de acesso aos dados. Essesarcaboucos abstraem detalhes dos diversos SGBDs suportados, padronizam o codigo-fonte, e facilitam o desenvolvimento do acesso aos dados, pois normalmente oferecemfacilidades para tal.

Deve ser feito um estudo de uso, conforme feito por Viana e Borba[Viana and Borba 1999], a partir de arcaboucos atuais da linguagem de programacaoescolhida (por exemplo, para o Java, o Hibernate [Bauer and King 2005] ou aespecificacao Java Persistence API [Patel et al. 2006]), para determinar o melhor con-junto de arcaboucos. Caso os SGBDs escolhidos suportem a orientacao a objetos[Boscarioli et al. 2006], deve-se observar se os arcaboucos de programacao escolhidospossuem o suporte necessario para as funcionalidades que serao utilizadas.


��

4.3. Ciclo de vida do sistema

Definidos o SGBD “base” e a ferramenta de conversao para os outros SGBDs (se for ocaso), sao gerados os scripts DML e DDL e realizadas as conversoes necessarias, con-forme o sistema e desenvolvido. Eventuais scripts de atualizacao de versao do sistemaprecisarao ser escritos para cada SGBD, pois muitas vezes envolvem migracao de dados.

O uso de funcoes SQL diretamente em banco de dados deve ser evitado, poisaumenta a complexidade da solucao, exigindo sua manutencao para cada SGBD, bemcomo a coerencia entre as diferentes codificacoes, inerentes a cada SGBD.

E importante que todos os envolvidos no desenvolvimento do sistema sigam oprocesso a partir das solucoes adotadas, tanto para a conversao entre os diversos SGBDsquanto para o desenvolvimento do proprio sistema na sua linguagem de programacao.Esse cuidado garante que todos trabalhem para que a aplicacao continue compatıvel comcada SGBD escolhido.

O teste sistemico devera ser realizado com o sistema instalado em cada SGBD,garantindo assim que esteja compatıvel com todos.

E importante entender que, quanto maior o nıvel de abstracao oferecido peloarcabouco escolhido e de automacao na conversao entre os SGBDs menor o risco deincompatibilidade entre eles. Para um sistema totalmente abstraıdo em relacao ao seumodelo relacional, o teste sistemico podera ser realizado por amostragem, sendo queos casos de teste sao executados parcialmente em um SGBD e parcialmente em outro,evitando que seja necessario realizar todos os casos de teste em todos os SGBDs, comexpressivo ganho de tempo durante seu desenvolvimento.

5. Prova de conceito

Para a realizacao da prova de conceito foi considerado um sistema inicialmente construıdopara o SGBD Oracle, que deveria ser compatıvel tambem com o SGBD PostgreSQL.O requisito de “portabilidade” entre ambos SGBDs, durante a vida do sistema e suasevolucoes, possibilitou a aplicacao da metodologia definida na Secao 4, garantindo a qua-lidade dos artefatos gerados e a ausencia de impacto nos prazos de entrega, eliminandotambem o risco produzido por conversoes manuais realizadas pelos desenvolvedores.

A estrutura adotada, para os artefatos gerados para o projeto e apresentada naFigura 3.

Conforme apresentado na Secao 2, existem arquivos DDL, de instalacao da estru-tura de tabelas do sistema e arquivos DML, que realizam a populacao dos dados iniciaisnecessarios para o funcionamento do sistema, bem como os comandos DML presentesem codigo-fonte, no caso, escrito em Java.

Os comandos DDL, originalmente em Oracle, foram convertidos utilizando-se aferramenta Ora2Pg [Ora2Pg 2012]. Esses arquivos precisam inicialmente ser instaladosem um SGBD Oracle para que a ferramenta consiga extrair as DDLs no formato Post-greSQL. Da mesma forma que as DDLs, as DMLs de carga do sistema foram instaladasno banco de dados Oracle e extraıdas com a mesma ferramenta para o formato Post-greSQL.

Os arquivos DDL e DML gerados para o PostgreSQL sao colocados em controle


��

Figura 3. Estrutura do projeto da prova de conceito

de versao, sendo disponibilizados para a instalacao, juntamente com o produto. Dessaforma o instalador podera optar por fazer a instalacao em um SGBD Oracle ou Post-greSQL, utilizando para isso um unico pacote de instalacao.

Funcoes SQL podem ser criadas diretamente em banco de dados e poderao serutilizadas, a partir do codigo-fonte Java, atraves do padrao de projeto DAO (Data AccessObject) [Alur et al. 2003]. Essas funcoes devem ser criadas com uma mesma assinaturade chamada, mesmo que para diferentes SGBDs, para que a chamada possa ser unica e aconstrucao do DAO independente do SGBD, bem como devem ser construıdas para todosos SGBDs definidos.

O sistema foi construıdo totalmente sobre o arcabouco Java EE EJB e todas as en-tidades de banco de dados foram mapeadas utilizando-se as funcionalidades de abstracaofornecidas por esse arcabouco. Todas as consultas a essas entidades foram construıdasutilizando-se a linguagem de consulta JPQL (Java Persistence Query Language), queabstrai a linguagem SQL, garantindo que o codigo-fonte Java seja unico e independentedo SGBD adotado.

O resultado da prova de conceito e um sistema capaz de trabalhar tanto no SGBDOracle quanto no SGBD PostgreSQL, com um unico pacote de instalacao e um unicocodigo-fonte, sendo que os processos de conversao entre esses SGBDs sao completamenteautomatizados, validando a metodologia proposta.

6. Conclus

˜

ao

Propor uma solucao para a abstracao de acesso aos dados de um SGBD, bem como cen-tralizar e automatizar a geracao de comandos de definicao do modelo relacional, garantea longevidade do sistema desenvolvido. O sistema torna-se independente de SGBD, per-mitindo a reducao dos custos de implantacao pela adocao de solucoes de software livresem adaptacoes do codigo-fonte original ou mesmo troca estrategica do SGBD. O co-nhecimento dos desenvolvedores envolvidos na producao do sistema pode ser nivelado,pois nao sao mais necessarios especialistas para cada SGBD, os riscos sao mitigados e os


��

pontos passıveis de erro reduzidos.

Por fim, a automacao da geracao e do controle dos artefatos de cada SGBD evitaerros relacionados a migracao de codigo-fonte especıfico de determinado SGBD, que saomaiores no caso de migracao manual, bem como reduz o custo do desenvolvimento poreliminar as horas necessarias para a conversao.

Refer

ˆ

encias

Alur, D., Crupi, J., and Malks, D. (2003). Core J2EE patterns: best practices and designstrategies. Prentice Hall.

Barbieri, C. (1994). Modelagem de Dados. IBPI Press Rio de Janeiro.

Bauer, C. and King, G. (2005). Hibernate in action. Manning.

Boscarioli, C., Bezerra, A., Benedicto, M., and Delmiro, G. (2006). Uma reflexao sobrebanco de dados orientados a objetos. IV CONGED.

Chamberlin, D., Astrahan, M., Blasgen, M., Gray, J., King, W., Lindsay, B., Lorie, R.,Mehl, J., Price, T., Putzolu, F., et al. (1981). A history and evaluation of system r.Communications of the ACM, 24(10):632–646.

Elmasri, R., Navathe, S., Pinheiro, M., Canhette, C., Melo, G., Amadeu, C., and de Oli-veira Morais, R. (2005). Sistemas de banco de dados. Pearson Addison Wesley.

Feuerstein, S. (2002). Oracle pl/sql Programming. O’Reilly.

Jacobson, I., Booch, G., and Rumbaugh, J. (1996). The Unified Modeling Language.University Video Communications.

Neto, J. and Passos, E. Jexodus: uma ferramenta para migracao de dados independentede sgbd.

Ora2Pg (2012). Ora2pg software. http://ora2pg.darold.net/.

Patel, R., Brose, G., and Silverman, M. (2006). Mastering Enterprise JavaBeans 3.0.Wiley Pub.

St.Laurent, S., Dumbill, E., and Gruber, E. (2012). Learning Rails 3. O’Reilly.

Viana, E. and Borba, P. (1999). Integrando java com bancos de dados relacionais. IIISimposio Brasileiro de Linguagens de Programacao, Porto Alegre Brasil, 5.


��

Apresentação e estudo de caso de metodologia de análise para Sistemas de Gestão do Conhecimento em empresas de

pequeno e médio porte Sergio Luiz Pereira1, Bruno Morozini1

1 Departamento de Engenharia de Energia e Automação Elétrica - Universidade de São Paulo (USP)

Av. Prof. Luciano Gualberto, trav. 3 , n. 158 - 05508-900 - São Paulo, SP - Brasil [email protected] , [email protected]

Resumo. Apesar das vantagens oferecidas pela gestão do conhecimento, pequenas e médias empresas ainda tem dificuldade de aplica-la devido a falta metodologias formais com ênfase em pequenas e médias empresas. Esse artigo apresenta uma proposta de metodologia para guiar pequenas e médias empresas na realização de projetos de Gestão do Conhecimento. Por meio de um método sequencial e repetível a metodologia tem como foco a fase de análise e levantamento de requisitos para o desenvolvimento de um Software para Gestão do Conhecimento. No artigo também é apresentado um estudo de caso com o resultado da aplicação da metodologia em uma pequena empresa brasileira e a análise dos resultados obtidos nessa aplicação.

1. IntroduçãoLongenecker et al. (1997) define pequenas empresas como parte fundamental para o bem-estar econômico da nação. Sua parcela de contribuição econômica é similar às grandes corporações e ainda possuem características que as tornam mais do que versões em miniatura das grandes empresas. Segundo Krugliankas(1996) essa característica comprova a importância que a competitividade dessas pequenas e médias empresas representa para o desenvolvimento econômico do país.

No Brasil, segundo estudos do SEBRAE (2008), a pequena empresa tem uma participação no mercado de 98% do total de empresas em atividade. Possui ainda grande potencial na geração de empregos, com aproximadamente 53% dos trabalhadores brasileiros ativos. Já na composição do produto interno bruto (PIB) brasileiro as pequenas e médias empresas representam 20% aproximadamente. Entretanto uma característica negativa em relação as pequenas empresas está na alta taxa de insucesso, principalmente em seus primeiros anos de vida. Dentre os principais fatores para o fracasso destacam-se a falta de habilidades técnicas e de gestão, falta de políticas de apoio e problemas pessoais dos proprietários.

Portanto a Gestão do Conhecimento (GC) pode ser considerada uma ferramenta capaz de gerar vantagem competitiva para pequenas e médias empresas (PMEs), diminuindo assim as chances de insucesso da empresa. Apesar disso, PMEs tem dificuldades para desenvolver e aplicar com sucesso a GC pela falta de uma metodologia que seja uma eficiente ferramenta de engenharia para realização da fase de levantamento de requisitos para GC.

Esse artigo apresenta uma proposta de metodologia denominada Metodologia de Análise para Gestão do Conhecimento em Pequenas e Médias Empresas(MAGCPME), para guiar a fase de análise e levantamento de requisitos de um projeto de GC . Esse artigo também apresenta um estudo de caso da aplicação da MAGCPME em uma pequena empresa brasileira. As conclusões foram obtidas por meio da comparação da situação inicial da empresa, antes do


��

projeto e a situação da empresa nove meses após a implantação do Sistema para Gestão do Conhecimento (SGC).

2. Gestão do Conhecimento

2.1. A Gestão do conhecimento nas pequenas e médias empresas

Canavarro (2003) cita a existência de diversas práticas de GC que podem ser aplicadas de acordo com o foco e as possibilidades da empresa, independente do seu tamanho, segmento ou estrutura. Canavarro (2003) apresenta duas formas básicas de aplicação da GC, são elas :

a) Conhecimento como um estoque que a empresa é capaz de lidar e gerenciaranualmente, sendo função da GC criar mecanismos para medir o conhecimentoacumulado;

b) As organizações tratam o conhecimento como um fluxo constante, no qual osprofissionais armazenam e compartilham experiências e conhecimentos.

Nesse caso, a GC tem o papel de organizar e suportar esse compartilhamento, por meiode sistemas que permitam uma maior interação entre os indivíduos e aumente a capacidade de troca de conhecimentos, o que no caso da pequena empresa estaria solucionando vários problemas, principalmente relacionados a comunicação.

Canavarro (2003) também pontua que independente do tamanho da empresa, do seu foco e das tecnologias utilizadas, a implementação da GC eficiente é um meio de melhorar a estrutura dos processos. O acesso mais amplo as informações e aos conhecimentos inerentes aos processos diminui o risco de erro e auxilia na tomada de decisões.

Apesar dos benefícios que a GC pode trazer a pequenas e médias empresas, alguns aspectos dificultam a sua implantação, entre eles destacam-se:

a) Falta de conhecimento técnico e específico sobre o negócio;

b) Falta de uma cultura de treinamento e capacitação dos recursos humanos;

c) Falta de um modelo de comunicação empresarial;

d) Falta de conhecimento sobre tecnologia.

Em contrapartida, segundo Rasheed (2005) a estrutura física e organizacional reduzidadas pequenas e médias empresas, em comparação com grandes empresas, oferece vantagens a implementação de um projeto de GC, destacam-se:

a) Gestão do projeto centralizada na alta-gerência;

b) Flexibilidade para mudanças nos processos;

c) Facilidade de desenvolvimento de uma cultura de compartilhamento de conhecimento.

2.2. Barreiras para Gestão do Conhecimento

Baseado na revisão da literatura sobre fatores de sucesso e fracasso de projetos de GC, pode-se identificar três fatores determinantes para o sucesso da GC: escolha e aplicação correta da tecnologia da informarção, mapeamento correto dos processos e aspectos da cultura organizacional. [Gray(2000), Quaddus (2005)]

A aplicação da tecnologia da informação (TI) para GC se tornou muito presente nas empresas durante os ultimos anos. Porém um projeto de sucesso de GC depende da escolha e aplicação correta de tecnologias para SGC. Para minimizar as chances de fracasso das iniciativas de GC a escolha das tecnologias devem considerar a forma de entrada, estrutura de


��

dados, armazenamento além da facilidade de manipulação, análise e extração dos dados armazenados [Alavi (1999), Chait (1999), Vandaie (2008)].

O mapeamento correto dos processos se torna atividade fundamental para o sucesso do projeto de GC. Segundo Rosina (2007) , ao entender a forma em que os processos organizacionais se relacionam entre si e quais as entradas e saídas associadas a cada processo, é possível se identificar os principais conhecimentos relacionados ao processo. Essa análise será transformada em requisitos para o SGC, e portanto erros durante essa fase podem resultar em um SGC que não atenda as necessidades da empresa. [Kogut (1992), Malhorta (2004)].

A cultura organizacional pode ser definida como um conjunto de comportamentos, crenças, valores e normas existentes entre as pessoas que fazem parte de uma organização [Birgit (2000)], uma implementação de sucesso de GC está associada a uma cultura organizacional que promova a criação e o compartilhamento do conhecimento, e deve ser suportada principalmente pela alta gestão da empresa que deve incentivar e premiar a aplicação de práticas de GC.

Outro aspecto importante está no envolvimento e participação dos stakeholders, em geral iniciativas de GC que não levam em consideração a opinião ou não tem a participação de todos os stakeholders do projeto durante sua fase inicial, tem maiores chances de fracassar. A participação dos stakeholders no processo de definição das práticas de GC que serão aplicadas, assim como na definição dos requisitos do SGC cria maior afinidade dos envolvidos com os resultados do projeto [King, (2008)].

Além disso, para aumentar as chances de sucesso da GC, é necessário que as pessoas percebam e entendam o valor da aplicação das práticas de GC, iniciativas de GC que criam complexidade ao trabalho ou geram mudanças nos processos sem que haja percepção de valor por parte dos responsáveis, tendem a fracassar. Assim como práticas ou sistemas que estejam apenas associados ao controle de resultados por parte do gestores e não ofereçam nenhum benefício aos funcionários, tendem a ser rejeitados [Disterer (2008), Atwood (2009)].

3. Metodologia de Análise para Gestão do Conhecimento em Pequenas eMédias Empresas (MAGCPME) A metodologia proposta nesse artigo tem como objetivo guiar a definição dos requisitos do projeto de GC em função dos processos, pessoas e tecnologias aplicadas.

Para se maximizar as chances de sucesso de um projeto de GC, é necessário um planejamento completo no início do projeto, para isso a metodologia proposta estabelece uma sequência de ações ou etapas a serem seguidas, são elas:

a) Identificação do estado atual da empresa e dos macro objetivos do projeto;

b) Definição da equipe do projeto de GC;

c) Avaliação dos sistemas e processos com foco em GC;

d) Definição da macro arquitetura sistêmica e do cronograma do projeto de GC;

e) Definição da tecnologia e infra-estrutura de suporte para a implementação da macroarquitetura sistêmica definida.

A Figura 1 apresenta o fluxograma das etapas propostas pela MAGCPME.


��

Figura 1 – Fluxograma das etapas da MAGCPME

3.1. Identificação do estado atual da empresa e dos macro objetivos do projeto

A macro-etapa de identificação do estado atual da empresa e dos macros objetivos do projeto é o ponto de partida da aplicação da metodologia. Essa etapa consiste de reuniões e entrevistasjunto aos principais stakeholders do projeto para que se possa identificar objetivos e limitações relacionados a questões organizacionais, tecnológicas, culturais e financeiras. Essa macro-análise servirá como base para os próximos passos da metodologia.

3.2. Definição da equipe do projeto de GC

A etapa de definição da equipe do projeto de GC é onde a equipe do projeto de GC será formada e as funções e atribuições de cada integrante definida. Essa etapa consiste de reuniões e entrevistas que auxiliarão na escolha dos participantes do projeto de GC, essa definição será feita baseada na avaliação de perfis e habilidades dos envolvidos. Além da definição dos envolvidos, nessa etapa também deve se avaliar a necessidade de capacitação dos recursos da empresa, assim como a necessidade de contratação de consultores para a realização do projeto.

3.3. Avaliação dos sistemas e processos com foco em GC

A etapa de avaliação de sistemas e processos com foco em GC é o momento onde a equipe de GC iniciará as atividades relacionadas a levantamento detalhado dos requisitos do projeto de GC e do SGC. Essa etapa consiste de entrevistas e levantamento de informações sobre a estrutura existente de GC na empresa e na definição de novos processos de GC que devem ser contemplados com o projeto. Ao final do levantamento da estrutura existente e do mapeamento do que será criado, será feita uma avaliação sobre como contemplar os objetivos do projeto de maneira eficaz, com o objetivo de maximizar a integração entre as áreas e a distribuição das informações por meio dos sistemas de GC utilizados.


��

3.4. Definição da macro arquitetura sistêmica e do cronograma do projeto de GC

A etapa de definição da macro arquitetura sistêmica e do cronograma do projeto de GC consiste do alinhamento dos requisitos do projeto definidos previamente, com as ferramentas de GC que sejam adequadas as realidades técnicas e financeiras da empresa, esse alinhamento permitirá a definição de como o SGC será aplicado. Baseado nas definições realizadas para o SGC e nas diretrizes de arquitetura definidas será definido o cronograma de implementação do projeto.

3.5. Definição da tecnologia e infra-estrutura de suporte para a implementação da macro arquitetura sistêmica definida

A etapa de definição da tecnologia e infra-estrutura de suporte para a implementação da macro arquitetura sistêmica definida consiste na definição das tecnologias e plataformas de sistema que serão utilizadas na implementação do projeto de GC e do SGC.

Nesta etapa deve-se levar em consideração que a empresa pode ter realizado investimentos em TI antes de iniciar esse novo projeto de GC. Portanto, essa etapa deve ser feita com o objetivo de implementar o projeto considerando e contemplando plataformas e tecnologias já utilizadas dentro da empresa.

4. Aplicação da MAGCPMEA aplicação da metodologia foi feita em uma pequena empresa brasileira, que atua como representante comercial de um software para Computer Aided Design (CAD) no Brasil. A empresa além de trabalhar com a comercialização de licenças do software, também possui uma área de suporte e consultoria sobre utilização do software e um centro de treinamento e capacitação de profissionais na utilização do software.

Para validação dos resultados foi comparado o estado inicial da empresa, antes do projeto e a situação da empresa nove meses após a implantação do SGC. Para a avaliação dos resultados foram realizadas entrevistas junto aos principais envolvidos no projeto, essas entrevistas foram conduzidas durante a fase de análise e após a implantação do SGC desenvolvido com o objetivo de identificar qual a percepção dos envolvidos em relação aos resultados obtidos pela aplicação do SGC.

4.1. Situação da empresa antes do projeto

Com a crescente demanda por consultoria e treinamentos e com a ampliação da área comercial em busca de novos clientes a diretoria da empresa identificou a necessidade de aplicação de um software para Gestão do Conhecimento para suportar as operações.

Inicialmente o controle e armazenamento das informações era descentralizado, cada vendedor controlava individualmente sua carteira de clientes e as informações sobre os contatos, reuniões e apresentações técnicas não eram registradas em uma base centralizada, o que dificultava a construção de relacionamento com os clientes, principalmente em casos onde o vendedor que atendia determinado cliente era substituido ou deixava a empresa.

A área de suporte e consultoria não possuia nenhuma ferramenta para registro e controle de chamados técnicos, a maioria desses chamados era feita via email ou telefone, e após o atendimento o histórico não era armazenado, assim como a solução do problema não era registrada em nenhuma base de conhecimento formal. A falta de estruturação dessa área gerava constante re-trabalho e oferecia pouca visibilidade a diretoria, sobre a qualidade do atendimento prestado pela equipe técnica.


��

A área de treinamentos fazia o controle das vendas e o cadastro dos alunos por meio de uma planilha eletrônica compartilhada na rede interna da empresa. Apesar de permitir o acesso e registro da informação de forma centralizada, a qualidade das informações contidas na planilha era baixa, devido a falta de padronização no seu preenchimento. Embora, em comparação com outras áreas da empresa, a área de treinamentos tivesse um processo para controle da informações o processo poderia ser melhorado amplamente com a aplicação de um SGC.

4.2. A aplicação da metodologia

A metodologia foi aplicada integralmente na empresa, e os resultados obtidos pela aplicação da metodologia foram utilizados como base para o desenvolvimento do SGC.

4.2.1. Aplicação da Macro-Etapa 1

A aplicação da Macro-Etapa 1 permitiu a identificação da situação inicial da empresa e de alguns aspectos da cultura organizacional.

A empresa era basicamente dividida em duas áreas : técnica e comercial e cada um dos sócios da empresa era responsável por uma das áreas e suas principais decisões.

Na área técnica os funcionários atuavam de maneira cooperativa e o compartilhamento de conhecimento, mesmo que de maneira informal, era mais comum que na área comercial. Na área comercial os vendedores atuavam individualmente e reportavam diretamente ao diretor da área, a troca de informação entre vendedores não era comum, em sua maioria os vendedores guardavam todo o conhecimento sobre o cliente e o relacionamento com o cliente para si.

Na Macro-Etapa 1 também foi possível identificar as principais tecnologias utilizadas pela empresa para a realização das tarefas diárias. A empresa utilizava tecnologias de mercado baseadas na plataforma Microsoft (Windows e Pacote Office) e tinha como objetivo investir em um SGC suportado por essas tecnologias e preferencialmente na internet para que permitisse o acesso mesmo que o funcionario estivesse fora da empresa.

Entre os principais objetivos da empresa com a realização do projeto destacam-se :

a) Centralização da informação sobre os clientes;

b) Registro do histórico de relacionamento com os clientes;

c) Redução do tempo de atendimento a chamados técnicos

d) Controle centralizado da agenda dos profissionais técnicos e comerciais;

e) Automação do processo de organização dos treinamentos;

f) Maior visibilidade sobre as tarefas executadas por cada um dos funcionários para ossócios da empresa;

g) Aumento no faturamento da empresa por meio de aumento nas vendas de software,treinamento e consultoria.


Na Macro-Etapa 2 foi definida a equipe do projeto, por se tratar de uma pequena empresa os líderes do projeto foram os sócios, cada um liderando as decisões sobre sua área. Essa escolha impactou diretamente nos resultados pois o conhecimento amplo sobre o negócio e a liderança exercida por cada um deles perante a equipe gerou um maior comprometimento dos envolvidos. Além dos dois líderes a equipe foi formada por dois profissionais de cada área. Esses profissionais foram selecionados baseados por sua experiência e tempo de trabalho na empresa


��

e foram o ponto de contato entre os líderes de projeto e os demais funcionários da área. Os funcionários escolhidos em cada área também tinham um conhecimento mais profundo sobre os processos organizacionais além das dificuldades e necessidades para a execução das tarefas no dia-a-dia.

Por se tratar de uma pequena empresa, não exisitiam profissionais com foco em tecnologia da informação e desenvolvimento de software, portanto na Macro-Etapa 2 foi detectada a necessidade de contratação de uma empresa de consultoria especializada para realizar o desenvolvimento e manutenção do SGC. A empresa contratada ofereceu um consultor para acompanhar a aplicação das macro-etapas seguintes da metodologia.


Com a equipe definida, foi aplicada a Macro-Etapa 3 da metodologia, com o objetivo de aprofundar o entendimento sobre a situação da empresa. Nessa macro-etapa foram levantados e avaliados todos os processos para GC existentes, assim como os ativos de TI existentes.

O levantamento foi realizado inicialmente pelos integrantes da equipe do proejto dentro de suas áreas. Posteriormente esses resultados foram apresentados aos líderes do projeto para que fossem tomadas as decisões de manter, alterar ou descontinuar cada um dos processos ou ativos identificados durante o levantamento. Esse levantamento também permitiu a identificação de lacunas que necessitavam ser preenchidas por meio da criação de novos processos, um exemplo de lacuna estava na falta de um processo formal para atendimento a chamados técnicos, esse processo tinha como objetivo desenvolver uma base de conhecimento centralizada capaz de aumentar a qualidade do atendimento da empresa e reduzir o tempo de resposta aos clientes, por meio da aplicação de conhecimento existente dentro da empresa.

A aplicação da macro-etapa 3 permitiu a identificação do estado atual do conhecimento da empresa, além do local e da forma que o conhecimento estava armazenado. Essa análise gerou um entendimento mais profundo sobre quais os conhecimentos estavam associados a cada processo, seja em forma de entrada ou saída do processo.


Com todos os requisitos identificados e com o entendimento completo sobre a estrutura atual dos processos organizacionais e tecnologia foi iniciada a Macro-Etapa 4. Nessa macro-etapa foram definidos os aspectos técnicos como tecnologias utilizadas, infra-estrutura necessária e macro-arquitetura sistêmica.

Baseado nos requisitos identificados e nas necessidades técnicas identificadas anteriormente, a empresa contratada para prestar consultoria em TI propos um sistema único que integrasse a área técnica e a área comercial, centralizando informações sobre os clientes e permitindo a automação de todos os processos definidos para a gestão do conhecimento. A proposta apresentada sugeria um sistema com características de um sistema de Customer Relationship Management (CRM), específico as necessidades apresentadas pela empresa, com recursos adicionais para controle de agenda dos profissionais, atendimento a chamados técnicos e relatórios gerenciais capazes de suportar a tomada de decisões estratégicas ao negócio. A proposta sugeria um sistema web distribuido com variações para acesso via internet e intranet. Essa divisão tinha como objetivo de proteger informações sigilosas, evitando que houvesse acesso externo por pessoas não autorizadas. A proposta foi validada junto a equipe do projeto por meio de protótipos funcionais que apresentavam a estrutura do SGC. A proposta foi avaliada e aprovada pela equipe do projeto e o cronograma de desenvolvimento do SGC foi definido.


��

Segundo os líderes do projeto, a necessidade de automação dos processos da área comercial era mais urgente do que a necessidade de automação da área técnica, portanto o desenvolvimento do SGC deveria ser iniciado pelas funcionalidades principais para a área comercial e posteriormente seriam desenvolvidas as funcionalidades para a área técnica.


Na Macro-etapa 5, novamente com apoio dos consultores de TI contratados, foram definidas as tecnologias a serem utilizadas além da infra-estrutura necessária para atender as demandas definidas na macro-etapa anterior.

Por se tratar de um sistema web e por toda a estrutura atual da empresa já utilizar a plataforma Microsoft, foi escolhido para desenvolvimento do projeto as linguagens de programação ASP.NET e C#, para o banco de dados foi escolhido o SQL Server 2005 e o servidor de aplicações Internet Information Services (IIS) 7.0.

Para a versão do SGC que seria executada na intranet a empresa já dispunha de um servidor capaz de atender os requisitos técnicos e de performance definidos pelos consultores. Porém a empresa não dispunha ainda de um servidor com os requisitos necessários para a versão do SGC que estaria disponível na internet para acesso externo. Baseado nas necessidades de performance, segurança, disponibilidade e escalabilidade do projeto a equipe optou por um servidor virtual utilizando computação na nuvem (cloud computing), tendo assim um custo benefício melhor se comparado a outras possibilidades como por exemplo um servidor compartilhado de baixo custo.

5. Análise de ResultadosApós o desenvolvimento e homologação do SGC foi realizado o treinamento da equipe técnica e comercial, o treinamento foi desenvolvido e ministrado pelos profissionais envolvidos no projeto.

Com a equipe capacitada na utilização do SGC toda a operação da empresa passou a ser registrada de forma centralizada. Nesse tipo de projeto, é comum surgir resistência por parte de alguns usuários devido as mudanças impostas nos processos organizacionais. Para mitigar esse problema a metodologia sugere a participação de todos os envolvidos durante o levantamento dos requisitos, essa participação gera nas pessoas um melhor senso de responsabilidade e realização sobre os resultados obtidos. Ou seja, ao perceber que ela fez parte da mudança e suas idéias foram levadas em consideração, ela passa a ter mais interesse pelos resultados. Outra medida importante foi a criação de um programa de avaliação de resultados e recompensa baseado em relatórios gerenciais do SGC. Um exemplo disso foi a área comercial interna da empresa, responsável pela prospecção de clientes por telefone. O SGC permite que a diretoria analise de maneira efetiva a quantidade de contatos comerciais realizada por cada vendedor e a qualidade desse contato comercial. Pois além do histórico de contato armazenado também passou a ser analisada a taxa de conversão de contatos comerciais em vendas. A análise da taxa de conversão direcionou modificações no processo comercial em busca de aumentar a qualidade dos contatos realizados e diminuir a quantidade média de iterações com o cliente para a realização da venda.

Na área técnica, foi implantada a automação do processo de controle de chamados técnicos que não existia previamente, essa automação permitiu a criação da uma base de conhecimento que reduziu em 35% o tempo médio de atendimento aos chamados. Na área técnica também foi automatizado o processo de venda e organização de treinamentos técnicos. Essa automação permitiu a padronização do cadastro dos alunos e o registro do historico de treinamentos realizados e de quais cursos interessavam ao aluno. Esse controle elevou a quantidade média de alunos por turma em cada treinamento em 15%, pois o sistema permite a


��

indentificação de quais treinamentos são mais procurados direcionando assim a agenda de treinamentos ministrados e mesmo para os treinamentos menos procurados o sistema permite a identificação de um grupo de alunos interessados para que uma turma seja criada.

De forma geral, os resultados em ambas as áreas da empresa foram significativos. O SGC permitiu o aumento do controle sobre o conhecimento existente da empresa e sobre o conhecimento gerado no dia-a-dia da empresa, além disso permitiu a implantação de um programa de reconhecimento de funcionários, que passou a premiar os profissionais com melhor performance e consequentemente aumentou a produtividade e diminuiu o turnover da empresa, pois os profissionais passaram a se sentir mais valorizados.

Após nove meses de utilização do SGC a empresa já obteve resultados em termos de vantagem competitiva e lucratividade.

6. ConclusãoPara o estudo de caso apresentado nesse artigo, a aplicação da metodologia se mostrou efetiva pois guiou o processo de levantamento de requisitos para o desenvolvimento do SGC sem que tivesse a tecnologia somente como ponto central do projeto. A metodologia guiou as definições por meio de uma alinhamento entre os processos organizacionais, as pessoas envolvidas e as tecnologias utilizadas.

A Tabela 1 apresenta as principais vantagnes oferecidas pela aplicação da metodologia.

Tabela 1 : Principais Vantagens da MAGCPME

Foco Vantagens da MAGCPME

Cultura Organizacional - Identificação de barreiras existentes na cultura organizacional - Alinhamento da Cultura Organizacional com a GC

Tecnologia

- Alinhamento da tecnologia com os processos organizacionais - Aproveitamento dos investimentos em tecnologia já realizados - Avaliação de custo-benefício - Foco em segurança da informação e usabilidade

Equipe - Auxílio na definição de uma equipe coesa - Identificação da necessidade de consultores

Processos - Formalização dos processos organizacionais - Alinhamento dos processos com as necessidades da GC

Apesar da metodologia ser mais complexa de ser aplicada do que uma metodologia de levantamento de requisitos de software comum, a aplicação da metodologia se justifica pela melhora obtida no levantamento de informações relavantes sobre a cultura organizacional, processos organizacionais e pessoas envolvidas.

Essa melhora na qualidade do levantamento de requisitos é refletida na qualidade do SGC, que tende a ter um melhor alinhamento com a cultura organizacional e com as expectativas dos profissionais envolvidos.

7. Trabalhos futurosOs próximos passos dessa pesquisa tem como objetivo avaliar os resultados em projetos de diferentes portes e empresas de diferentes ramos de atuação, com o objetivo de refinar o método proposto em busca de redução do tempo de aplicação da metodologia sem que haja impacto na qualidade dos resultados obtidos.


��

Referências Bibliográficas Quaddus, M., Xu, J., Adoption and diffusion of knowledge management systems: field studies

of factors and variables, Knowledge-Based Systems, Volume 18, Issues 2–3, Abril 2005, Pages 107-115, ISSN 0950-7051

P.H. Gray, The effects of knowledge management systems on emergent teams: towards a research model, Journal of Strategic Information Systems 9 (2000) 175–191.

Alavi M, Leidner D. Knowledge management systems: issues, challenges, and benefits. CAIS 1999;1(7):2–36.

Malhotra, Y., Why Knowledge Management Systems Fail? Enablers and Constraints of Knowledge Management in Human Enterprises . American Society for Information Science and Technology Monograph Series, 87-112, 2004.

Nassar Rasheed. (2005). The Impact of Knowledge Management on SMEs. Disponiível em:http://www.knowledgeboard.com/download/2539/THE-IMPACT-OF-KM-ON-SMEs.pdf. Acesso em 1 de dezembro de 2012

Kogut B, Zander U. Knowledge of the firm, combinative capabilities, and the replication of technology. Organization Science 1992;3(3): 383–97.

William R. King, Peter V. Marks Jr., Motivating knowledge sharing through a knowledge management system, Omega, Volume 36, Issue 1, February 2008, Pages 131-146

Ramin Vandaie, The role of organizational knowledge management in successful ERP implementation projects, Knowledge-Based Systems, v.21 n.8, p.920-926, December, 2008

L.P. Chait, Creating a successful knowledge management system, Journal of Business Strategy 20 (2) (1999) 23–26.

Weber Rosina (2007) “Addressing Failure Factors in Knowledge Management” The Electronic Journal of Knowledge Management, Volume 5 Issue 3, 333–346.

Disterer, G. (2001) ‘Individual and Social Barriers to Knowledge Transfer’, Conference Proceedings 34th Annual Hawaii International Conference on System Sciences, Los Alamitos, CA:IEEE Press.

Atwood, M.E. (2002) ‘Organizational Memory Systems: Challenges for Information Technology’, Conference Proceedings, 35th Annual Hawaii International Conference on System Sciences, Los Alamitos, CA:IEEE Press.

Justin G. Longenecker; Carlos W. Moore; J. William Petty. Administração de pequenas empresas: ênfase na gerência empresarial. São Paulo: Ed. Makron Books. 1997

Isak Kruglianskas, Celso Augusto Rimoli, Roberto Sbragia. Investigando a gestão tecnológica e o desempenho de MPEs de setores tradicionais. Revista de Administração e Tecnologia. Anais do ANANPAD, Curitiba: 1996.

SEBRAE (2008). Serviço Brasileiro de Apoio às Micro e Pequenas Empresas. 10 Anos de Monitoramento da Sobrevivência e Mortalidade de Empresas. Disponível em: http://www.sebraesp.com.br/PortalSebraeSP/Biblioteca/Documents/EstudosePesquisas/Mortalidade_MPE/mortalidade_2006_2007/mortalidade_2006_2007.pdf. Acesso em: 15 de novembro de 2012

Marcela Canavarro,. (2003). Gestão do saber. Artigo eletrônico. Disponível em: http://www.timaster.com.br/revista/materias/main_materia.asp?codigo=853. Acesso em 3 de dezembro de 2012


��

MAIN, A Aplicabilidade de Agentes Inteligentes como Estimuladores da Interatividade em Ambientes Virtuais de

Aprendizagem. Márcio André Andrade Silva1, Marcelo Batista de Souza2,3

1Departamento de Ciência da Computação – Universidade Federal de Roraima (UFRR) – Boa Vista, RR – Brasil

2Departamento de Matemática – Universidade Federal de Roraima (UFRR) – Boa Vista, RR – Brasil

3Núcleo de Educação à Distância – Universidade Federal de Roraima (UFRR) – Boa Vista – RR – Brasil

[email protected], [email protected]

Abstract. In the globalized context, distance education has enhanced the use of tools based on Information Technologies and Communication. Relevant aspects of human life are being applied to computational intelligent systems. This paper describes the MAIN - multiagent Informers, which is under development. The system is based on multi-agent technology and will operate within a Virtual Learning Environment to observe, assess and encourage interactive relationships between students, tutors and teachers linked to an undergraduate degree. Resumo. No contexto globalizado, a Educação a Distância tem potencializado o uso de ferramentas baseadas em Tecnologias da Informação e daComunicação. Aspectos relevantes da vida humana estão sendo aplicados a sistemas computacionais inteligentes. Este trabalho descreve o MAIN - MultiAgent Informers, que está em fase de desenvolvimento. O sistema é baseado em tecnologia multiagente e atuará dentro de um Ambiente Virtual de Aprendizagem para observar, avaliar e estimular as relações interativas entre estudantes, tutores e professores vinculados a um curso de graduação.

1. Introdução

A modalidade de Educação a Distância (EaD) tem despertado interesses de instituições de ensino no Brasil, motivada pela oferta de cursos e nova demanda de estudantes. Com isso, produtos e serviços educacionais têm sido melhorados significativamente.

Nos últimos anos, com a evolução da EaD, as pesquisas voltadas para o âmbito educacional, aprimoraram o uso da tecnologia de Agentes Inteligentes (AIs). Aspectos relevantes da vida humana foram observados e copiados para aplicações computacionais. Isto contribuiu para a melhoria das relações entre homem-máquina e do processo de ensino-aprendizagem. Segundo Lévy (1999) é notória a crescente evolução nas áreas de tecnologia e de comunicação. Investimentos para desenvolver novas ferramentas computacionais têm sido feitos, tornando as perspectivas promissoras. Bica (2000) defende que os avanços mais recentes no campo dos ambientes de aprendizagem inteligentes têm proposto o uso de arquiteturas baseadas em sociedades de agentes. A


��

caracterização desses AIs explora o conceito de aplicações capazes de executar tarefas do sistema, visando atingir o seu objetivo principal. As interações entre eles é que tornam isso possível através da habilidade, sociabilidade, agilidade e autonomia de cada um. Isto vem despertando grande interesse na área educacional. Bradshaw (1997) descreve um agente como uma entidade de software que funciona de forma contínua e autônoma em um ambiente em particular, geralmente habitado por outros agentes e processos.

Neste trabalho, será apresentado o MultiAgent Informers (MAIN), o qual caracteriza-se pela atuação de AIs no Ambiente Virtual de Aprendizagem (AVA) Moodle, com o intuito de averiguar qual a sua influência neste tipo de ambiente. Um dos seus principais desafios é promover a interatividade e estimular a proatividade dos participantes no AVA, criando mecanismos necessários no processo de aprendizagem, para que estudantes, tutores e professores atinjam um nível maior de participação. O sistema multiagente MAIN está em fase de desenvolvimento. Ele propõe uma abordagem para averiguar se, no processo educacional, o uso da tecnologia de AIs em AVAs estimula a interatividade entre os seus participantes.

O restante do artigo apresenta na seção 2 os trabalhos correlatos que estão contribuindo para o desenvolvimento do MAIN, já as tecnologias empregadas na sua implementação serão mostrados na seção 3. Nas seções 4 e 5 serão descritos os seus detalhes, as conclusões parciais e os trabalhos em andamento, respectivamente. O artigo é finalizado destacando na seção 6 as referências bibliográficas que sustentam as idéias apresentadas neste resumo.

2. Trabalhos CorrelatosNesta seção, serão apresentados os trabalhos correlatos que descrevem abordagens utilizando Sistemas Multiagentes (SMA) e Moodle, que serviram de referência teórica para o desenvolvimento do sistema MAIN.

Campana et al (2008) apresentaram uma arquitetura de SMA para AVAs. A idéia contempla uma camada multiagente, que oferece um serviço de monitoramento e suporte aos participantes e mediadores dos grupos para melhorar a qualidade da interação no ambiente e aprendizado dos seus usuários. Outro trabalho que incentiva a interatividade foi apresentado por Musa (2001), sua característica principal é detectar as situações criticas no AVA, Nele, o sistema poderá auxiliar o professor no acompanhamento das atividades propostas, colaborando com o estudante em supostas dificuldades que ele possa vir a ter, sem acarretar sobrecarga de trabalho.

Lyra e Santos (2012) apresentaram um SMA capaz de monitorar a frequência dos estudantes e as datas de envio dos trabalhos na plataforma Moodle, bem como a estrutura do seu banco de dados. Para tanto, o SMA dispara mensagens, sempre que houver comunicados pendentes, a fim de evitar a evasão de estudantes e desatenção em relação ao cumprimento das atividades do curso. Já Gonçalves et al (2008) apresentaram uma aplicação que possui agentes de softwares capaz de notificar via e-mail usuários do ambiente Moodle, de uma determinada instituição, quanto ao número de acessos no prazo de 24 horas, com um agente notificador que possui um banco de dados próprio com informações extraídas da sua base de dados.

Lazzarotto (2010) apresentou um modelo de SMA, a ser usado em AVAs, que auxilia o professor na definição de procedimentos mais adequados com o intuito de


��

melhorar e aumentar a eficiência do processo de ensino-aprendizagem em EAD. Nesta mesma percepção, Alencar e Netto (2012) descreve uma arquitetura, baseada em sistemas multiagentes, criada para auxiliar estudantes e tutores na conclusão e acompanhamento de atividades em cursos EaD. Na seção a seguir serão apresentadas as ferramentas tecnológicas utilizadas no projeto MAIN, sendo elas suficientes para a construção de um SMA e suas aplicações.

3. Tecnologias EmpregadasDas tecnologias utilizadas na pesquisa destaca-se o Moodle (2013), por ser um ambiente dinâmico de aprendizagem com padrão orientado a objetos, guiado por uma pedagogia social, que se apoia em quatros grandes conceitos que se relacionam que são o construtivismo, o construcionismo e o construtivismo social, conectada e em separado. Vale ressaltar que o Moodle é um dos AVAs mais difundidos na EAD para suporte e gerenciamento de cursos em instituições de ensino.

Para facilitar a análise e identificação dos principais agentes envolvidos na arquitetura do SMA proposto, foi utilizada a ferramenta AGENTTOOL (2013), um ambiente de desenvolvimento gráfico, baseado em Java, que auxilia seus usuários a analisar, projetar e implementar Sistemas Multiagente (SMA). A ferramenta apóia a Metodologia de Engenharia de SMAs descrita como Multiagent Systems Engineering (MaSE).

No processo de implementação foi utilizado Java que é uma linguagem de programação orientada a objetos, desenvolvida pela Sun Microsystems. Ela é capaz de criar tanto aplicativos para desktop, aplicações comerciais, aplicativos para a Web e softwares robustos, completos e independentes.

Como o processo de implementação é um passo importante, complementado a linguagem Java foi utilizado o HIBERNATE (2013), um framework que faz o mapeamento de classes para tabelas de banco de dados e de tipos de dados Java para tipos de dados Structured Query Language (SQL). Ele fornece dados de consulta e recuperação de instalações que reduzem significativamente o tempo de desenvolvimento, contemplado a capacidade de mapear um modelo de representação do objeto de dados para um modelo de dados relacional e seu esquema de banco de dados correspondente. Além de está licenciado sob a GNU fonte aberto Lesser General Public License (LGPL) é livre para o desenvolvimento e implantações de produção.

Para a realização de testes do SMA utilizou-se o JADE (2013) que um ambiente de desenvolvimento de agentes e que, também, utiliza um middleware contendo um ambiente de execução dos agentes, uma biblioteca de classes e um conjunto de ferramentas gráficas, que segue as especificações no padrão da Foundation for Intelligent Physical Agents (FIPA).

Na próxima seção, serão apresentadas as características gerais do MAIN, na subseção 4.1 será descrita as motivações que culminaram na construção do SMA, na subseção 4.2 serão apresentados o modelo do SMA e seus detalhamentos, os AIs com suas características e comportamentos mostrados em forma de diagramas. Finalmente, na subseção 4.3, serão apresentados três tipos de mensagens (de estimulo) a ser enviada ao seu respectivo participante envolvido no processo de ensino e aprendizagem.


��

�� 2�6LVWHPD�0XOWLDJHQW�,QIRUPHUV�±�0$,1

O sistema MAIN consiste basicamente em promover a interação entre usuários de um AVA, utilizando AIs, e partir disso estabelecerá uma comunicação com aqueles que ficam inertes ou que pouco interagem no AVA, por um determinado período. Essa comunicação é um fator importante, pois estimulará os participantes do ambiente a interagir efetivamente, propiciando o engajamento ao estudo e, portanto, obtendo-se melhores resultados.

4.1 Motivação

Historicamente, as preocupações na educação presencial e à distância são semelhantes, ou seja, as duas buscam novas formas de acesso ao conhecimento que possibilitem a construção de conceitos, uma maior compreensão das idéias e do pensamento analítico e crítico, mediante o uso de recursos tecnológicos.

Lévy (1999) destaca que a EAD é considerada uma modalidade que explora técnicas de ensino, incluindo hipermídias, redes de comunicação interativas e tecnologias intelectuais da cibercultura, favorecendo o surgimento de um estilo pedagógico voltado para a aprendizagem personalizada e coletiva em rede. O mediador torna-se um animador da inteligência em vez de um fornecedor direto de conhecimentos.

Em EAD, a interatividade é tida como um fator importante. O êxito em um curso pode ter como influência diversos fatores como, por exemplo, uma definição clara do programa, a utilização do material didático e de meios apropriados que facilitem essa interatividade entre professores e estudantes.

Foi realizada uma pesquisa experimental, com os estudantes das disciplinas A, B e C do curso de Licenciatura em Informática, no Núcleo de Ensino a Distância (NEAD) da Universidade Aberta do Brasil (UAB/UFRR), onde se constatou que em um período de três meses, em média 43% destes participantes nunca interagiam com o AVA e que apenas 36% dos participantes acessam o ambiente com frequência. Portanto, os dados apontaram que não há interação no ambiente AVA por quase a metade dos estudantes.

Tabela 1. Percentual de acessos no AVA (NEAD/moodle).


��

Esses dados revelam que há uma realidade desfavorável em relação ao ensino a distância, pois a falta de interatividade no ambiente demonstra desestímulo do estudante em prosseguir com o curso, fato que colaborou para investigação científica a ponto de verificar quais os fatores que contribuem para o índice de evasão e como o uso de AIs em AVAs poderiam minimizar tal situação ao tentar promover constante interatividade.

4.2 Abordagem Proposta Esta seção apresenta uma abordagem que consiste em adicionar na arquitetura do AVA, um SMA capaz de monitorar estudantes e mediadores que utilizam o ambiente, enviando mensagens via e-mail. A proposta do sistema é estimular usuários para que possam acessar o ambiente com mais frequência, explorando o construtivismo, onde o conhecimento é adquirido de forma colaborativa.

Wooldridge (2002) caracteriza os SMAs em um sistema onde vários agentes atuam em conjunto sobre um ambiente na busca da resolução de um problema. Para Tori (2010) os sistemas multiagentes possibilitam a automação do processo de monitoramento que alerte o professor para situações que necessitem de sua atenção. A arquitetura MAIN é apresentada na figura 1, destacando os seus componentes principais.

Figura 1. Representação do SMA em conjunto com o AVA/Moodle.

Superadas fases anteriores, o MAIN está em fase de prototipação utilizando a metodologia MaSE, que compreende duas etapas, sendo descritas de acordo com Deloach e Wood (2001) como a análise e a modelagem. Os mecanismos informados na Figura 1 proporcionam a comunicação entre os usuários do AVA e os AIs que estão sendo definidos na fase de análise, com os seguintes comportamentos:


��

StarterAgent: este agente é responsável por criar o GetterAgent em um determinadoperíodo. Com ele, o SMA inicia a busca de informações da base dados do moodle eas encaminha para o outros agentes se comunicarem e realizarem suas tarefas pré-estabelecidas.

KillerAgent: possui a tarefa apenas de fazer “matar” o GetterAgent por umdeterminado tempo, evitando que ele se comunique com outros agentes, ficandoportanto bloqueados a espera desta comunicação.

GetterAgent: obtém informações especificas da base de dados do moodle paraenviá-las ao próximo agente realizar sua tarefa.

StorerAgent: se caracteriza por armazenar na tabela mdl_agent_content oscomunicados enviados pelo GetterAgent.

StudentAgent: faz o monitoramento da base de conhecimento, a fim de coletarinformações relativas as pendências do estudante, atualizando o status do evento ecomunicando-as ao PostMailAgent.

TeacherAgent: é responsável, também, por monitorar a base de conhecimento,enviando informações para o PostMailAgent, comunicando ao professor, sobre ocomportamento do estudante.

CoordinatorAgent: monitora a base de conhecimento, no sentido de comunicar-secom o PostMailAgent para que este possa enviar e-mail ao coordenador do curso,sobre o comportamento do professor.

CleanerAgent: este agente “limpa” a tabela mdl_agent_content, sempre que o statusdo evento estiver como enviado, a fim de manter apenas as informações recentes eminimizar a sobrecarga no sistema.

PostMailAgent: recebe todas as mensagens dos agentes designados para monitorar atabela mdl_agent_content e enviá-las para seus respectivos destinatários.

Após a definição da hierarquia dos objetivos propostos, de acordo com a metodologia MaSE, foi construído o diagrama do modelo de agentes envolvidos na arquitetura do MAIN. Este diagrama é apresentado na figura 2.

Figura 2. Diagrama do Modelo de Agentes


��

Para especificar a troca de mensagens entre os agentes envolvidos no modelo de SMA proposto, foi utilizada a especificação de diagramas de sequência. A Figura 3 mostra a comunicação dos AIs envolvidos no monitoramento e armazenamento de informações do AVA, que posteriormente tem a interação dos participantes analisadas.

Figura 3. Diagrama de Sequencia dos Agentes

Na Figura 4, o diagrama de sequência apresenta a comunicação entre os AIs.Verifica-se o tempo e frequência de acesso nas sessões do AVA, através de informações armazenadas na base de conhecimento, onde tudo é registrado para posteriormente informar ao agente PostMailAgent que envia mensagens de estímulo para os estudantes e demais envolvidos no processo de ensino e aprendizagem

Figura 4. Diagrama de Sequencia dos Agentes

Todos esses diagramas mostram os procedimentos envolvidos para que, a partir da coleta dessas informações, seja possível avaliar o grau de interação dos estudantes. Esse monitoramento e avaliação são constantes e dinâmicos para permitir um resultado mais preciso sobre o desempenho dos estudantes do ensino a distância.


��

Na subseção seguinte são apresentadas as notificações enviadas aos participantes do curso relacionadas à interação com o ambiente, estímulos ao usuários para tornar o processo de ensino-aprendizagem mais dinâmico.

4.3 Mensagens de Estímulos Enviados por E-mail

Nesta subseção serão apresentadas as notificações a serem enviadas aos participantes do curso, para que estes sejam estimulados a interagirem com o ambiente favorecendo, desta forma, o modelo pedagógico proposto pelo Moodle.

A Figura 5 apresenta um exemplo de mensagem enviada por E-mail para um dos estudantes do curso a distancia. Esta mensagem é enviada quando o sistema verifica se o participante não acessa com frequência o ambiente AVA, em um determinadoperíodo, de forma a estimulá-lo para interagir com o ambiente e dar continuidade ao processo de aprendizagem, encorajando-o a não desistir do curso.

Figura 5. Mensagem Enviada ao Estudante.

No caso da Figura 6 é apresentado um exemplo de mensagem enviada para o professor responsável pelo curso, contendo os nomes dos estudantes que pouco interagiram com o ambiente durante a semana. Com esta informação, o professor poderá implementar um plano de ensino no decorrer do curso, dependendo do desempenho dos estudantes, contribuindo desta forma para que o ensino a distância seja mais otimizado.

Figura 6. Mensagem Enviada ao Professor.


��

Já na figura 7 é mostrado uma mensagem enviada ao Coordenador do curso, que poderá verificar se há interação dos mediadores no AVA, podendo neste caso exigir deles a frequência no ambiente de forma mais efetiva, visto que esse comportamento contribui para que haja desestímulo e consequente evasão do curso por parte dos estudantes.

Figura 7. Mensagem Enviada ao Coordenador do Curso

Na seção seguinte serão apresentadas as conclusões parciais, os trabalhos em andamento e o que se espera do uso do MAIN como estimulador da interatividade em AVAs.

5. Conclusões Parciais e Trabalhos em Andamento

Conforme observado, na abordagem proposta, os participantes do curso a distância terão sempre um feedback, pois o MAIN, além de promover a interação, também fortalece a cooperação entre os participantes, agregando o grupo e motivando os participantes do processo de ensino-aprendizagem.

Com a conclusão do protótipo, os testes e a respectiva verificação de sua influência no AVA, conforme obedece ao cronograma de atividades, a ser desenvolvido ao longo de 2013, o MAIN será disponibilizado como proposta para os cursos EaD do Núcleo de Ensino a Distância da Universidade Federal de Roraima.

Os trabalhos em andamento que darão prosseguimento à pesquisa centram-se na busca de resultados favoráveis acerca do projeto e suas implementações posteriores, colaborando para a criação de agentes mais especializados, que possam contribuir, de forma significativa, com a EaD.

Diante da crescente demanda dos ambientes e das novas tecnologias desenvolvidas em prol do ensino, espera-se, com este trabalho, contribuir para que novas ferramentas computacionais e metodologias possam ser criadas e consolidadas, de forma a estabelecer novos caminhos e horizontes para o processo de ensino-aprendizagem, evitando-se desta forma, a evasão estudantil e a falta de interatividade no AVA dos estudantes nos cursos na modalidade EaD.


��

6. Referências

AGENTTOOL(2013). Disponível em: <http://agenttool.cis.ksu.edu/>. Acesso: 05/02/2013. ALENCAR, Márcio Aurélio dos Santos, NETTO José Francisco de Magalhães.(2012)

“Sistema Multiagente para Apoiar a Percepção e o Acompanhamento de Atividades em Ambientes Virtuais de Aprendizagem”. In: Anais do XXIII Simpósio Brasileiro de Informática na Educação, Rio de janeiro/RJ.

BICA, Francine. “Eletrotutor III: Uma abordagem multiagente para o Ensino à distância”. Porto Alegre : PPGC da UFRGS, 2000.

BRADSHAW, Jeffrey. M. “An introduction to software agents” In: BRADSHAW, J. M. Ed. Software Agents. Massachusetts: MIT Press, 1997.

CAMPANA, V. F.; SANCHES, D. R.; TAVARES, O. L.; SOUZA, S. F. de. (2008) “Agentes para Apoiar o Acompanhamento das Atividades em Ambientes Virtuais de Aprendizagem”. In: Anais do XXVIII Simpósio Brasileiro de Informática na Educação, Fortaleza/CE.

DELOACH, S. A., WOOD, M. (2001).“Developing Muiltiagent Systems with AgentTool”. In:Proceedings of Lecture Notes in Artificial Intelligence. Springer – Verlag. Berling, 2001.

JADE, Java Agent Development Framework. (2013) Desenvolvido por TILAB. Disponível em: <http://jade.tilab.com>. acesso: 05/02/2013.

LAZZAROTTO, Lissandra Luvizão. (2010).“Sistemas multiagentes na avaliação pedagógica e na detecção do perfil cognitivo dos alunos: proposta de modelo para uso em ambientes de ensino a distância”. Minas Gerais. PPGC da UFV.

LÉVY, Pierre. “Cibercultura”. São Paulo: Editora 34, 1999. LYRA, Felipe, SANTOS Neide. (2012) “Agentes de Software no Monitoramento de

Alunos em Educação a Distância”. In: Anais do XVIII Workshop de Informática na Escola, Rio de Janeiro/RJ.

MUSA, Daniela Leal. “Um Sistema de Alertas para Ambientes de Ensino na Internet”. Porto Alegre: PPGC da UFRGS. 2001. Disponível em:<http://www.lume.ufrgs.br/bitstream/handle/10183/1877/000311269.pdf?sequence=1> acesso: 21/01/2013.

HIBERNATE (2013). Disponível em:< http://www.hibernate.org/about > acesso: 05/02/2013

WOOLDRIDGE, Michael. (2002) “An Introduction to Multiagent Systems”. Editora Wiley: England, 2002.

MOODLE (2013) “Modular Oriented-Object Dynamic Learning Environment”. Disponível em: < http://docs.moodle.org/24/en/Philosophy>. Acesso: 05/02/2013.

TORI, Romero. “Educação sem distância: as tecnologias interativas na redução de distâncias em ensino e aprendizagem”. São Paulo. Editora Senac. São Paulo. 2010.


��

Desenvolvimento de Um Aplicativo Para Identificar Discente Com Problema de Compreensão de Texto

Wollace de Souza Picanço1, Anderson F. Esteves1, Ricardo da Silva Barboza1, Wanderlan Albuquerque1

1 Curso Superior em Licenciatura em Computação – Centro Universitário do Norte – Laureate International Universities (UNINORTE)

Manaus – AM – Brasil ZROODFH�#PVQ�FRP�{wcacarvalho,rsbarbosa,anderson.esteves} @gmail.com

Abstract. This article aims to develop a game via Digital TV to help the teacher to identify the possible factors that contribute to the difficulties of the students' understandings of texts. In this context, the application was modeled, implemented, tested in the educational setting and the results were satisfactory.

Resumo. Este artigo tem como objetivo desenvolver um jogo via TV Digital para auxiliar o docente a identificar os possíveis fatores que contribuem para as dificuldades decompreensões de textos dos discentes. Neste contexto, o aplicativo foi modelado, implementado, testado no cenário educacional e os resultados foram satisfatórios.

1. IntroduçãoProfessores de uma escola identificaram na Educação de Jovens e Adultos (EJA), que tanto jovens quanto adultos a partir de 18 anos, não compreendem os textos apresentados pelos docentes.

Entende-se que uma das causas dessa problemática, relaciona-se com a história cultural do cidadão, com base em [Luckesi 2005], o leitor-objeto, em termos de história da cultura, foi sempre tão somente instrumento de armazenamento da informação. Já o leitor-sujeito, dedica-se a uma atividade que não pode delegar a nenhum instrumento, pois o mesmo cria novas interpretações da realidade. É na postura de leitor-sujeito que é possível haver transformação em leitor-autor, papel daquele que não só recebe mensagens, como também as cria e as transmite com nova dimensão.

Nesse sentido, migra-se o questionamento de como os docentes identificarão em 360 (trezentos e sessenta) alunos, as deficiências ou as proficiências de compreensões de textos? Este questionamento surgiu, com a necessidade de organizar os alunos, visando à sistematização das dificuldades. Dessa forma, criam-se turmas de alunos de acordo com suas dificuldades.

A partir dessas identificações, sentiram-se as necessidades de elaborar um recurso que auxiliasse os docentes nessas identificações. Esse recurso seria por meio das interações de docente, discente e jogo. Contudo, o jogo é um objeto de aprendizagem, que podem ser entendidos como “qualquer entidade digital ou não digital que possa ser usada, reusada ou referenciada durante aprendizagem” [IEEE 2010 apud Moraes et al. 2011]. No entanto, devem-se incentivar programas educacionais que proporcionem ambientes de jogos interativos, pois segundo [Jesus et al. 2008], um programa educacional que tem como modelo de ambiente um jogo, caracteriza-se normalmente por conter telas visualmente atrativas, eventualmente com sons, animações e de fácil interação do usuário com o sistema. Em outras palavras, estas características e possibilidades, descrevem alguns elementos que foram inovados na TV Digital Brasileira.


��

Atualmente o sinal digital já é uma realidade nas televisões, onde surgiu no contexto histórico, como uma das principais fontes de informações, culturas e entretenimentos. Porém, a característica mais interessante da TV Digital combinada com um canal de retorno são as possibilidades das criações de aplicativos interativos.

Assim, propõe-se desenvolver um aplicativo via TV Digital, que pudessem auxiliar os docentes a identificar os alunos com dificuldades de interpretações de textos. Portanto, este trabalho de pesquisa foi dividido em quatro seções. A primeira seção contextualizou o trabalho; A segunda seção aborda o método utilizado; A terceira seção o estudo de caso visando às verificações da eficiência do aplicativo e da problemática e, finalmente a ultima seção estão às considerações finais.

2. MétodoPropõe-se o método de análise e teste por meio do mecanismo tecnológico, pois o mesmo se funde na observação e, segue o caminho das regras. Com o resultado pode-se deduzir e fazer previsão, que podem ser confirmadas ou negadas. Portanto, o referido método passa pelas seguintes etapas (sublinhadas): problemas que surge, em geral, de conflitos; solução proposta consistindo numa hipótese (nova teoria; dedução na forma de proposições passiva de teste) e teste tecnológico de negação ou confirmação que visa à construção de uma ferramenta para confirmar ou refutar as hipóteses.

2.1. Problemas A Educação de Jovens e Adultos é uma modalidade da Educação Básica, que garante a jovens e adultos (a partir de 18 anos) o direito à formação na especificidade de seu tempo humano e assegura-lhes a permanência e a continuidade dos estudos ao longo da vida [MEC 2012]. Assim, analisaram-se em alguns alunos suas dificuldades inerentes as compreensões de textos e identificaram que os mesmos possuem grandes dificuldades.

Essa problemática, hipoteticamente, poder-se-ia minimizar, caso os professores pudessem inferir e organizar de forma eficiente, os alunos com seus respectivos problemas. Dessa forma, sistematizariam os problemas de acordo com os seguintes fatores: Análise dos Elementos, Análise das Relações e Análise da Estrutura. Em virtude disso, a gestão pedagógica organizaria as turmas de alunos conforme os fatores identificados e, portanto, possibilitariam as sistematizações metodológicas especificas para cada caso. Assim , algumas questões que se buscam respostas são:

P¹: Como identificar o leitor que tem dificuldade com estes fatores? P²: Um mecanismo tecnológico ajudaria na identificação? Estas perguntas foram formuladas para compor a hipótese norteando à produção de uma

ferramenta esta propõe identificar alguns fatores que, por sua vez, serão considerados aqui como “fatores de entendimentos”, este será composto por Análise dos Elementos, Análise das Relações e Análise da Estrutura.

2.2. Hipótese A partir do pressuposto, de que todas as demais variáveis que compõem esses “fatores de entendimentos” sejam semelhantes, iniciaram-se os processos de deduções, onde há textos mais ou menos compreensíveis do que outros, como há também, leitores mais ou menos proficientes que outros. Hipoteticamente, isso se deve a presença ou ausência de certos “fatores de entendimentos”,


��

tanto em textos como em leitores. Assim, os “fatores de entendimentos” essenciais para o desenvolvimento desta pesquisa, foram divididos em três partes. Agora observem a [Tabela 1]. Ela descreve os fatores necessários para os entendimentos de uma obra ou texto.

Tabela 1. “fatores de entendimentos” (Análise de Texto de Lakatos et al 2001)

Fatores Descrição Estes fatores levam os estudantes a:

Análise dos Elementos

A primeira consistir no levantamento de todos os elementos básico constitutivo de um texto, visando à sua compreensão. Os elementos podem aparecer de modo explícito ou implícito, dependendo de como o autor os apresenta. Alguns são facilmente identificáveis outros exigem mais esforço, para melhor entender a mensagem do autor.

a) Aprender a ler, a ver, aescolher o maisimportante dentro dotexto;

b) Reconhecer a organizaçãoe estrutura de um texto;

c) Interpretar o texto,familiarizando com ideia,estilos, vocabulários;

d) Chegar a nível maisprofundo de compreensão;

e) Desenvolver a capacidadede distinguir fatos,hipóteses e problemas;

f) Reconhecer o valor domaterial, separando oimportante do secundário;

g) Encontrar, relacionar aideia principal

h) Identificar as conclusões eas bases que as sustenta.

Análise das Relações

A segunda parte tem como objetivo encontrar as principais relações, em estabelecer conexões com os diferentes elementos constitutivos do texto. Uma análise mais completa exige não só a evidencia das partes principais do texto, mas também a indicação de quais delas se relacionam com a hipótese central.

Análise da Estrutura

A terceira verifica-se as parte de um todo, procurando evidenciar as relações existentes entre elas. As estruturas podem ser: estático ou dinâmico.

Estes “fatores de entendimentos” descrito na [Tabela 1] identificarão as competências desses leitores durante a implementação do aplicativo, isto é, quando se privilegia o texto, por exemplo, pressupõe-se que o leitor tenha conhecimento do verbo, adjetivo, substantivo entre outros. Dessa forma, pode-se deduzir que o leitor compreende o texto; Caso contrario, o mesmo acontece quando ele não compreende esses “fatores de entendimentos”. Para melhor entendimento, observa-se a hipótese abaixo:

Se Maria compreende os “fatores de entendimentos” então, compreenderá a obra. Ora ela não compreende a obra. Então, Maria não compreende os “fatores de entendimentos”.

Assim, esta seção tem como objetivo identificar à problemática e esclarecer que a ferramenta a ser desenvolvida, conterá os “fatores de entendimentos” em sua base de conhecimento.


��

Dessa forma, propõe-se desenvolver um aplicativo via TV Digital interativa e que tenha a responsabilidade de inferir os “fatores de entendimentos”.

Portanto, iniciou-se o processo de desenvolvimento de um jogo de compreensão de texto, pois, conforme [Pietruchinski et al. 2011], os jogos no processo de ensino e aprendizagem são ferramentas capazes de auxiliar no processo educativo, desde que sejam planejados e trabalhados de uma forma crítica, que possibilite a aprendizagem de uma maneira significativa ao aprendiz.

2.3 Teste Tecnológico de Negação ou Confirmação O desenvolvimento do aplicativo será balizado pelas seções: 2.3.1 Desenvolvimento da Arquitetura; 2.3.2 Implementação do aplicativo.

2.3.1 Desenvolvimento da Arquitetura A [Figura 1] apresenta um esquema da arquitetura. Esta foi composta por quatro componentes básicos: (i) Base dos “fatores de entendimento”, (ii) Mecanismo de inferência, e (iii) Subsistema de explicação [Fernandes, 2005].

(i) Base dos “fatores de entendimentos” é formada pelas regras e procedimentos que compõe especificamente um determinado texto ou obra (elementos básicos constitutivo de um texto como: descrição objetiva ou subjetiva; elementos de coesão e coerência;

(ii) Mecanismo de inferência é responsável pela tomada de decisões e julgamentos baseados em dados simbólicos contidos na Base dos “fatores de entendimentos”;

(iii) Subsistema de explicação é responsável em explicar ao usuário a linha de raciocínio que utilizou para chegar a uma conclusão;

Em suma, tal arquitetura funciona da seguinte maneira: o modulo inicia com o menu, este modulo tem como opções outros módulos conectados a ele, como: ajuda, sobre, sair e jogo. No modulo jogo existem três níveis de fluxos: texto básico, responsável pela Análise dos Elementos; texto intermediário, responsável pela Análise das Relações e texto avançado, que Analisa as Estrutura. Estas são inferidas através do Ciclo-Pex e do Ciclo-K. Para melhor entendimento conceituaram-se estes:

• Ciclo-Pex: é um conjunto de atividades que tem como principal objetivo analisarum elemento que compõe um “fator de entendimento”, que poderá ser verdadeiro oufalso. Estas atividades são compostas pelos seguintes encadeamentos genéricos:Ciclo-Pex equivale a Jogo�Pergunta�Mecanismo de Inferência�Base dos “fatoresde Entendimentos”�Subsistema de Explicação�Feedback. Para melhorentendimento observe-se a [Figura 2].

• Ciclo-K: são as conjunções dos Ciclo-Pex’s que tem como principal objetivoanalisar, todos os elementos que compõem um “fator de entendimento”, os quaispodem ser verdadeiros ou falsos. Genericamente são: Ciclo-Pex¹ � Ciclo-Pex² �...Ciclo-Pex�.


��

Figura 1. Mapa conceitual da arquitetura

Figura 2. Encadeamento genérica do Ciclo-Pex

O “fator de entendimento” foi representando por regras IF-THEN e Redes Neurais com Ciclos (Feedback), conforme [Russell e Norvig 2004], é uma maneira bastante utilizada nos diversos Sistemas Especialistas ou em Redes Neurais existentes, onde o conhecimento é representado através de pares condição-ação, na forma de regras Se <condição> Então <ação>.

Assim, todos os jogos educacionais adotam uma tecnologia para seu desenvolvimento, conforme a adaptação e a necessidade do pesquisador e do software respectivamente [Machado et


��

al. 2011]. Nesse sentido, o aplicativo utilizou o padrão da TV Digital interativa para sua implementação.

2.3.2 Implementação do Aplicativo A [Figura 3] representa os módulos de interfaces do aplicativo. Por exemplo: ao acessar o aplicativo, o discente tem como interface inicial o menu; No menu temos as opções de funcionalidades como: ajuda, sobre, jogo e sair . Se o leitor optar pela a opção jogo será mostrado a interface com os livros as quais terá três níveis: o básico, o intermediário e o avançado. Agora para melhor entendimento simulou-se uma atividade:

Pressupõe-se que o aluno inicie o aplicativo; o modulo inicial será o Menu (figura a), este contem as opções: sobre, ajuda, jogo e sair. Agora, ele selecionou a opção jogo (figura b), consequentemente selecionou o nível básico (figura b) e em seguida o aluno deverá ler o módulo do livro (figura c), após isso, inicia-se o módulo jogo (figura d) e durante o percurso do jogo, o leitor receberá o módulo de pergunta (figura e) referente ao texto selecionado; Após respondê-las o Mecanismo de Inferência julgará suas respostas de acordo com as regras definidas. Em virtude disso, o Subsistema de Explicação (figura f), emite ao usuário a linha de raciocínio que utilizou para chegar a uma conclusão. Portanto, após todas essas implicações, o docente ficará responsável pelo diagnóstico final.

Figura 3. Atividade de um Ciclo-Pex inerente a condução do usuário

3. Estudo de CasoUm experimento foi realizado utilizando o aplicativo, uma TV Digital interativa, três docentes e uma amostra de 12 (doze) discentes do ensino fundamental das series finais de uma escola. Os docentes têm como experiência em ensino da Língua portuguesa de 7 a 15 anos. Estes experimentos tiveram como objetivo, verificar com os docentes a utilização do aplicativo em sala de aula e


��

melhorias a serem realizadas, assim como estratégia pedagógica para os docentes utilizarem o jogo de compreensão de texto como ferramenta de apoio no processo de identificações dessas dificuldades.

Desde já, os alunos foram divididos em três turmas T¹ (Análise dos Elementos), T² (Análise das Relações) e T³ (Análise da Estrutura). Os professores receberam as ementas contendo seus respectivos “fatores de entendimentos”. Eles ficaram responsáveis durante um mês pelo processo de ensino-aprendizagem desses alunos. Assim, os alunos foram avaliados pelos professores inicialmente através do pré-teste, no entanto, foi definido aqui nessa pesquisa que tanto o pré-teste (prova por escrita) quanto o pós-teste (jogo de compreensão de texto) valerá 10 (dez) pontos para ser aprovado; Caso contrario reprovado, em virtude disso, pode-se confirmar ou refutar as hipóteses através do aplicativo.

Consequentemente, os mesmos procedimentos foram aplicados no pós-teste, em virtude disso, foi possível comparar os resultados, observa-se a [Tabela 2], ela demonstra os resultados de acordo com as respectivas colunas:

• Coluna Alunos: Identifica os alunos que participaram do experimento;

• Coluna Pré-teste: Representa as notas das provas por escrita;

• Coluna Pós-teste: Representa as notas inferidas pelo aplicativo;

• Coluna Compreensão dos Fatores: Comparação entre pré-teste e pós-teste. Estacomparação confirma tanto a veracidade do pré-teste quanto à deficiência ou a proficiênciado aluno;

• Coluna Eficiência do Aplicativo: Confirmado (quando o leitor acertou todos os “fatoresde entendimentos”) e Refutável (quando o leitor acertou no pré-teste ou exclusivamente nopós-teste a nota 10 e quando o leitor não acertou no pré-teste ou exclusivamente no pós-testea nota diferente de 10).

É interessante ressaltar, que a Tabela abaixo não está avaliando nenhum aluno, e sim, verificando a eficiência do aplicativo em relação ao apoio das identificações, ou seja, ele poderá identificar tanto aluno sem a proficiente quanto o aluno com a proficiente.

Tabela 2. Resultados do experimento (Análise de Texto) Turma: T¹ (Análise dos Elementos) Alunos Pré-teste Pós-teste Compreensão

dos fatores Eficiência do Aplicativo

Aluno-1 6,0 7,0 Não Confirmado Aluno-2 10,0 10,0 Sim Confirmado Aluno-3 10,0 10,0 Sim Confirmado Aluno-4 9,0 10,0 Não Refutável Turma: T² (Análise das Relações) Aluno-5 10,0 10,0 Sim Confirmado


��

Aluno-6 10,0 10,0 Sim Confirmado Aluno-7 10,0 10,0 Sim Confirmado Aluno-8 7,0 9,0 Não Confirmado Turma: T³ (Análise da Estrutura) Aluno-9 8,0 8,0 Não Confirmado Aluno-10 5,0 6,0 Não Confirmado Aluno-11 10,0 10,0 Sim Confirmado Aluno-12 6,0 8,0 Não Confirmado

Assim, a [Tabela 2] confirma que o aplicativo não foi 100% eficiente, pois, demonstrou-se 01 (um) questionamento, ou seja, teve-se 8,4% de questionamento e 91,6% de eficiência, portanto, isto foi considerado aqui aceitável, pois, não prejudica o aluno, e sim, ajuda-o a ter uma base de leitura consistente. Contudo, foram feitos novos experimentos visando à problemática e, desta vez utilizou-se o aplicativo como “identificador”. Aplicou-se num universo de 360 (trezentos e sessenta) alunos e os resultados estão no gráfico abaixo. Assim, o aplicativo identificou 297 (duzentos e noventa e sete) alunos sem proficiências e 63 (sessenta e três) alunos com as proficiências.

Portanto, o aplicativo cumpre a função proposta ao mesmo. Em virtude disso, ressalta-se que através desse aplicativo, foi possível organizar as turmas de alunos inerentes à problemática. Outra possível contribuição pode ser vista na arquitetura do aplicativo, onde a mesma poderá ser adequada a outros aplicativos ou plataformas, norteando propósito específico de identificação, por exemplo: na Matemática, na Geografia, História entre outros. Futuras pesquisas estão sendo desenvolvidas como: mapeamento do conteúdo EJA para um aplicativo denominado Ejapp. Este será um aplicativo desenvolvido na plataforma android e visa converter a metodologia tradicional para uma metodologia digital.

4. Considerações FinaisFoi apresentado neste artigo, o desenvolvimento de um aplicativo para identificar alunos com dificuldades de compreensões de textos. Neste contexto, foram analisadas as possibilidades de identificações, especificamente, os fatores que contribuem para esta problemática. Em virtude disso, identificaram-se os fatores que compõem o texto e com essas identificações, desenvolveu-se um jogo via TV Digital interativa, visando à identificação dessa problemática. Nesse sentido, foi possível organizar os alunos por níveis de dificuldades, facilitando assim, uma metodologia de ensino especifica e voltada de fato para o problema do aluno.

É relevante lembra que este aplicativo não é auto-suficiente, ou seja, deve ser incorporado a outros recursos de aprendizagem principalmente com a presença do professor. A simples exposição dos alunos às informações desconexas, não geram aprendizagem, pois este se supõe intencionalidade. Assim, este aplicativo poderá auxiliar o docente a identificar alunos com


��

dificuldades nas compreensões de textos, ganhando assim, tempo para elaboração de determinado conteúdo especifico e, portanto, reduzido o desperdício com papel e tinta.

Referências Fernandes, Anita Maria da Rocha. Inteligência Artificial Noções Gerais, 2ª impressão.

Florianopolis. VisualBook, 2005. Jesus, R. P. T., Fernandes, A. M. R., Dazzi, R. L. S. e Moreira, B. G. (2008). “Ambiente Virtual de

jogos Educativos que Auxilia na Reabilitação Cognitiva de Pessoas Portadoras de Deficiência Mental”. XIII Simpósio de Informática/ VII Mostra de Software Acadêmico.

Lakatos, Eva Maria., Marconi, Marina A. Metodologia Científica. 4. ed. São Paulo: Atlas, 2001. Luckesi, Cipriano Carlos [et al]. Fazer Universidade: Uma Proposta Pedagógica. 14. ed. São Paulo:

Cortez, 2005. Machado, Alex F. V., Cazetta, Paôla P., Santos, Priscyla C., Figueiredo, Ana Mara O., Sant'ana,

Leandro dos S., Junior, Nilson A. S., Dutra, Sebastião de Freitas E., Clua, Esteban. (2011). Uma Proposta de Jogo Educacional 3D com Questões Didáticas. In: Anais do XXII Simpósio Brasileiro de Informática na Educação.

Ministério da Educação (MEC) 2012. Disponível em:< http://portal.mec.gov.br/index.php?option=com_content&view=article&id=13536%3Amateriais-didaticos&catid=194%3Asecad-educacao-continuada&Itemid=913>[Acesso em 02 nov 2012].

Moraes, M., Raymundo, V., Bocchese, J., Lima,V. (2011). Elaboração de Objetos de Aprendizagem para o LAPREN: Processo de Desenvolvimento e Sistema de Produção. In: Anais do XXII Simpósio Brasileiro de Informática na Educação.

Pietruchinski, Mônica H., Neto, J. C., Malucelli, Andreia., Reinehr, Sheila. (2011). Os jogos Educativos no Contexto do SBIE: uma revisão sistemática de Literatura. In: Anais do XXII Simpósio Brasileiro de Informática na Educação.

Russell, Stuart., Norvig, Peter. Inteligência Artificial Noções Gerais. 2. Ed. Rio de Janeiro: Elsevier, 2004.

Sommerville, Ian. Engenharia de Software. 9º Ed. São Paulo: Pearson Prentice Hall, 2011. !


��

Alert@me, um Sistema de Notificação Inteligente que Utiliza Ambiente Virtual de Aprendizagem, Tecnologia

Multiagente e Serviço de Mensagens Curtas Romero G. da Silva1, Marcelo B. de Souza2,3, Thais O. Almeida3

1Departamento de Ciência da Computação – Universidade Federal de Roraima (UFRR) Caixa Postal 69.310-000 – Boa Vista – RR – Brasil

2Departamento de Matemática – Universidade Federal de Roraima (UFRR) Caixa Postal 69.310-000 – Boa Vista – RR – Brasil

3Núcleo de Educação à Distância – Universidade Federal de Roraima (UFRR) Caixa Postal 69.310-000 – Boa Vista – RR – Brasil

[email protected], [email protected], [email protected]

Abstract. Monitoring activities of a distance learning course is a tough task for anyone who depends only on the computer lab of the educational institution. However, the lives of many people has been facilitated by the use of the mobile device. This paperintroduce the Alert@me using Multiagent technology to notify users of a Virtual Learning Environment (VLE) using the short message service provided by mobile operators. The content of the messages received is based on the list of user-defined interests in the VLE. The system is being developed with an approach that encourages students, tutors, teachers and coordinators to become participatory. Resumo. Acompanhar as atividades de um curso à distância é uma tarefa difícil para quem depende apenas do laboratório de informática de uma instituição de ensino. Entretanto, a vida de muita gente tem sido facilitada pelo uso do aparelho celular. O artigo apresenta o Alert@me que utiliza tecnologia Multiagente para notificar usuários, de um Ambiente Virtual de Aprendizagem, utilizando o serviço de mensagens curtas disponibilizado por operadoras de telefonia móvel. O conteúdo das mensagens recebidas é baseado na lista de interesses do usuário definida no ambiente. O sistema está em fase de desenvolvimento com uma abordagem que estimula estudantes, tutores, professores e coordenadores para que se tornem participativos.

1. IntroduçãoNos últimos anos, a procura por cursos de graduação tem evidenciado o crescimento do número de estudantes na modalidade de Educação a Distância (EaD). Segundo dados do Censo da Educação Superior 2011 [INEP, 2013], foram registradas 992.927 novas matrículas.

A EaD é caracterizada por utilizar meios e Tecnologias de Informação e Comunicação (TICs) para mediar o processo de ensino-aprendizagem no desenvolvimento de atividades didático-pedagógicas [Art. 1º, Decreto Presidencial nº 5622/05]. Entretanto, as Instituições de Ensino Superior (IES) têm trabalhado para ampliar as oportunidades de acesso ao conhecimento nessa modalidade, investindo em


��

pesquisas científicas com o objetivo de melhorar a qualidade da interatividade entre professores e estudantes.

Este trabalho apresenta o Alert@me que emprega tecnologia de Sistemas Multiagente (SMA) para notificar usuários de um Ambiente Virtual de Aprendizagem (AVA), utilizando Short Message Service (SMS) disponibilizado por operadoras de telefonia móvel. O conteúdo das mensagens recebidas é baseado na lista de interesses do usuário definida no ambiente. O sistema visa estimular estudantes, tutores, professores e coordenadores, a se tornarem mais participativos no processo de ensino-aprendizagem.

O restante do artigo apresenta os trabalhos correlatos que serviram como referência e estão contribuindo para o desenvolvimento do Alert@me. Na seção 3, são destacadas as ferramentas utilizadas na construção do sistema. As seções 4 e 5, descrevem o Alert@me e as adaptações realizadas no AVA, respectivamente. O artigo é finalizado com as referências que sustentam as idéias defendidas no desenvolvimento do trabalho.

2. Trabalhos CorrelatosNesta seção, serão apresentados os trabalhos correlatos que serviram de base teórica para a escrita do artigo, dos quais foram extraídos conceitos e abordagens utilizadas na construção do sistema Alert@me.

A pesquisa de [Lim et. al, 2011], utilizou SMS para auxiliar estudantes no gerenciamento, motivação e estímulo no desenvolvimento de atividades. Os autores relatam que a abordagem contribuiu para diminuir as dificuldades enfrentadas na modalidade EaD, além de estreitar a comunicação do estudante com a universidade. Foi desenvolvido por [Campana et al, 2008], um SMA para auxiliar mediadores e aprendizes no monitoramento de atividades no ambiente AmCorA. O sistema melhorou a integração do estudante com o ambiente, fortaleceu o acompanhamento contínuo e o desenvolvimento das suas atividades.

Já o trabalho de [Felippo et. al, 2006], investigou mecanismos que auxiliam participantes de grupos virtuais à coordenarem suas atividades. Os autores utilizaram a tecnologia SMS para notificar usuários sobre atualizações em fóruns de discussão do AVA AulaNet. Eles relataram que a pesquisa obteve a aceitação dos participantes, proporcionou o acompanhamento das atividades sem estarem conectados à internet e reduziu a necessidade de verificação do fórum continuamente. Na seção seguinte, serão apresentadas as ferramentas utilizadas no desenvolvimento do Alert@me.

3. Ferramentas Utilizadas

3.1 MaSE A Methodology MultiAgent Systems Engineering (MaSE) foi utilizada no desenvolvimento do Alert@me. Segundo [DeLoach, 2001], a metodologia é composta por duas fases, análise e modelagem. Cada uma delas possui um conjunto de etapas a serem seguidas que podem ser vistas na Figura 1.


��

Figura 1 – Arquitetura da Metodologia MaSE.

A Figura 1 ilustra as etapas Capturando Objetivos, Aplicando Casos de Uso, Definindo de Papéis e Criando Classes de Agente, Construindo Conversações, Agrupamento das Classes de Agente e Implementação do Sistema que contemplam as fases de análise e modelagem, respectivamente.

O Alert@me se baseou em trabalhos como os de [Silva et al, 2007] e [Souza e Netto, 2010] que utilizaram a metodologia na modelagem de seus SMAs. Segundo [DeLoach e Wood, 2001], a aplicação da MaSE resulta na alta coerência entre seus vários modelos e o desenvolvimento de um sistema que satisfaça os objetivos iniciais do projeto.

3.2 Software agentTool O software agentTool (aT) é uma ferramenta de Engenharia de Software (ES) totalmente interativa que auxilia desenvolvedores na criação de SMAs. Segundo [DeLoach, 2001], o aT implementa as sete etapas da MaSE, vistos na Figura 1, além de oferecer suporte a criação de diagramas, comportamentos de agentes e conversão automatizada de seus modelos de análise em modelos de projeto.

O trabalho de [Bolzan, 2002] contribuiu para adoção da aT no desenvolvimento do Alert@me. O autor afirma que a ferramenta apresenta uma ligação entre as fases da metodologia MaSE, deixando documentado e explicito as definições de cada etapa. Ele destaca ainda que o aT possibilita a verificação de possíveis omissões ou erros no projeto, facilitando o desenvolvimento de SMAs.


��

3.3 O Ambiente Moodle Segundo [Al-Ajlan, 2008], o Modular Object Oriented Dynamic Learning Enviroment (Moodle) é uma ferramenta baseada em teorias sócio-construtivistas, com licença de software open source, que auxilia o processo de aquisição do conhecimento de forma colaborativa. Os trabalhos de [Alencar e Netto, 2012] e [Alencar, 2011] colaboraram para a adoção da ferramenta, pois eles integraram a tecnologia de SMA ao AVA Moodle para apoiar o processo de ensino-aprendizagem. A escolha da ferramenta proporcionou ganho de tempo no desenvolvimento do sistema, devido ao conceito de reutilização de código. Recursos como Chat, Fórum, Log, Perfil de Usuário, Glossário, Lição, Wikis, Envio de Arquivos, entre outros, foram utilizados. Além disso, outros recursos foram ajustados e até adicionados, para a construção do ambiente de atuação dos Agentes Inteligentes (AI).

3.4 JADE O Java Agent DEvelopment Framework (JADE) é um software sob a licença Lesser General Public License (LGPL). Segundo [Bellifemine et al, 2007], a ferramenta implementada em Java simplifica a construção de SMAs. Os trabalhos de [Netto, 2006] e [Vicari et al, 2009], influenciaram na escolha. A utilização do JADE, torna possível a implementação do comportamento dos AIs, colaborando para que eles percebam a ocorrência de eventos no ambiente através de seus pacotes e bibliotecas disponíveis em [JADE, 2013].

3.5 SMS O Short Message Service (SMS) oferece o intercâmbio de mensagens de texto limitado ao tamanho máximo de 140 (cento e quarenta) caracteres entre os usuários [Bodic, 2005]. Alguns trabalhos como [Ismail, 2011], [Nwaocha et al, 2010] e [Rau et al, 2006] contribuíram para a adoção do SMS como ferramenta de apoio ao ensino.

4. Abordagem do Alert@meNesta seção, serão descritos a motivação, a arquitetura e a abordagem utilizada para o desenvolvimento do Alert@me. O sistema tem como objetivo estimular estudantes, tutores, professores e coordenadores, a se tornarem mais participativos no processo de ensino-aprendizagem. Ele utiliza AVA, SMA e SMS para notificar usuários do ambiente através do serviço de mensagens curtas disponibilizados por operadoras de telefonia móvel.

O desenvolvimento do Alert@me foi influenciado pelos trabalhos de [Felippo et al, 2006], [Spósito et al, 2008], [Campana et al, 2008] nos quais apontam que os AVAs não possuem ferramentas que auxiliem usuários no acompanhamento de atividades. Os autores relacionam isso à existência da ocorrência de eventos no ambiente, como a expiração do prazo de entrega de atividades, a criação de novo fórum de discussão, entre outros. Perceber o que está acontecendo nos espaços virtuais facilita o processo de ensino-aprendizagem e melhora a eficácia do processo de colaboração, possibilitando aos usuários prover informações que estimulem a cooperação [Lobato et al, 2007].

O sistema adota o Moodle para suportar as interações sociais entre estudantes e professores. Segundo [Souza, 2011], a ferramenta é uma opção de AVA flexível e interativo, devido as vantagens que oferece. O autor relaciona isso a sua facilidade na


��

utilização, o baixo custo, sua flexibilidade e a instalação da ferramenta em qualquer sistema operacional com suporte a linguagem Personal Home Page (PHP). No desenvolvimento do trabalho foi proposta a seguinte arquitetura composta por recursos de Software e Hardware, que estão sendo apresentados na Figura 2.

Figura 2 – Arquitetura do Alert@me.

Na Figura 2 está sendo destacada a camada multiagente que compõe o sistema. O Alert@me utiliza uma sociedade de AIs que interagem num ambiente com a finalidade de alcançar seus objetivos de projeto, onde cada um emprega características como autonomia, habilidade social, reatividade e pro-atividade [Wooldridge, 2002]. Além disso, os AIs são baseados na arquitetura Belief Desire Intention (BDI) que os tornam mais robustos e flexíveis, podendo facilmente ser adaptados a novas situações e contextos [Giraffa, 1999].

Segundo [Netto, 2006], a abordagem multiagente proporciona um desempenho melhor quando aplicado em um sistema. Ele relaciona isso a comunicação e cooperação que ocorrem entre os agentes. A Figura 2 apresenta ainda o funcionamento do auxílio ao acompanhamento das atividades do AVA, onde o Alert@me utiliza o SMS para realizar a notificação aos seus usuários. [Silva e Consolo, 2008] destacam o uso de dispositivos móveis em conjunto com o serviço de mensagens curtas. As autoras relatam que o uso dessa tecnologia representa uma alternativa de acesso a informações para os estudantes, gerando mediação pedagógica.

5. Implementação do Ambiente Apoiado por um SMANo desenvolvimento do Alert@me foi realizado a análise dos requisitos iniciais do sistema, conforme a etapa Capturando Objetivos da MaSE. A Figura 3 ilustra seu o Digrama de Hierarquia de Objetivos, desenvolvido com o apoio da ferramenta aT.


��

Figura 3 – Digrama de Hierarquia de Objetivos do Sistema.

Para alcançar os objetivos do sistema destacados na Figura 3, foi necessário entender a complexidade das 198 (cento e noventa e oito) tabelas que compõem o banco de dados (BD) do Moodle. O mapeamento do BD será utilizado pelos AIs que irão acompanhar os eventos do AVA, geradas a partir das interações entre Aluno/Professor, Aluno/Ambiente e Professor/Ambiente. Para utilização do Alert@me foram alterados trechos de código do Moodle e inserido na interface gráfica a aba Lista de Interesses no Perfil do Usuário, conforme pode ser visto na Figura 4.

Figura 4 – Aba de Lista de Interesses no AVA.

Na aba Lista de Interesses estão sendo apresentadas as opções de alertas baseado no perfil do usuário (Estudante, Professor, Tutor e Coordenador) de modo que, deverão selecionar as notificações de seu interesse para cada curso no qual estão vinculados e salvar as configurações desejadas, conforme ilustra a Figura 5.


��

A seleção das opções destacadas na Figura 5 permitirá o acompanhamento das atividades ocorridas no ambiente pelo sistema Alert@me que é apoiado por um SMA composto pelos AIs Finder Agent, Manager Agent, Postman Agent e Help Tutor Agent com funcionalidades específicas.

O Finder Agent realiza o acompanhamento dos novos eventos no AVA. O agente atua nas tabelas do ambiente em busca de criação de chats, atualizações em fóruns de discussão, prazo de entrega de atividades, entre outros. Além disso, ele é responsável por salvar novidades encontradas no Moodle para o BD do Alert@me.

O Manager Agent analisa a lista de interesse pessoal de estudantes, tutores, professores e coordenadores definida no ambiente com os eventos armazenados no BD do Alert@me. Seu objetivo é encontrar usuários interessados, além de estruturar a notificação através de elementos de percepção e repassar a informação para o Postman Agent.

Postman Agent transmite informações repassadas pelo Manager Agent para aparelhos celulares dos usuários através de alertas SMS. Ele também é responsável por gerenciar sua conexão com a rede da operadora que é realizada através de um modem 3G.

Help Tutor Agent coleta informações sobre o desempenho dos estudantes em cursos nos quais estão matriculados. O agente auxilia professores e tutores, realizando a verificação da presença do estudante no ambiente, sua participação em atividades propostas, se existem tarefas pendentes, entre outros.

Na próxima sessão, serão apresentadas as conclusões parciais e os trabalhos em andamento do sistema Alert@me.

Figura 5 – Notificações Disponíveis aos Usuários.


��

6. Conclusões Parciais e Trabalhos em AndamentoEm geral, os AVAs utilizam mecanismos de monitoramento limitados, isolando informações sobre a ocorrência de eventos. Isto dificulta a percepção dos usuários, pois ficam limitados a acessar informações do curso somente quando estão conectados ao ambiente. Por esta razão é que está sendo proposto o sistema Alert@me com uma abordagem que aproxima usuários de um curso à distância de qualquer novidade que surja no AVA, utilizando o serviço de envio e recebimento de mensagens, baseado na sua lista de interesses.

Outra questão levantada foi o custo/benefício do SMS. A motivação para adotar o serviço se originou também em decorrência de sua simplicidade de uso, o amploalcance geográfico devido às redes móveis, sua popularidade entre seus usuários, além de ser suportada pela maioria dos aparelhos GSM. No entanto, o emprego dessa tecnologia no Alert@me agrega custos financeiros e sua viabilidade dependerá de planos oferecidos por operadoras do setor.

Atualmente o Alert@me está em fase de desenvolvimento, obedecendo o cronograma de atividades da pesquisa. Após a conclusão do sistema, ele será validado, testado e experimentado com alunos de um curso à distância oferecido pelo Núcleo de Educação a Distância (NE@D) da Universidade Federal de Roraima (UFRR). Portanto, espera-se que a continuidade do trabalho contribua para a melhoria do processo de ensino-aprendizagem e torne participativos estudantes, tutores, professores e coordenadores.

Referências Alencar, M. A. S. (2011) “Sistema Multiagente para Apoiar a Percepção e o

Acompanhamento de Atividade em Ambientes Virtuais de Aprendizagem”.Dissertação (Mestrado em Informática). PPGI. Universidade Federal do Amazonas – UFAM, Amazonas – AM, 2011.

Alencar, M. A. S. e Netto, J. F. M. (2012) “Sistema Multiagente para Apoiar a Percepção e o Acompanhamento de Atividades em Ambientes Virtuais de Aprendizagem”, In: XXIII Simpósio Brasileiro de Informática na Educação, 2012, Rio de Janeiro, RJ. Anais do XXIII Simpósio Brasileiro de Informática na Educação, 2012.

Al-Ajlan, A. S. (2008) “Why Moodle”. In: Future Trends of Distributed ComputingSystems 2008 – FTDCS08. 12th IEEE International Workshop.p. 58-64. IEEE, 2008.

Bellifemine, F.; Caire, G. e Greenwood, D. (2007) “Developing multiagent systems with JADE”. Editora Wiley, 2007.

Bodic, G. L. (2005) “Mobile Messaging: Technologies and Services SMS, EMS and MMS”. 2. ed. England: John Wiley and Sons, 2005, 432p.

Brasil, Decreto nº 5.622, de 19 de Dezembro de 2005. Regulamenta o art. 80 da Lei no 9.394, de 20 de dezembro de 1996, que estabelece as diretrizes e bases da educação nacional. Presidência da República, Brasília, DF, 19 de Dezembro de 2005.


��

Brasil. Ministério da Educação. Instituto Nacional de Estudos e Pesquisas Educacionais Anísio Teixeira – INEP (2013). Dados do Censo da Educação Superior 2011. Brasília: INEP.

Campana, V. F. ; Sanches, D. R. ; Tavares, O. L. e Souza, S. F. (2008) “Agentes para Apoiar o Acompanhamento das Atividades em Ambientes Virtuais de Aprendizagem”, In: XIX Simpósio Brasileiro de Informática na Educação, 2008, Fortaleza, CE. Anais do XIX Simpósio Brasileiro de Informática na Educação, 2008.

DeLoach, S. A. (2001) “Analysis and Design using MaSE and agentTool”, In: Proceedings of the 12th Midwest Artificial Intelligence and Cognitive Science Conference – MAICS, 2001. Miami University, Oxford, Ohio, March 31 - April 1, 2001.

Filippo, D.; Gerosa, M. A.; Pimentel, M.; Fuks, H. e Lucena, C. J. P. (2006) “Sempre Atento ao Fórum: Alertas SMS para Suporte à Coordenação dos Aprendizes”, In: XVII Simpósio Brasileiro de Informática na Educação, 2006, Brasília, DF. Anais do XVII Simpósio Brasileiro de Informática na 2006.

Giraffa, L. M. M. (1999) “Uma Arquitetura de Tutor Utilizando Estados Mentais”. Tese (Doutorado em Ciência da Computação). Programa de Pós-Graduação em Computação – PPGC. Universidade Federal do Rio Grande do Sul – UFRGS. Porto Alegre – RGS, 1999.

Ismail, S.M. (2011) “Um Ambiente Virtual de Aprendizagem que Utiliza Avaliação Formativa, a Tecnologia de Mensagens Curtas e Dispositivos Móveis”. Dissertação (Mestrado em Engenharia Elétrica). Programa de Pós-Graduação em Engenharia Elétrica – PPGEE. Universidade Estadual de Campinas – UNICAMP. Campinas – SP, 2011.

JADE, Java Agent DEvelopment Framework. (2013) Desenvolvido por TILAB. Disponível em: <http://jade.tilab.com>. Acesso em: Dezembro de 2013.

Lim, T.; Fadzil, M. e Mansor, N. (2011) “Mobile Learning via SMS at Open University Malaysia: Equitable, Effective, and Sustainable”, In: The Internacional Review of Research in Open and Distance Learning. Vol. 12, N. 2, ISSN. 1492-3831, February, 2011.

Lobato, L. L.; Gomes, A. S.; Monteiro, B. S. e Nibon, R. (2007) “Aspectos de Percepção como Instrumento de Acompanhamento e de Avaliação em Ambientes Virtuais” In: I Workshop sobre Avaliação e Acompanhamento da Aprendizagem em Ambientes Virtuais, 2007, São Paulo, SP. Anais do XVIII Simpósio Brasileiro de Informática naEducação, 2007.

Marinho, C. S. R.; Geller, M. T. B. e Sobrinho, M. C. (2011) “O Celular e a alfabetização: Uma Ferramenta de Apoio”. In: XVII Workshop de Informática na


��

Escola, 2011, Aracaju, SE. Anais do XXII Simpósio Brasileiro de Informática na Educação, 2011.

Netto, J. F. M. (2006) “Uma Arquitetura para Ambientes Virtuais de Convivência: uma Proposta Baseada em Sistemas Multiagente”. Tese de Doutorado, Universidade Federal do Espírito Santo, Vitória.

Nwaocha, V. O. (2011) “SMS–Based Mobile Learning System: A Veritable Tool for English Language Education in Rural Nigeria”. In: Internacional Conference on Information and Communication Technologies and Development, 4, 2010, London. Proceedings of IPID Postgraduate Strand at ICTD 2010. London: Karlstad University Studies, 2011. p. 49-53.

Rau, P. L. P.; Gao, Q. e Wu, L. M. (2008) “Using Mobile Communication Technology in High School Education: Motivation, Pressure and Learning Performance”. In: Computer & Education, Vol. 50, N. 1, January, 2008.

Souza, M. B. e Netto, José F. M. (2010) “Modelagem do Laboratório de Acesso Remoto de Robótica Educacional Utilizando a Metodologia MaSE”. In: II Escola Regional de Informática - Informática e os Desafios Regionais, Manaus. II Escola Regional deInformática - Informática e os Desafios Regionais. Porto Alegre: SBC, 2010.

Silva, J. M. C.; Bavaresco, N. eSilveira, R. A. (2007) “Proposta de um Sistema Multi- agentes para a aplicação de Objetos Inteligentes de Aprendizagem Seguindo o Padrão SCORM”. In: anais do XVIII Simpósio Brasileiro de Informática na Educação, São Paulo/SP. XVIII Simpósio Brasileiro de Informática na Educação. Porto Alegre: SBC - Sociedade Brasileira de Computação. v. 1. p. 175-185, 2007.

Souza, M. B. (2011) “Arcabouço de um Ambiente Telerobótico Educacional Baseado em Sistemas MultiAgente”. Dissertação (Mestrado em Informática). Programa de Pós-Graduação – PPGI. Universidade Federal do Amazonas – UFAM. Amazonas – AM, 2011.

Spósito, M. A. F.; Castro, T. H. C. e Junior, A. N. C. (2008) “Estação de Percepção: Uma Abordagem para o Monitoramento em Ambientes Virtuais de Aprendizagem”, In: XIX Simpósio Brasileiro de Informática na Educação, 2008, Fortaleza, CE. Anais do XIX Simpósio Brasileiro de Informática na Educação, 2008.

Vicari, R. M.; Gluz, J. C.; Santos, E. R.; Primo, T. T.; Rossi, L. H. L.; Bordignon, A.; Behar, P.; Passerino, L. M.; Filho, R. C. M. F. e Roesler, V. (2009) “O Uso de Agentes e Ontologias em Objetos de Aprendizagem”. Projeto OBAA – Relatório Técnico RT-OBAA-O4 – Grupos de Agentes e Ontologias. Porto Alegre, 2009.

Silva, M. G M. e Consolo, A. T. (2008) "Uso de dispositivos móveis na educação - o SMS como auxiliar na mediação pedagógica de cursos a distância", quinto elemento


��

- design da informação, 2008. Disponível em: www.5e.com.br/infodesign/ 146/Dispositivos-moveis.pdf, Acesso em: 22de dezembro de 2012.

Wooldridge, M. J. (2002) “An Introduction To Multiagent Systems”. 1.ed. England: John Wiley & Sons. 2002, 348p.


��

Tecnologias Móveis no Auxílio ao Gerenciamento Patrimonial de Empresas.

Gabriel Sampaio La Greca de Paiva1��7KDLV�2OLYHLUD�$OPHLGD��:HQGHU�$QW{QLR�GD�6LOYD

1Centro de Ciências Tecnológicas– Universidade Federal de Roraima (UFRR)&(3��R�%RD�9LVWD��55��%UDVLO

2Curso de Ciências da Computação – Universidade Estadual de Roraima (UERR)

JDEULHOBVDPSDLRBODJUHFD#KRWPDLO�FRP��ZHQGHU�XHUU#JPDLO�FRP�

Abstract. This study aims to develop a software which carries out asset management of a company, thus giving it the following functions: Requests requisition; Requests loans; Signups assets and management thereof; Registration of users on the system at different levels access and its management, as well as programming system that will acquire data.

Resumo. Este trabalho tem como objetivo desenvolver um software que realize o gerenciamento patrimonial de uma empresa, deste modo fornecendo a ela as seguintes funções: Pedidos de requisição; Pedidos de empréstimos; Cadastros dos bens e o gerenciamento dos mesmos; Cadastro dos usuários no sistema em diferentes níveis de acesso e o seu gerenciamento, assim como a programação do sistema que fará a aquisição dos dados.

1. Introdução

Atualmente a necessidade de uma boa organização em uma empresa ou em órgão público tornou-se imprescindível. As empresas tidas como modernas e dinâmicas possuem bases sólidas de níveis organizacionais e coordenações bem estruturadas na sua administração, obtendo assim um crescimento mais rápido e efetivo (Maximiano, 2002).

Dentro desse planejamento, o campo do gerenciamento patrimonial é fundamental. Ele compreende um conjunto de processos, metodologias e metas para ter o controle sobre o patrimônio do órgão em questão. Este processo é uma das principais metodologias a serem empregadas, e rege a administração dos bens, tanto passivos, quanto ativos, do órgão. Uma de suas finalidades é que se mantenha uma avaliação detalhada sobre cada objeto, para que o surgimento de empecilhos sejam controlados das formas mais precisas possíveis, através dos dados que possuem do patrimônio presente na instituição (Delazaro Filho, 2005).

Neste contexto, a implementação de um sistema para controle patrimonial se mostra como uma boa opção para a automatização deste processo, assegurando a confiabilidade dos dados, o objetivo da gerência dos bens de uma forma sofisticada e dinâmica, e mantendo a segurança dos dados cadastrados. Desta forma, a descentralização desta solução tecnológica se tornou um dos grandes pontos a serem abordada, e desenvolvida, por este trabalho, através da criação de um sistema móvel.

Com o crescimento da utilização de sistemas móveis, a possibilidade do acesso a informações remotas independente do lugar em que o usuário se encontra se tornou uma das grandes funcionalidades a serem implementadas em sistemas que antes eram só fornecidos para computadores. Hoje em dia a grande popularização dos dispositivos móveis, como, celulares e smartphones, fez com que o acesso a esses sistemas aumentasse de uma forma gigantesca, e uma grande quantidade de pessoas passassem a usar aplicativos e começassem a acessar estes sistemas. Dessa forma, a criação de um aplicativo para a utilização de um sistema de gerência patrimonial traz um novo conceito de dinâmica e o surgimento de várias facilidades, e serviços a serem utilizados pelo usuário (Oliveira, 2011).

A Sampayo Ferraz Contadores, empresa de contabilidade no estado de Roraima, desde a sua criação não possuía um sistema semelhante ao descrito nesse trabalho, desse modo não havendo gerência


��

sobre o seu patrimônio. Desde o dia 15 de fevereiro de 2013, a empresa adotou o protótipo do sistema descrito nesse trabalho, sendo, assim, realizadas algumas modificações para a melhor utilização e correção de erros do sistema.

Aliado a criação desse sistema, também foi desenvolvido um sistema para iOS, sistema da Apple para os seus dispositivos portáteis, que implementa o conceito de mobilidade para o gerenciador patrimonial.

Através de ambos, tanto o sistema web quanto o móvel, é possível realizar cadastro e busca de equipamentos, e solicitar requisições e empréstimos dos bens patrimoniais.

Exatamente sobre esta implementação que este trabalho se apresenta, com o objetivo de otimizar os serviços de gerenciamento patrimonial da Sampayo Ferraz e aliá-los a modernidade da tecnologia móvel.

2. Organização Empresarial Organização é o modo em que se organiza um sistema, para que através do planejamento ela consiga ser atingida, deste modo, facilitando, o alcance de um objetivo fim. Em outras palavras, organizar é o processo de reunir recursos físicos e principalmente os humanos, essenciais para a consecução das metas de uma empresa (Montana, 2003). Ela necessariamente possui dois sentidos, um em que a combinação de esforços individuais tem por finalidade realizar propósitos coletivos, e o modo em que ela foi estruturado, dividido e sequenciado o trabalho (Lacombe, 2003).

A organização empresarial implementa este conceito nas empresas através do gerenciamento de pessoas, amparadas pelas máquinas e outros equipamentos que facilitam o trabalho, para capitalizar recursos financeiros e outros. Juntando todos esses fatores orientados a um objetivo comum, temos a organização (Bilhim, 2006).

3. Gerenciamento Patrimonial

A gestão patrimonial é um conjunto de processos, metodologias e metas que são aplicadas para o correto controle dos bens da empresa. Essas metas, basicamente, são aplicadas ao patrimônio da empresa, que compreende os bens ativos, e os passivos. O principal processo a ser implantado é o controle patrimonial, necessário para se adequar as legislações vigentes, sendo necessário que a empresa passe por um processo de engenharia de avaliação, onde é efetuado a avaliação de todos os bens da mesma (Addler, 2009).

A importância de uma boa gestão patrimonial consiste no fato de que possuir documentado o real estado de cada ativo, suas condições e características, torna possível mensurar o patrimônio da empresa. Com esses dados, qualquer mudança não planejada no mercado pode ser controlada com uma resolução otimizada do mesmo (Addler, 2009).

Afim de aumentar a confiabilidade dos dados a implantação de um sistema de gestão patrimonial visando a integração dos vários departamentos da empresa é extremamente relevante. Apesar de aumentar a burocracia, este processo garante a segurança das informações coletadas, e a integração de todas as áreas do empreendimento. No entanto para assegurar o sucesso da implantação do gerenciamento é necessário realizar um estudo para verificar a necessidade deste (Addler, 2009).

4. Tecnologia Móvel

Tecnologia móvel é, por definição, toda aquela que permite o seu uso durante a movimentação do usuário. Atualmente ela está presente no cotidiano das pessoas, modificando suas rotinas e a forma de tomar decisões. Um grande exemplo disso é quantidade de pessoas que não consegue ficar sem o seu aparelho celular durante o dia, ou com um tablete, ou um meio de acesso tecnológico (Frederick e Lal, 2011).

Passando de facilidade para necessidade, nos dias de hoje, a mobilidade teve uma evolução rápida, por permitir o acesso a dados e informações em qualquer momento e em qualquer lugar (Frederick e Lal, 2011).

Tendo este tipo de tecnologia começado a atingir as empresas de médio e grande porte, pela facilitação de tarefas particulares, e a melhora da gestão de negócios,


��

possibilitando a integração de dispositivos móveis com sistemas que possuem funções de gerenciamento (Frederick e Lal, 2011).

5. Desenvolvimento Móvel

Desenvolvimento móvel é o processo pelo qual uma aplicação para dispositivos móveis, como assistentes pessoais, assistentes empresariais ou aparelhos de telefones móveis (Frederick e Lal, 2011).

Essas aplicações podem ser pré-instaladas no processo de fabricação do dispositivo ou instalada pelo usuário a partir das várias plataformas de distribuição de serviços moveis que estão disponíveis atualmente (Frederick e Lal, 2011).

O iOS e o Android, são as principais plataformas móveis atualmente e englobam a maior parte de usuários do mercado de smartphones e tablets. Enquanto o iOS é restrito aos produtos do fabricante, Apple, o Android é fornecido em diferentes aparelhos, de diferentes marcas, com isso tendo uma distribuição mais diversificada (Frederick e Lal, 2011).

6. Tecnologias Utilizadas

5.1 Introdução

Este capítulo tem como objetivo demonstrar o protótipo que foi desenvolvido para este trabalho durante o processo de pesquisa do mesmo. O protótipo foi implementado na Sampayo Ferraz Contadores e está sendo utilizado pela empresa até a presente data.

5.2 Tecnologias utilizadas

5.2.1 – PHP

PHP é uma linguagem utilizada para demonstrar conteúdo multimídia na web. Ela é interpretada pelo servidor pelo módulo de mesmo nome, assim gerando a página web a ser visualizada pelo cliente (Sica, 2011).

A linguagem foi criada em 1994 por Rasmus Lerdof, com a intenção de substituir um conjunto de scripts de outra linguagem que ele usava para desenvolver a sua página pessoal.

Atualmente está na versão 5, que possui suporte a apontadores, que significa que no caso de uma modificação em uma versão original de um objeto, todas as cópias sofrem esta alteração (Dall’oglio, 2007). Trata-se de uma linguagem extremamente modularizada, sendo assim ideal para instalação e uso em servidores web.

O PHP também é conhecido pela simplicidade com que oferece conexão a base de dados, como por exemplo: Oracle, Sybase, PostgreSQL, InterBase, MySQL, SQLite, MSSQL, Firebird, etc. (The PHP Project – Internet). Também oferece suporte a protocolos como o POP3 e HTTP, sendo possível abrir sockets e interagir com outros protocolos.

O PHP é um software livre e com o seu código aberto publicado sob a PHP License (The PHP License – Internet).

5.2.2 – MySQL

MySQL é um sistema de gerenciamento de banco de dados, que faz utilização da linguagem SQL como interface (MySQL – Internet).

Ele foi criado na Suécia por David Axmark, Allan Larsson e Michael Widenius em 1994, hoje estando em sua versão 5.6.5, tendo em seu desenvolvimento aproximadamente 400 profissionais (Amaral, 2008).


��

A atual popularidade do MySQL se deve em grande parte a sua fácil integração com a linguagem PHP incluída nos pacotes de hospedagem que os servidores oferecem atualmente (Thomson e Welling, 2005).

O SGBD oferece suporte a Unicode, Full Text Indexes, replicação, Hot Backup, GIS, OLAP, entre outros recursos de banco de dados (Cartwright, 2005).

5.2.3 – Objective-C

Objective-C é uma linguagem de programação reflexiva orientada a objeto. Atualmente é utilizada principalmente em Mac OS X e GNUstep, e é a principal linguagem utilizada nos aplicativos estruturais NeXTSTEP, OPENSTEP e Cocoa (Cox, 1983).

Também possui grande popularidade devido a ser a linguagem adotada no sistema presente em telefones da Apple, iPhones, o iOS. Os desenvolvedores que desejam desenvolver para esse sistema móvel, devem possuir no seu computador o aplicativo XCode, que é utilizado para a construção dos códigos em Objective-C (Dalrymple e Knaster, 2010).

Foi desenvolvida em 1980 por Brad Cox e Tom Love, e atualmente está na sua versão 2.0, que foi desenvolvida em outubro de 2007 (Cox, 1983). A sua sintaxe orientada a objeto deriva do Smalltalk e a não orientada a objeto é idêntica da linguagem C. Essa sintaxe orientada a objeto é baseada na transferência de mensagem entre os objetos.

5.2.4 – iOS

iOS é o sistema móvel adotado e desenvolvido pela empresa Apple para o seu smartphone, o iPhone, e depois se expandindo para o iPod Touch, iPad e Apple TV. Ele foi desenvolvido para que o usuário tenha um a manipulação direta do dispositivo através de gestos em multi-touch. Ele possui quatro camadas de abstração, que são: a camada Core OS, a Camada Core Services, a camada mídia, e a camada Cocoa Touch (Hillegass e Conway, 2012).

O iOS foi apresentado em 2007 pela Apple, tendo sido lançado no ano seguinte. Atualmente se encontra na versão 6 que possui 200 novas funcionalidades em relação a versão anterior (Honan, 2007).

Os desenvolvedores que desejam trabalhar com iOS devem possuir conhecimento da linguagem Objective-C e fazer o download do aplicativo XCode no site da Apple. O Aplicativo conta com uma interface de desenvolvimento e um simulador de iPhone para a simulação do aplicativo que está sendo desenvolvido.

5.3 Implementações realizadas

Para a utilização do sistema móvel, o único acesso liberado na empresa Sampayo Ferraz foi o do Sr. Gerente da Sampayo Ferraz, Pedro Henrique Ferraz, o qual possuía um iPhone 4, com o sistema iOS 6, para que fosse instalado o aplicativo e utilizado pelo mesmo. Tendo sido iniciada em fevereiro de 2013, a implementação teve como primeiro etapa uma apresentação para o gerente da empresa, Pedro Henrique Ferraz, a quem coube definir alterações e ajustes que foram realizados no projeto, para que ele se adequasse as normas exigidas. Após a realização das alterações, foi realizada uma nova apresentação para a demonstração do layout, este, aprovado e adotado para a execução do projeto.

O Layout aprovado tem como intenção dar uma maior facilidade ao usuário no que diz respeito ao acesso de funções, assim bem como demonstrar a marca da empresa, suas cores e seus parceiros. Como segue abaixo, ele possui a logo da empresa na parte superior e o menu distribuído em sua tela principal.


��

Figura 1: Layout aprovado pela Sampayo Ferraz

A primeira função que foi demonstrada foi a tela de requisição e como o usuário pode realizar o pedido de materiais e acompanhar os mesmos até que fossem liberados ou negados pela gerente do sistema. Para o acesso a essa função, é realizada a escolha da opção “Requisições”, onde o usuário será levado a uma tela onde ele possui acesso a uma abertura de requerimento, aos seus requerimentos ativos e a todos os requerimentos referentes ao seu usuário.

Figura 2: Tela de requerimento do sistema móvel.

A segunda função demonstrada foi a tela de empréstimo, para que o usuário ficasse ciente de como abrir e acompanhar o estado do pedido do seu empréstimo, e como realizassem a devolução do objeto que estava em posse na data correta, para que seu cadastro não fosse bloqueado no sistema. Escolhendo a opção “Empréstimos”, o usuário será levado a uma tela onde ele possui acesso a uma abertura de empréstimo, aos seus empréstimos ativos e a todos os empréstimos referentes ao seu usuário.


��

Figura 3: Tela de empréstimo do sistema móvel.

7. Objetivos 7.1 Objetivo Geral

Desenvolver um software que seja capaz de realizar o gerenciamento patrimonial da empresa Sampayo Ferraz, fornecendo um sistema web e um sistema móvel para a realização do mesmo. 7.2 Objetivos Específicos

• Realizar acompanhamento e entrevistas com os funcionários da Sampayo Ferraz responsáveis pelo patrimônio;

• Analisar a forma de administração do patrimônio da empresa Sampayo Ferraz. • Fazer um levantamento das necessidades e possíveis soluções tecnológicas para os

problemas apresentados; • Realizar um estudo sobre as linguagens de programação e ferramentas que serão

utilizadas para o desenvolvimento do aplicativo para iOS; • Desenvolver um sistema para iOS que procure solucionar os problemas da Sampayo

Ferraz referentes ao controle patrimonial; • Realizar testes com o sistema móvel desenvolvido; • Disponibilizar o sistema móvel para ser utilizado pelos funcionários da Sampayo

Ferraz; • Demonstrar as melhorias obtidas com a implementação deste trabalho;

7. Referências

DALL'OGLIO, PABLO. PHP Programando com Orientação a Objetos: Inclui Design Patterns. 1 ed. São Paulo: Novatec, 2007.

DALRYMPLE, MARK. Learn Objective-C on the Macintosh. 1ª Edição, SpiderWorks, 2006.

FLANAGAN, DAVID; FERGUSON, PAULA. JavaScript: The Definitive Guide. 4ª Edição, O'Reilly & Associates, 2002

FREDERICK RAHN, GAIL; RAJESH, LAL. Dominando o desenvolvimento web para smartphone. 1ª Edição, Altabooks, 2011.

LERDORF, RASMUS. The Php Project. Disponível em : < http://news.php.net/php.internals/47120 >. Acesso em: 15/03/2013


��

MACDONALD, MATTHEW. Criação de Sites – O Manual que faltava. 1ª Edição, Digerati Books, 2010.

MAXIMIANO, ANTONIO AMARU. Teoria Geral da Administração: da revolução urbana à revolução digital. Ed. Atlas, 2002.

SICA, CARLOS. HTML: Fale a Linguagem da Internet. 1 ed. Maringá - PR: Independente, 1997.

SICA, CARLOS. PHP COM TUDO. 1 ed. Rio de Janeiro - RJ: Ciência Moderna, 2011.

SICA, CARLOS. PHP Orientado a Objetos: Fale a Linguagem da Internet. 1 ed. Rio de Janeiro - RJ: Ciência Moderna, 2006.

SICA, CARLOS. Programação Segura Utilizando PHP: Fale a Linguagem da Internet. 1 ed. Rio de Janeiro - RJ: Ciência Moderna, 2007.

RAGGET, DAVE. Raggett on HTML 4. 2ª Edição, Pearson Education, 1997.

THOMSON, LAURA; WELLING LUKE. Php e Mysql Desenvolvimento Web. 3ª Edição, Campus, 2005.

Apple unveils iPhone. Disponível em : <

http://www.macworld.com/article/1054769/iphone.html>. Acesso em: 15/03/2013

ECMAScript Language Specification. Disponível em : < http://www.ecma-international.org/publications/files/ECMA-ST/Ecma-262.pdf >. Acesso em: 15/03/2013

iOS Developer Libray. Disponível em : <

http://developer.apple.com/library/ios/navigation/ >. Acesso em: 15/03/2013

The object oriented pre-compiler: programming Smalltalk 80 methods in C language. Disponível em : < http://dl.acm.org/citation.cfm?id=948095 >. Acesso em: 15/03/2013

MySQL :: Case Studies. Disponível em : < http://www.mysql.com/why-mysql/case-studies >. Acesso em: 15/03/2013

MySQL :: Case Studies. Disponível em : < http://www.mysql.com >. Acesso em: 15/03/2013

MySQL 5.0 open source database. Disponível em : < http://review.techworld.com/applications/346/mysql-50-open-source-database/ >. Acesso em: 15/03/2013


��

O Que é Gestão Patrimonial. Disponível em : < http://www.swink.com.br/economia/gestao/o-que-e-gestao-patrimonial/ >. Acesso em: 15/03/2013

Programming with Objective-C. Disponível em : <

https://developer.apple.com/library/ios/#documentation/Cocoa/Conceptual/ProgrammingWithObjectiveC/FoundationTypesandCollections/FoundationTypesandCollections.html >. Acesso em: 15/03/2013

The Php License. Disponível em : < http://www.php.net/license/3_01.txt >. Acesso em: 15/03/2013

Versions of JavaScript. Disponível em : < http://ejohn.org/blog/versions-of-javascript >. Acesso em: 15/03/2013

Why MySQL ? :: Case Studies. Disponível em : < http://www.mysql.com/why-mysql >. Acesso em: 15/03/2013


��

APLICAÇÃO DA REALIDADE VIRTUAL NO AUXÍLIO AO

PROCESSO DE ENSINO-APRENDIZAGEM DA GEOMETRIA ESPACIAL

Maykon Diego Silva Ribeiro1

Wender Antônio da Silva2

ABSTRACT

This paper describes the modeling and implementation of an Educational Software based Virtual Reality titled GERVI - Geometry Space and Virtual Reality. The GERVI uses some technologies for

the development of educational software adaptable to the student and teacher. Among these technologies is highlighted Virtual Reality and Moodle. The paper describes the modeling and implementation of geometric objects within the virtual reality environment, followed by a description of the project GERVI technologies, object modeling, learning theory used, and finally, conclusions and proposals for future work.

Keywords: Virtual Reality, Space Geometry, Moodle, Computers in Education, Theory of Meaningful Learning

RESUMO

Este artigo descreve a modelagem e a implementação de um Software Educacional baseado em

Realidade Virtual intitulado GERVI – Geometria Espacial e Realidade Virtual. O GERVI utiliza

algumas tecnologias para o desenvolvimento de um software educacional adaptável ao aluno e professor. Dentre essas tecnologias é destacado a Realidade Virtual e o Moodle. O artigo descreve a modelagem e implementação dos objetos geométricos dentro do ambiente de realidade virtual,

seguido por uma descrição do projeto GERVI, tecnologias de modelagem de objetos, teoria de aprendizagem utilizada e, finalmente, conclusões e propostas de trabalho futuro.

Palavras Chaves: Realidade Virtual, Geometria Espacial, Moodle, Informática na Educação, Teoria

da Aprendizagem Significativa.

1 - Chefe da Divisão de Telemática da Universidade Estadual de Roraima, Bacharel em Sistemas de Informação pela Faculdade Estácio da

Amazônia, Cursando especialização em Engenharia de Sistemas pela ESAB, e-mail: [email protected].

2 – Professor Efetivo da Universidade Estadual de Roraima e Professor da Faculdade Estácio da Amazônia.


��

1. INTRODUÇÃO

Observando as dificuldades enfrentadas no processo de ensino-aprendizagem da

Matemática e considerando que a Geometria Espacial é um dos temas em que os alunos

apresentam maior nível de dificuldade dentre os conteúdos matemáticos. Optou-se por

desenvolver uma pesquisa na qual o objetivo geral foi a elaboração de um ambiente

baseado em realidade virtual e na teoria da aprendizagem significativa para auxiliar no

processo de ensino-aprendizagem da Geometria Espacial, no qual tem-se como foco à

princípio a utilização de 4 (quatro) sólidos geométricos básicos(Cubo, Esfera, Cilindro e

Cone), sendo passível de continuidade por outros acadêmicos futuramente.

Neste sentido, o trabalho desenvolvido teve como objetivos específicos: entender

o funcionamento do ambiente virtual de aprendizagem (Moodle); modelar em 3D o

ambiente de ensino-aprendizagem; elaborar as interações do estudo de caso; testar

protótipo com alunos e professores do curso de Licenciatura da Faculdade Estácio Atual.

Contudo para o desenvolvimento desse software foi utilizado a tecnologia de Realidade

Virtual com o intuito de facilitar a interação do usuário final com o software e o fator que

nos levou a optar por essa tecnologia foi a sua utilização em outros trabalhos na área que

obtiveram resultado positivo, ou seja, o objetivo proposto foi alcançado.

Portanto, faz-se necessário enfatizar que para desenvolver um software na área

educacional a utilização de boas ferramentas de desenvolvimento não são o suficiente,

necessita-se estar bem fundamentado em teorias que possam facilitar o aprendizado do

aluno. Esta foi a razão da opção de embasar o trabalho na teoria da aprendizagem

significativa.

Sendo assim, justifica-se este trabalho pela importância da tecnologia na

educação, pois a Realidade Virtual pode proporcionar alto nível de interação e imersão

simplificando assim o processo de ensino-aprendizagem, pois segundo Ausubel citado

por Silva (2010, p. 38),

Aprendizagem Significativa é o processo que ocorre quando uma informação nova é adquirida mediante um esforço deliberado por parte do aluno em ligar a informação nova às estruturas cognitivas e aos referencias simbólicos já existentes.


��

Kalawski (1993) afirma que, por meio dos ambientes de Realidade Virtual e

Aumentada é possível proporcionar ao aprendiz situações lúdicas, tornando as atividades

mais motivadoras. A escola não pode ficar de fora deste avanço e fazendo das palavras

de Ponte (1997, p. 1) as nossas afirmamos que,

A missão fundamental da escola já não é a de preparar uma pequena elite para estudos superiores e proporcionar à grande massa os requisitos mínimos para uma inserção rápida mercado de trabalho. Pelo contrário,passa a ser a de preparar a totalidade dos jovens para se inserirem de modo criativo, crítico interveniente numa sociedade cada vez mais complexa, em que a capacidade de descortinar oportunidades, a flexibilidade de raciocínio,a adaptação a novas situações, a persistência e a capacidade de interagir e cooperar são qualidades fundamentais.

O ambiente elaborado possibilita ao aluno uma maior compreensão dos objetos

que estão sendo estudados, permitindo assim a visualização desses objetos em três

dimensões (altura, largura e profundidade), pois Oliveira et. al. (2008) enfatiza que, a

educação pode ser tratada como um processo de descobertas, de observação, de

exploração e de construção de conhecimento.

2. DESENVOLVIMENTO DO GERVI

2.1. Modelagem dos Objetos Virtuais

Os objetos virtuais visualizados neste software são baseados nos conceitos da Geometria

Espacial. Podemos ilustrar dessa forma o potencial que este software possui para a aplicação em

áreas educacionais, devido a concepção dos objetos virtuais serem baseados em uma área do

conhecimento específica, neste caso a matemática.

Neste sentido, o presente software possui 4(quatro) objetos geométricos virtuais na cena,

podendo ser acrescentado um número maior de objetos geométricos. Esses objetos foram

modelados na ferramenta Vivaty Studio 1.0. Esta ferramenta possui um alto poder de modelagem,

onde o usuário poucas vezes precisa implementar alguma linha de código. Ao término da

modelagem, os objetos foram exportados para o formato “.wrl” do VRML. A exportação dos

objetos é necessária, pois é preciso executá-lo dentro do ambiente do moodle.

2.2. Implementação da Interface de Realidade Virtual

Para a modelagem do menu inferior onde contém os 4(quatro) objetos geométricos

trabalhados no software, utilizou-se o software de modelagem Vivaty Studio 1.0. A Figura 1 exibe

essa modelagem. O restante da interface foi desenvolvida utilizando-se a linguagem VRML 2.0.


��

Figura 01 - Objetos geométricos modelados no Vivaty Studio 1.0

No arquivo menu.wrl os objetos da Figura anterior possuem ações desenvolvidas em

javascript para a chamada dos objetos que correspondem a eles próprios na cena junto com seus

respectivos menus interativos.

2.3. Funcionamento da Interface de Realidade Virtual

A aplicação de Realidade Virtual, GERVI, possui uma barra de menu no formato dos

objetos geométricos já citados no Desenvolvimento do Sistema. Cada um desses menus pode, nesta

aplicação, chamar outros objetos virtuais na cena juntamente com suas respectivas funcionalidades.

Na parte mais inferior da tela há outra barra de menu que exibem informações detalhadas sobre

cada objeto na cena. A Figura 02 ilustra a interface do software.

Figura 02 – Interface da Aplicação de Realidade Virtual.

Onde:

1. Menus Objetos Geométricos – possuem os formatos dos objetos a serem


��

trabalhados na cena, quando selecionados ficam 70% transparentes e com uma imagem logo acima

com o nome do objeto escolhido. Também possuem rotinas que chamam objetos geométricos

virtuais maiores na cena.

2. Menus de Conceitos dos objetos – possuem links que direcionam o usuário aos

conceitos referentes a cada objeto trabalhado no software.

3. Objeto geométrico Selecionado – objeto chamado pelo menu CONE da barra de

menus geométricos. Onde possui rotinas que possibilitam a interação do usuário com esse objeto

podendo o usuário rotacioná-lo em seu próprio eixo.

4. Menus do objeto selecionado – possuem rotinas que possibilitam a alteração da

forma como esse objeto selecionado irá ser trabalhado pelo usuário.

5. Opções do Objeto – objetivam alterar tanto a visibilidade do objeto selecionado

(transparência) , como também a sua estrutura física (escala) na cena.

3. RESULTADOS DA AVALIAÇÃO DO SISTEMA

O processo de validação do sistema ocorreu da seguinte forma: aplicação de 1(um)

questionário com foco no conteúdo tecnológico e pedagógico proposto neste trabalho o qual foi

aplicado à 30(trinta) alunos do curso de Licenciatura em Computação da Faculdade Estácio Atual e

entrevistas realizadas com 5(cinco) professores do referido curso nas quais foram feitas perguntas

pré-selecionadas que permitiu aos professores a chance de expressar opiniões, criticas e elogios em

relação ao sistema proposto. O questionário aplicado aos alunos foi divido em 14(quatorze)

questões com perguntas fechadas em forma de Checklist.

3.1. Questionário Aplicado aos Alunos

De posse desses dados, tornou-se possível a análise das respostas do questionário aplicado

aos alunos, proporcionando assim uma avaliação dos itens abaixo descritos e para todos foi

elaborado um gráfico comparativo, mas exibiremos somente o gráfico geral.


��

I. Gráfico Geral do Sistema por meio de questionários aplicados

Fonte: Pesquisa de campo realizada, 2011

Figura 03 – Gráfico: Visão Geral do Sistema

No gráfico da Figura 03 ilustra a visão geral do resultado da aplicação dos questionários.

Desta forma, entende-se que por meio do resultado demonstrado no gráfico do questionário torna-se

possível afirmar que o software proposto neste trabalho é funcional, podendo ser utilizado como

auxílio em salas de aulas e também em conjunto com outras aplicações educacionais, porém, cabe

uma análise mais aprofundada das questões pedagógico-educacionais.

3.2. Entrevista Realizada com os Professores

Entrevista realizada com os professores do Curso de Licenciatura em Computação da

Faculdade Estácio Atual na qual expuseram as suas opiniões respondendo 5 (cinco) perguntas pré-

elaboradas, afim de validar o software proposto.

I. Quanto à Interface (Usabilidade)?

A maioria concordou que o sistema possui uma interface de fácil interação, pois se utiliza

basicamente um navegador e um mouse. Porém, algumas sugestões foram feitas em relação a

usabilidade, uma delas foi: acréscimo de um menu de ajuda para auxiliar o usuário na utilização dos


��

objetos disponíveis na cena. Essa sugestão foi aceita e implementada na versão aqui apresentada.

II. Quanto a facilidade de uso (Funcionalidade)?

Foi constatado que a interface é muito intuitiva não trás nenhuma dificuldade ao

usuário, pois todos os menus estão bem acessíveis. Não houve nenhuma sugestão ou reclamação por

parte dos professores.

III. Quanto ao nível de interação com os objetos disponíveis na cena?

Todos concordaram que os objetos em cena são de fácil manuseio, estão bem visíveis na

cena e que estão bem posicionados em cena. Assim como na pergunta anterior, não houve alguma

sugestão ou reclamação sobre a interação com os objetos na cena.

IV. Quanto a manipulação dos menus interativos (Facilidade de Uso)?

A maioria disse que todos os menus estão bem visíveis, com cores destacáveis, são simples e

intuitivos. Houve algumas reclamações em relação a falta de flexibilidade dos menus.

V. Quanto à aquisição de conhecimento (Obteve-se aquisição de conhecimento)?

O sistema limitou-se a algumas informações dos objetos em cena, porém constatou-se que é

possível alguma aquisição de conhecimento. A sugestão da maioria foi o acréscimo de referências

sobre o conteúdo disponibilizado para pesquisas futuras dos usuários.

3.2.1. Comentários negativos em relação ao software

Foram feitos alguns comentários em relação ao plug-in utilizado (Cortona 3D) no qual

alegou-se que o mesmo oferece alguns aspectos negativos relacionado ao seu funcionamento.

Também foi relatado que a linguagem VRML não foi a melhor opção para este trabalho, porém, é

importante ressaltar que o objeto de estudo não era a linguagem e nem o plug-in e sim a

metodologia proposta.

Sendo assim faz-se necessário informar que levar-se-á esses comentários em consideração

nos trabalhos futuros.

4. CONSIDERAÇÕES FINAIS

Durante esse trabalho, constatou-se que existem diversos softwares de auxílio ao processo

de ensino-aprendizagem da Geometria Espacial. Porém, a maioria proporciona apenas a


��

visualização em 3D de desenhos pedagógicos (Geométricos), sem levar em consideração a forma

que esse sistema será disponibilizado.

Neste artigo é apresentado um software de apoio educacional embasado na teoria da

Aprendizagem Significativa, com a utilização da Realidade Virtual permitindo ao usuário manipular

objetos virtuais dentro de cenários em tempo real de execução.

Deste modo, o trabalho aqui apresentado visou a utilização da tecnologia de Realidade

Virtual para proporcionar aos alunos e professores que trabalham com a Geometria Espacial um

ambiente interativo, enriquecedor, de fácil utilização. Com isso podemos perceber que há muitas

vantagens da sua utilização em salas de aulas.

Devido a sua elevada exigência de abstração, entendemos que o processo de ensino da

Geometria não pode ficar nos dias de hoje sem a utilização de meios tecnológicos para o

desenvolvimento de seus conceitos na formação dos alunos. Acreditando que o papel e o lápis

podem ser limitadores para esse estudo, criamos um modelo que, segundo os próprios alunos é

satisfatório, fácil de usar e que facilita o aprendizado.

Com base nos dados coletados, pode-se concluir que a maioria dos alunos e professores

entrevistados afirmaram-se satisfeitos ou muito satisfeitos. Demonstrando assim, que a utilização

desse software pode vir a ser implementada no processo de ensino-aprendizagem, podendo

proporcionar grandes melhorias a esse processo.

REFERÊNCIAS

BARILI, Elomar C.; CUNHA, Gerson G. A Tecnologia de Realidade Virtual: Recurso Real para Potencializar a Educação. Rio de Janeiro, 2009. Disponível em < www.latec.ufrj.br/revistaeducaonline/vol4_2/2.pdf > Acessado em 18 de Novembro de 2010.

BURDEA, G.; COIFFET C, Virtual Reality technology. New York, NY: JohnWiley and Sons, 2003.

CARRARA, Ariane. Aplicação da Realidade Virtual no Ensino Aprendizagem de Conceitos de Matemática Piracicaba, 2006. Disponível <www.unimep.br/phpg/mostraacademica/anais/4mostra/.../493.pdf > Acessado em 16 de Novembro de 2010.

CRUZ, Cristiano C. A teoria cognitivista de ausubel teoria cognitivista de ausubel. Disponível em

<Www.Robertexto.Com> Acessado em 23 de março de 2011.

DIAS, Vasco P. Dissertação de Mestrado em Comunicação Educacional Multimédia. Universidade aberta, janeiro de 2009. Disponível em < ebookbrowse.com/a/alexandrina-rosa-dias-pereira> Acessado em


��

16 de agosto de 2010.

GIOVANI, José R. BONJORNO, José R. GIOVANI, Ruy Jr. Matemática Fundamental: uma nova abordagem: ensino médio: volume único. São Paulo: Ftp, 2002.

KIRNER, C.; TORI, R. Introdução a Realidade Virtual, Realidade Misturada e Hiper- Realidade Virtual. In. Cláudia Kirner; Romero Tori.(Ed).Realidade Virtual: Conceitos, Tecnologias e Tendencias. 1ed. São Paulo, 2004.

OLIVEIRA, Liliane L. ; VELASCO, Angela D. O ensino de Geometria nas escolas de nível médio da rede pública de Guaratinguetá. Guaratinguetá, 2007. Disponível em < www.degraf.ufpr.br/artigos_graphica/OENSINO.pdf > Acessado em 30 de Abril de 2011.

OLIVEIRA, Francisco C. et al. Colaboração em Ambientes Educacionais com Realidade Aumentada. Piracicaba2008. Disponível em < seer.ufrgs.br/renote/article/view/14712 > Acessado 14 de setembro de 2010.

PELIZZARI, Adriana et al. Teoria da Aprendizagem Significativa Segundo Ausubel, Curitiba Julho de 2003. Disponível em < www.obrasill.com/teoria-da-aprendizagem-significativa-seg > Acessado em 01 novembro de 2011.

PONTE, J. P. As novas tecnologias e a educação. Lisboa: Texto Editora, 1997.

SABBATINI, Renato E. Ambiente de Ensino e Aprendizagem via Internet A Plataforma Moodle.

Disponível em < www.ead.edumed.org.br/file.php/1/PlataformaMoodle.pdf >Acessado em 15 de janeiro de 2011.

SILVA, Wender A. Ambientes Virtuais baseados em Realidade Virtual, Aumentada e Teorias da aprendizagem como metodologias à aprendizagem cooperativa para resolução de problemas matemáticos: Pré-Projeto de mestrado. Boa Vista-RR, 2010.

SILVA, Wender A. Uma arquitetura para distribuição de Ambientes Virtuais de Realidade Aumentada.

Uberlândia, 2008. Disponível em <http://www.bdtd.ufu.br/tde_busca/arquivo.php?codArquivo=2028>

Acessado em 31 de Outubro de 2010.


��

Novas Contribuições e Implementações a um Modelo Formal de Ontologia de Domínio para Biodiversidade

Janaína M. P. Nascimento1,2, Delano Campos de Oliveira2, Clodomir S. Souza Junior1, Fábio A. E. Mendes1, Marcos Paulo Alves de Sousa1,2, Andréa Corrêa

Flôres Albuquerque3, e José Laurindo Campos dos Santos3

1Área de Ciências Exatas e Tecnologia – Centro Universitário do Estado do Pará

(CESUPA). CEP: 66060-230Belém – PA – Brasil

Núcleo de BioGeoInformática – Museu Paraense Emílio Goeldi (MPEG). CEP: 66077-530 Belém – PA – Brasil

3Núcleo de BioGeoInformática - Instituto Nacional de Pesquisas da Amazônia.

CEP: 69060-001 Manaus – AM – Brasil.

{clodomirjr0,camposdelano,fabio.aem,janaina.mayara7, andreaalb.1993, laurocampos2004, marcosp.belem}@gmail.com

Abstract. In recent years, important studies have shown good results in the use of ontology to represent complex biological data. Recently, researchers of the Biodiversity Research Programme of the Ministry of Science, Technology and Innovation, have proposed a domain ontology for Biodiversity, which is a scalable and dynamic model. From this model, this work proposes new contributions and implementations of the model of domain ontology mentioned with the inclusion of entities, relationships and taxonomy related instruments to capture species, aiming to expand the representation of knowledge about biodiversity.

Resumo. Nos últimos anos, importantes trabalhos mostraram bons resultados no uso de Ontologia para representar dados complexos biológicos. Recentemente, pesquisadores vinculados ao Programa de Pesquisa em Biodiversidade do Ministério de Ciência, Tecnologia e Inovação, propuseram uma ontologia de domínio para Biodiversidade, que se trata de um modelo expansível e dinâmico. A partir deste modelo, este trabalho propõe novas contribuições e implementações ao modelo de ontologia de domínio mencionado com a inclusão de entidades, relacionamentos e taxonomia referentes instrumentos para captura e modos de coleta de espécies, visando expandir a representação do conhecimento sobre a Biodiversidade.

1. Introdução

O Brasil é um país florestal, abrigando cerca de 5,5 milhões de km2 de florestas (65% do seu território), o que representa aproximadamente 10% do total das florestas do mundo. Desse total 60% são florestas tropicais e estão situadas na Amazônia Legal, possuindo a biodiversidade mais rica do mundo. Grande parte desta biodiversidade permanece desconhecida, e a ampliação do conhecimento sobre as espécies biológicas é


��

um desafio essencial para a aplicação de políticas de preservação e exploração sustentável das florestas.

Dados referentes à biodiversidade são de extrema importância porque através deles, pesquisadores podem avaliar questões triviais a respeito das dimensões dos impactos ambientais, proteção de espécies ameaçadas, recuperação de áreas desmatadas, além de apoiar decisões governamentais relevantes como definição de áreas de proteção ambiental, políticas públicas e legislações.

Atualmente, há projetos e programas de pesquisa visam criar sistemas de informação capazes de extrair, armazenar, gerenciar, analisar, integrar e disseminar os diferentes dados das diversas fontes de dados de biodiversidade, tais como, Large-Scale Biosphere-Atmosphere Experiment in Amazonia (LBA) [LBA, 2012] e Global Biodiversity Information Facility (GBIF) [GBIF, 2012].

Dados de biodiversidade apresentam um alto nível de complexidade. Segundo [ALBUQUERQUE et al., 2009] inclui: parâmetros espaço-temporais, estrutura indefinida, multidimensionalidade, vocabulário incógnito expresso por uma linguagem particular e grande volume de dados. Ressalta-se a existência de numerosos modelos e formatos de dados, o que torna a interoperabilidade entre eles, um desafio. No que diz respeito à integração de dados, a maior dificuldade advém da falta de uma conceitualização básica de domínios.

Importantes trabalhos têm sido publicados demostrando bons resultados com o uso de Ontologias para representar modelos de dados da área da Biologia [BODENREIDER, 2006] [LEONELLI, 2008]. De acordo com [ALBUQUERQUE et al., 2009], as bio-ontologias, que são as ontologias ligadas à biologia e ciências da vida, têm auxiliado e contribuído para grandes avanços na área, pois permitem a associação de significado aos dados gerados em experimentos, além de possibilitar a integração das várias fontes de conhecimento, uma nova abordagem para preparação de experimentos ou ainda a busca de respostas usando resultados de fontes distintas.

O atual Ministério da Ciência, Tecnologia e Inovação implantou, em 2004, o Programa de Pesquisa em Biodiversidade (PPBIO), através da Portaria MCT nº 268, de 18/06/2004, que visa desenhar uma estratégia de investimento em ciência, tecnologia e inovação que aponte prioridades, integre competências em diversos campos do conhecimento, gere, integre e dissemine informações sobre biodiversidade. O Programa tem abrangência nacional, com diversas instituições de ensino e pesquisa vinculadas, e iniciou sua implementação nas regiões da Amazônia Oriental, da Amazônia Ocidental e do Semi-Árido, e as referidas regiões possuem núcleos de coordenação das atividades de pesquisa do Programa, representadas pelo do Instituto Nacional de Pesquisas da Amazônia, Museu Paraense Emílio Goeldi e Universidade Estadual de Feira de Santana, respectivamente.

A partir das bases de conhecimentos geradas pelo PPBIO, foi proposto e validado um modelo de Ontologia de domínio visando a integração e consolidação de dados de Biodiversidade [ALBUQUERQUE et al., 2012], que baseia-se em Ontologia de Fundamentação Unificada (UFO) [GUIZZARDI, 2005]. O modelo da ontologia de Biodiversidade está dividida em cinco sub-ontologias, conectadas por relações entre os conceitos e por axiomas, que são: Sub-Ontologia de Coleta; Sub-Ontologia Entidade Material; Sub-Ontologia Localização Espacial; Sub-Ontologia Ecossistema e Sub- Ontologia Ambiente. A referida proposta não é um modelo fechado, e representa um


��

domínio complexo da Biodiversidade de forma expansível e dinâmica. Ressalta-se que há necessidade de expandir e incluir entidades ao modelo de ontologia da Biodiversidade, conforme o surgimento de novos dados e informações sobre espécies biológicas.

Visando expandir a representação do conhecimento sobre a Biodiversidade, este trabalho tem como objetivo propor novas contribuições e implementações a um modelo de ontologia de domínio formalizado, com a inclusão de entidades, relacionamentos e taxonomia referente aos instrumentos para captura e modos de coleta de espécies, utilizando a linguagem de modelagem conceitual OntoUML [GUIZZARDI, 2005].

2. Um Modelo Formal de Ontologia de Domínio para Biodiversidade

Atualmente, há uma ontologia de domínio referente à biodiversidade implementada por pesquisadores vinculados ao PPBIO [ALBUQUERQUE et al., 2012] usando Ontologia de Fundamentação Unificada (UFO), que visa prover uma conceitualização clara e precisa dos aspectos considerados em coletas de dados de biodiversidade independentes de uma aplicação específica, que pode responder questões de competência da ontologia. A competência de uma representação diz respeito à cobertura de questões que essa representação pode responder ou de tarefas que ela pode suportar. Ao se estabelecer a competência, tem-se um meio eficaz de delimitar o que é relevante para a ontologia e o que não é.

A ontologia de Biodiversidade está dividida em cinco subontologias, conectadas por relações entre os conceitos e por axiomas. São elas: (i) Sub-Ontologia de Coleta; (ii) Sub-Ontologia Entidade Material; (iii) Sub-Ontologia Localização Espacial; (iv) Sub- Ontologia Ecossistema; (v) Sub-Ontologia Ambiente, como mostra a figura 1.

Figura 1 – Visão Geral da Ontologia de Domínio da Biodiversidade.

A figura 2 mostra o conjunto de entidades ontológicas com seus respectivos relacionamentos, e está subdivido por cores distintas nos seguintes grupos de subontologia:

Amarelo: Representa informações sobre o Ambiente, sendo que no modelo ontológico dessa entidade está subdivida em outras duas classes que são subclasses da classe Ambiente: Microambiente e Macroambiente, as


��

informações representadas nesse domínio do modelo são: tipo do ambiente, condições climáticas, luminosidade, fases da lua, entre outros;

Verde claro: Representa informações sobre Espaço Geográfico, são todas as informações relacionadas com Tipo de Região, Local de Coleta, Localidade, Ponto Geográfico de onde as espécies foram coletadas;

Verde escuro: Representa informações sobre Ecossistema, são informações relacionadas com Meso, Macro e Micro Ecossistema, além de Tipo do Ecossistema e Bioma;

Azul escuro: Representa informações sobre Materiais, são informações que se dividem em entidade biótica e abiótica, na primeira encontram-se informações de Taxonomia, Animal, Micro-organismo, Sexo, Planta, flora, Vegetação, entre outros. Na segunda (abiótica) encontram-se informações sobre Solo, Água e Ar;

Azul claro: Representa informações sobre Coleta, são informações relacionadas com tipo de coleta, instrumento de coleta, responsável pela coleta, ou seja como a coleta foi feita (manual ou instrumental), qual instrumento utilizado, se foi do tipo armadilha, ou por redes, entre outros.

Figura 1 – Entidades da ontologia de domínio da Biodiversidade.

3. Novas contribuições à Ontologia de Domínio para Biodiversidade

A partir de estudos e pesquisas sobre métodos de coletas de espécies da região Amazônica [UIEDA, 1999] [RIBEIRO, 2006], identificou-se a necessidade de incluir novas subclasses de Coleta, que faltavam no modelo anterior.

Na classe Coleta serão adicionadas 36 novas subclasses correspondentes aos tipos de coleta, como mostra figura 2. Entre as subclasses, envolve Cacuri (é instanciada como subclasse da classe ColetaporArmadilha que é uma generalização da


��

classe ColetaInstrumentada), que são currais de varas de madeira construídos às margens dos rios na região amazônica para captura de peixes.

A partir das novas entidades, é possível adicionar novas Questões de Competência para testar a consistência e taxonomia da ontologia da Biodiversidade. A seguir é mostrado um exemplo questão de competência que é abordada pelo referido modelo de ontologia.

Questões de Competência – Regras SWRL.

Qual Instrumento de Coleta Utilizado na Coleta por Armadilha?

Coleta (?col) ^ ColetaporArmadilha(?colarm) ^ mediationColetaInstrumentadaColetaporArmadilha(?col, ?colarm) ^ InstrumentoArmadilha(?instarm) ^ isInstaceOfnInstrumentoArmadilhaColetaArmadilha(?colarm, ?instarm) → sqwrl:select(?col, ?colarm, ?instarm) ^ sqwrl:orderBy(?col)

Para alcançar o resultado desta questão a regra criada utilizou as entidades Coleta e ColetaPorArmadilha em formas de conjunção seguida de uma propriedade chamada mediationColetaInstrumentadaColetaporArmadilha que delimita um domain e um range onde a busca será feita seguida de uma conjunção com uma outra entidade que é a InstrumentoArmadilha para que a propriedade usada a seguir isInstaceOfnInstrumentoArmadilhaColetaArmadilha fosse aplicada e assim determinando que todo instrumento armadilha é um instrumento usado em coleta por armadilha. Com o sqwrl pode-se trazer os resultados desejados a partir de uma query e ordenar a visualização dos dados através da entidade Coleta.

Figura 2 - Novas entidades adicionadas à classe Coleta. 4. Conclusão

O conhecimento sobre a Biodiversidade é uma necessidade indispensável para aplicações de políticas e programas de preservação e de exploração sustentável, e a utilização de sistemas de informações tem se tornado uma importante ferramenta aliada nesse processo. Diante dos bons resultados com o uso de Ontologias para representar dados complexos biológicos, um modelo de ontologia de Domínio foi proposto e


��

validado a partir de dados da Biodiversidade do PPBIO. Este trabalho demostrou que o referido modelo é aberto, expandindo-o com novas contribuições de entidades de dados, de acordo com o levantamento das características do domínio da Biodiversidade.

As novas contribuições resultaram em um modelo de maior abrangência a respeito da biodiversidade aumentando a capacidade de análise e validação semântica dos termos do domínio.

Como proposta futura, seria importante a implementação de um repositório de ontologias para tratar dos dados complexos de Biodiversidade, e que possa receber cooperações de pesquisadores do PPBIO e demais programas de pesquisas, com novas contribuições em outras classes do domínio, referentes ao espaço geográfico, habitats, hábitos alimentares de espécies, entre outras.

5. Referência LBA. LBA-Ecology Project Science Office”. Disponível por http://www.lbaeco.org/lbaeco/, acessado em 06/2012. GBIF. The Global Biodiversity Information Facility – GBIF. Disponível por http://data.gbif.org, acessado em 06/2012.

BODENREIDER, Olivier; STEVENS, Robert. Bio-ontologies: current trends and future directions. Brief Bioinform (2006) 7(3): 256-274 doi:10.1093/bib/bbl027, 2006. LEONELLI, S. Bio-Ontologies as Tools for Integration in Biology. Biological Theory, 3 (1), pp 8-11, 2008.

ALBUQUERQUE, A.; CAMPOS DOS SANTOS, J.; DE MAGALHÃES NETTO, J. "A Strategy for Biodiversity Knowledge Acquisition Based on Domain Ontology”. To appear in Proceedings of the 9th. International Conference on Intelligent Systems Design and Application (ISDA 2009). November 30th –Pisa, Italy, 2009.

ALBUQUERQUE, Andréa Corrêa Flôres ; SANTOS, José Laurindo Campos dos ; Magalhães Neto, J. F. ; CASTRO JR, A. N. . OntoBio: An Ontology for the Amazonian Biodiversity. In: the International Joint Conference on Knowledge Discovery, Knowledge Engineering and Knowledge Management; 4th International Conference on Knowledge Engineering and Ontology Development, 2012, Barcelona. To be presented, 2012.

GUIZZARDI, G. Ontological Foundations for Structural Conceptual Models. PhD Thesis (CUM LAUDE), University of Twente, The Netherlands. Published as the same name book in Telematica Instituut Fundamental Research Series No. 15, ISBN 90- 75176-81-3 ISSN 1388-1795; No. 015; CTIT PhD-thesis, ISSN 1381-3617; No. 05-74. Holanda, 2005.

UIEDA, V.S. & CASTRO, R.M.C. Coleta e fixação de peixes de riachos. In Ecologia de peixes de riachos: estado atual e perspectivas (E.P. Caramaschi, R. Mazzoni, C.R.S.F. Bizerril, P.R. Peres-Neto, eds). Oecologia Brasiliensis, v. VI, PPGE-UFRJ, Rio de Janeiro, p.1-22, 1999.

RIBEIRO, O. M.; ZUANON, J. Comparação da eficiência de dois métodos de coleta de peixes em igarapés de terra firme da Amazônia Central. Acta Amazônica. vol.36 no.3 Manaus, 2006.


��

Estudo da Aplicabilidade de Grupos de Resposta a Incidentes de Segurança (CSIRT) no Ambiente Computacional do INPA

Cícero Paes Leite1,2, José Laurindo Campos dos Santos1, Rosana Noronha Gemaque1, Ricardo Luís da Costa Rocha1

1 Coordenação de Tecnologia da Informação (CTIn),Laboratório de Interoperabilidade Semântica (LIS), Instituto Nacional de Pesquisas da Amazônia (INPA), Avenida André Araújo, 2936 – Aleixo, CEP.:

69060-001, Manaus-AM, Brasil

2 Fundação Centro de Análise, Pesquisa e Inovação Tecnológica, Faculdade Fucapi, Instituto de Ensino Superior FUCAPI, Av. Gov. Danilo de Mattos Areosa, 381 - Distrito Industrial - CEP: 69075-351,

Manaus-AM, Brasil

ciceropaes, lcampos, rosana.gemaque, rlcr{@inpa.gov.br}

Resumo. Um Computer Security Incident Response Team (CSIRT) se mostra uma importante ferramenta na gestão de incidentes de segurança, por se tratar de um modelo completo, com serviços reativos, proativos e de gerenciamento da qualidade dos processos de segurança da informação. Esta ferramenta pode ser aplicada a diferentes organizações, e representar uma fonte centralizada de obtenção de informações relevantes para a empresa. Este trabalho objetivou um estudo sobre os CSIRTs que aborda as características dos diferentes tipos existentes e seus focos de atuação. Além disso, foi desenvolvido um estudo de caso para observar na prática como a ferramenta CSIRT funciona, sobre suas vantagens e impactos positivo na instituição. Foi proposto um estudo da aplicabilidade no ambiente computacional do Instituto Nacional de Pesquisas da Amazônia (INPA) para a verificação da eficiência do modelo de gestão de incidentes. O estudo é oportuno, pois o INPA está desenvolvendo políticas e estudando formas de gerenciar melhor seus processos de segurança da informação. O resultado do estudo sugere o modelo mais indicado de CSIRT e um processo estruturado de tratamento de incidentes de segurança.

1. Introdução

As atividades de gestão da segurança da informação são elementos importantes na redução de custos e impactos causados por eventuais incidentes de segurança, o alinhamento à legislação sob a qual a organização está inserida, o aumento da confiança de colaboradores e clientes, o melhor conhecimento dos processos internos da organização, bem como, dos sistemas de informação que podem ter as suas fraquezas detectadas e mitigadas, são algumas das vantagens obtidas com este tipo de gestão. Para atingir o seu potencial a segurança da informação trabalha os princípios de confidencialidade: o acesso à informação só é concebido a usuários previamente autorizados; integridade: garante que a informação manipulada preserve todas as suas


��

características originais; e disponibilidade: a informação precisa estar disponível e acessível aos usuários autorizados.

Diferente da realidade de alguns seguimentos empresariais, a cultura de segurança da informação ainda não está bem definida nas instituições de pesquisas científicas, que apesar de terem como objetivos principais a geração, manipulação, catalogação e disseminação de informações, ainda estão no começo do processo de alinhamento às boas práticas segurança da informação (ALEXANDRIA, 2010).

A Lei de Acesso a Informação nº 12.527/2011 propiciou ao INPA o desafio de proteger os seus dados de pesquisa com maior critério, neste sentido, os processos de segurança da informação podem ajudar a gerir com maior eficiência os seus dados trabalhando em prol da segurança dos mesmos. Ficou evidente que o INPA necessita de um modelo de gestão de segurança e uma possível solução é a utilização de times de resposta aos incidentes de segurança (CSIRTs) que tem como ponto central a resolução de incidentes, contudo, a literatura existente permite a utilização deste modelo de gestão em todos os serviços de segurança, trabalhando reativamente, proativamente e gerenciando a qualidade da segurança.

O ponto mais importante para a obtenção de sucesso em ações de segurança é a criação de uma Política de Segurança da Informação (PSI) sólida que deve ser seguida por todos os colaboradores da organização. Segundo LANDWEHR (2001), uma PSI fornece as regras do jogo da segurança da informação. Para DIAS (2000) e BEAL (2005) é um conjunto de regras gerais ou diretrizes que direcionam a segurança da informação e são apoiadas por normas e procedimentos. É uma ferramenta de prevenção, tem seu foco na proteção de dados e processos, nela está contido o padrão de segurança a ser adotado por todos os colaboradores ligados à organização.

2. Porque seguir normas de segurança e as atividades de gestão de incidentes

Ao utilizar os controles aplicáveis de normas de segurança a organização poderá proteger seus ativos de informação, assim como, estará de acordo com as recomendações das agências reguladoras a que se submete (ABNT/ISO 27001; ABNT/ISO 27002). No caso específico do INPA, foi publicada a Instrução Normativa GSI/PR nº 1, de 13 de junho de 2008, que aprovou as orientações para Gestão de Segurança da Informação e Comunicações que deverão ser implementadas pelos órgãos e entidades da Administração Pública Federal, direta e indireta. (DSIC/GSIP, 2012). Um dos controles dispostos nesta norma trata-se da Gestão de Incidentes.

A capacidade de gerenciar incidentes é a habilidade de desenvolver, com qualidade, o tratamento a incidentes e eventos de segurança, envolve a definição de processos a seguir, com políticas de suporte e procedimentos, regras e responsabilidades, sendo importante ter o equipamento apropriado, infraestrutura, ferramentas, materiais de suporte, ter pessoal designado, qualificado e treinado para desenvolver um trabalho consistente, de qualidade e de forma repetitiva (KILLCRECE, 2005).

Um CSIRT, ou Grupo de Resposta a Incidentes de Segurança, é uma organização responsável por receber, analisar e responder a notificações e atividades relacionadas a incidentes de segurança em computadores. Um CSIRT normalmente presta serviços para uma comunidade, que pode ser a organização que o mantém, como


��

uma empresa, um órgão governamental, uma universidade ou uma instituição de pesquisa, que é o caso do INPA (CERT.BR, 2012).

A maioria dos CSIRTS começou apenas como uma metodologia orientada a resposta de incidentes, mas esta metodologia chegou a um nível de maturidade que a permite trabalhar ativamente na proteção de ativos críticos das organizações e na defesa à comunidade da Internet em geral. Este trabalho proativo inclui a influência em políticas, na coordenação de oficinas e compartilhamento de informações. Também inclui a análise de padrões e tendências de intrusão para criar uma melhor compreensão de um ambiente em constante modificação como o da segurança da informação, para que a prevenção, mitigação e estratégias de resposta possam ser desenvolvidas e disseminadas.

3. Modelos CSIRT e sua aplicação no Ambiente do INPA

Para determinar o modelo que melhor atende as necessidades do INPA é necessária a análise dos modelos existentes e suas características. Segundo KILLCRECE (2003), existem 5 modelos organizacionais para CSIRTs,:

1. Equipe de Segurança: apesar de incluído como modelo organizacional, não é

formalmente denominada como CSIRT, é composto por profissionais especializados em segurança ou não, trabalhando apenas em alguns serviços reativos sem seguir nenhum padrão de processos. A literatura admite que este tipo de equipe seja formado com profissionais existentes no setor de TI da organização. Este modelo não atende as necessidades do CSIRT INPA, pois não possui processo de gestão estruturado.

2. Interno distribuído: é formalmente reconhecido como CSIRT, consiste em profissionais especializados, trabalhando geograficamente distribuída na organização, reportando-se a um coordenador. A resposta aos incidentes é realizada de maneira formal e este modelo prevê um repositório central para armazenar informações sobre incidentes de segurança e recuperação. Contudo, o gerenciamento destes funcionários é bastante complicado. O coordenador não terá como verificar se os profissionais estão realizando um trabalho de qualidade e dificilmente conseguirá fazer o CSIRT evoluir, adicionando novos serviços a sua grade. Este não é um modelo aconselhado para o CSIRT INPA.

3. Interno centralizado: é formalmente reconhecido como CSIRT, consiste em profissionais especializados 100% centrado na prestação de serviços de tratamento e resposta de incidentes, fisicamente centralizados, sendo capazes de atuar em conjunto e de forma estruturada, efetuar serviços reativos, proativos e de gestão de qualidade de segurança. O CSIRT funciona como fonte central de análise de informações, determinando tendências e padrões para toda a empresa. Existe a figura de um coordenador que gerencia de perto a produção de seus funcionários e se reporta a um gerente superior da organização, mas também trabalha nas atividades de gestão de incidentes. Este modelo também prevê um repositório central para armazenar informações sobre incidentes, vulnerabilidades e procedimentos de tratamento. Com este modelo, o CSIRT consegue fornecer informações valiosas para o administrador de rede, desenvolvedores de software e de aplicações WEB. Este CSIRT é capaz de construir uma base de conhecimento abrangente a respeito de incidentes,


��

vulnerabilidades, relatórios, análises e estratégias de resposta. Como a equipe está 100% disponibilizada para atividades de CSIRT, a mesma consegue trabalhar proativamente mantendo a qualidade da segurança da informação. Este modelo pode ser aplicado ao INPA.

4. Interno misto (centralizado e distribuído): este modelo combina as características apresentadas no modelo interno centralizado e no modelo distribuído. A equipe central oferece um alto nível de análise e recomenda a recuperação e mitigação para os membros da equipe distribuídos. Este modelo pode ser aplicado ao INPA.

5. CSIRT de coordenação: o foco deste modelo é facilitar o compartilhamento de

informações sobre ataques e vulnerabilidades para entidades externas. O nível de coordenação envolve recomendações para a resposta e recuperação de incidente, servindo como fonte de vigilância, um exemplo de CSIRT de coordenação é o CAIS, que tem a responsabilidade de pesquisar, gerir os incidentes e conscientizar instituições conectadas na RNP. Este modelo não se aplica ao INPA.

4. Metodologia de tratamento a incidentes

O modelo para o tratamento de incidentes de segurança no INPA tem como objetivo formalizar um padrão a ser seguido pelos analistas do CSIRT INPA, este é um dos serviços que será disponibilizado pelo CSIRT INPA. A aplicação deste modelo além de estruturar os processos, garantirá a qualidade dos procedimentos operacionais, uma vez que será mais fácil a localização, correção e adequação dos procedimentos que por ventura apresentarem pontos falhos.

Este modelo é sugerido ao INPA por se basear e estar alinhado aos processos de tratamento de incidentes indicados pelo CERT/CC (instituição referência mundial em gestão de incidentes), como sendo o a melhor maneira de gerir incidentes de segurança da informação. Esta linha de trabalho também concorda com a apresentada em Ceron et al. (2009). A figura 12 ilustra o modelo de tratamento de incidentes de segurança da informação sugerido ao INPA.

A etapa (1) corresponde aos processos iniciais de resposta, através deles a equipe

tem o conhecimento de que um incidente está acontecendo. Existem 3 formas de entrada, por detecção, por notificação de incidentes internos ou por notificação externa de incidentes. A forma de detecção é feita pela equipe de resposta através de ferramentas como IDS (Intrusion Detection System), HIDS (Host Intrusion Detection System), NAGIOS (monitoramento de infraestrutura de TI) e com monitoramento de logs. As outras duas formas de entrada se referem a notificações originadas por usuários da comunidade do INPA ou por entidades externas ao INPA. As notificações externas são recebidas por e-mail, enquanto as notificações internas são realizadas por e-mail, telefone e repassadas pela equipe de Help Desk ou de administração de redes do INPA que recebem os chamados de ocorrências que podem ser possíveis incidentes de segurança da informação através do sistema OCOMON.


��

Figura 1: modelo de tratamento de incidentes CSIRT INPA

Mitigação

Base de conhecimento

(lições aprendidas)

Investigação

Relatórios sobre o incidente

Educação e conscientização

dos usuáriosDetecção

Análise

Fluxo de dados

Fluxo de processos

(1)

(2)

(3)

(4)

(5) (6)

(7)

(8)

Definição da resposta(Direta ou Coordenada

ProcessosPós-resposta

(9)

A etapa (2) é de análise, na qual a equipe do CISRT INPA verifica e constata se realmente se trata de um incidente de segurança. Se for confirmada a existência do incidente, ele é categorizado, priorizado e encaminhado para etapa (3).

Na etapa (3), a equipe do CSIRT tem a tarefa de definir a estratégia de resposta, mas para isso é necessário conhecer o padrão e a causa do incidente. As características do incidente são analisadas, é feita uma consulta na base de conhecimento do CSIRT, etapa (4), onde foram armazenadas e catalogadas soluções para incidentes anteriores.

Se o incidente tiver semelhanças com um incidente previamente tratado ou tiver padrões conhecidos, a equipe diminuirá o tempo de resposta. Neste caso, é definida, a resposta coordenada, na qual a equipe do CSIRT coordenará a resposta remotamente enquanto as equipes de HelpDesk (caso o incidente ocorra em máquinas de usuário) ou administração de rede (caso o incidente seja em algum equipamento de rede ou sistemas) implementam as ações necessárias. Por outro lado, se depois da consulta à base de conhecimento for caracterizada a existência de um incidente novo (que ainda não foi tratado e não consta na base de conhecimento), um membro do CSIRT é designado para tratar o incidente in loco.

Na etapa (5), são implementadas ações de mitigação, isolando o ativo vítima do incidente, minimizando assim as consequências advindas do problema. Esta tarefa pode ser feita com a ajuda de ferramentas da administração da rede e firewalls. Por exemplo, o administrador de rede do INPA pode isolar uma VLAN (virtual lan, uma rede lógica independente) que estiver enviando vírus para outras redes VLANs, através de regras no firewall e tratar o incidente em um perímetro de rede delimitado. As ações de resolução do incidente atualizam a base de conhecimento e são definidas como lições aprendidas.

Após a realização das ações para mitigar o incidente, começa-se a etapa de investigação (6), na qual são documentadas todas as informações relativas ao incidente, seus padrões e características. Essas informações também são enviadas e atualizam a base de conhecimento.


��

Na etapa (7) são realizados os processos de pós-resposta ao incidente. Se a resposta completa do incidente depender de outra área, o incidente é encaminhado para a outra área, se for necessária uma revisão post-mortem do incidente é realizada uma reunião entre todos os membros do CSIRT com a possível participação do gerente da CTIN e outras pessoas chave; se o incidente exigir resposta legal, é realizada uma consulta à equipe jurídica do INPA, se o incidente exigir que outras coordenações sejam notificadas da ocorrência de incidentes em suas áreas (no caso de incidentes internos relacionados com mal uso de ferramentas de trabalho por funcionários) e se a resposta estiver completa todos os envolvidos no incidente são avisados. Todos os procedimentos realizados no processo de pós-resposta atualizam a base de conhecimento.

Na etapa (8), são gerados relatórios de todo o processo de tratamento aos incidentes, informações como data, hora, tipo do ativo alvo, o ativo alvo, características do incidente, tipo de resposta, ações para mitigação, resultado das investigações, e procedimentos pós-resposta. Estes relatórios serão enviados para a gerência da CTIN.

Na etapa (9), é realizada a educação e a conscientização dos usuários, onde serão emitidos alertas para comunidade e serão desenvolvidos conteúdos de conscientização que podem ser disponibilizados na forma de manuais e tutoriais ou em workshops.

5. Lições Aprendidas na implantação de um CSIRT no INPA Através da revisão na literatura sobre as características de cada modelo, pode-se

então afirmar que os únicos modelos capazes de atender às necessidades do INPA, no que diz respeito à gestão da segurança da informação, com a formalização dos processos de serviços reativos, proativos e de gerência da qualidade da segurança são os modelos: Interno Centralizado e o Interno Misto.

Contudo, para a fase inicial, o modelo mais indicado é o do CSIRT interno centralizado, por atender aos serviços iniciais e por caracterizar menor valor para a implantação imediata. Uma vez que necessita de um menor número de funcionários, o valor do investimento inicial é menor e, consequentemente, mais viável para o INPA.

Vale a pena salientar que a estrutura do INPA não se limita apenas a Manaus, sua estrutura inclui representações de núcleos de apoio à pesquisa nos estados de Roraima, Rondônia, Acre, Pará e em breve no Amapá. Sendo assim, as políticas de segurança e os serviços do CSIRT INPA serão disseminados em todos estes núcleos de apoio. Com a implementação deste cenário a visão de futuro do CSIRT INPA passará de Interno Centralizado para Misto, com base central em Manaus e com analistas externos dispostos nos demais núcleos.

6. Considerações Finais

Nesta pesquisa foi possível entender as particularidades de um grupo de respostas a incidentes, e o que esta ferramenta pode trazer de benefícios para os processos de gestão da segurança da informação no INPA. A implantação de um CSIRT mostrou ser de grande valia para o instituto, pela capacidade desta ferramenta não se limitar apenas ao tratamento de incidentes, podendo representar um ponto central e consolidado, sendo referência em segurança da informação para todos os indivíduos utilizadores da infraestrutura de rede do INPA. Por estas razões a criação de grupos de respostas é utilizada e recomendada pelo Gabinete de Segurança Institucional da


��

Presidência da República, em sua Instrução Normativa GSI/PR nº 1, de 13 de junho de 2008. Assim como, na norma complementar nº05/IN01/DSIC/GSIPR de 17 de agosto de 2009.

A avaliação de adequação sugeriu o modelo de CSIRT interno centralizado como o mais indicado para a estrutura física e organizacional do INPA. Esta avaliação pode ser encontrada na integra em LEITE (2012). A perseguição deste resultado foi o agente incentivador para a realização deste estudo. As características obtidas nesta pesquisa poderão servir de auxílio ao INPA em um possível projeto de implantação de CSIRT. Os serviços de um CSIRT deste modelo conseguem abranger as principais atividades da gestão de segurança da informação, com seus serviços reativos, proativos e de gerenciamento da qualidade, trabalhando desde a preparação até o desenvolvimento da sua melhoria contínua.

Foi detectado dentre os serviços de gerenciamento da qualidade de segurança que podem ser disponibilizados pelo CSIRT, as análises de riscos periódicas (em conformidade com a norma 27002), capazes de diagnosticar a situação da segurança no Instituto, recomendando contra medidas para cada vulnerabilidade mapeada, ajudando assim no processo contínuo de redução de riscos sugerido pelo CAIS após a análise realizada de 2010. Outro serviço de gerenciamento da qualidade é o da sensibilização/conscientização da comunidade (controle 8.2.2 da norma 27002) em questões de segurança da informação. Com base nos incidentes tratados, o grupo de respostas pode criar tutoriais de uso, desenvolver treinamentos e workshops. Esta conscientização dos usuários será um agente eficaz para a diminuição de incidentes causados por falta de conhecimento dos usuários em relação a ameaças de segurança da informação. A publicação da política de segurança da informação mostrou-se como o principal pilar para a criação de um CSIRT. Esta afirmativa também é verdadeira para a implementação de qualquer controle de segurança da informação. A não publicação e divulgação de políticas, como protocolos a serem seguidos por todos os utilizadores da rede, impactam diretamente na criação e no funcionamento de um grupo de respostas. As simulações realizadas puderam comprovar que a ausência de políticas de base não permite uma resposta completa, satisfatória e esperada pelo CSIRT. O processo consegue responder até certo ponto, mas não consegue utilizar 100% do seu potencial e com isso pode não corresponder à expectativa gerada pela organização, o que é um risco para a continuidade do CSIRT. Sendo assim, é obrigatória pelo menos a política de segurança da informação para o trabalho de criação de um CSIRT começar a ser executado. Referências ABNT/ISO 27001. ASSOCIAÇÃO BRASILEIRA DE NORMAS TÉCNICAS – ABNT. Tecnologia da informação – Técnicas de segurança – Sistemas de gestão de segurança da informação – Requisitos: NBR ISO/IEC 27001:2006. Rio de Janeiro: ABNT, 2006. ABNT/ISO 27002. Tecnologia da informação - Técnicas de segurança - Código de pratica para a gestão da segurança da informação. NBR ISO/IEC 27002:2005. Rio de Janeiro: ABNT, 2005.


��

ALEXANDRIA, J. C. S. Gestão da Segurança da Informação – Uma proposta para potencializar a efetividade da Segurança da Informação em ambiente de pesquisa científica. 2009. 16 p. Tese (Doutorado em Ciências na Área de Tecnologia Nuclear) – Instituto de Pesquisas Energéticas e Nucleares, Universidade de São Paulo, São Paulo, 2009.

BRASIL. Decreto nº 3.505 de 13 de junho de 2000. Institui a Política de Segurança da Informação nos órgãos e entidades da Administração Pública Federal. Diário Oficial da República Federativa do Brasil, Brasília, nº 114, pag. 2, 14 jun. 2000. Seção 1.

______. Instrução Normativa GSI/PR nº 1, de 13 de junho de 2008. Disciplina a Gestão de Segurança da Informação e Comunicações na Administração Pública Federal, direta e indireta, e dá outras providências. Diário Oficial da República Federativa do Brasil, Brasília, Nº 115, 18 jun. 2008, Seção 1.

BRASIL. Lei nº 12.527, de 18 de novembro de 2011. Regula o acesso a informações previsto no inciso xxxiii do art. 5º, no inciso ii do § 3º do art. 37 e no § 2º do art. 216 da constituição federal; altera a lei nº 8.112, de 11 de dezembro de 1990; revoga a lei nº 11.111, de 5 de maio de 2005, e dispositivos da lei nº 8.159, de 8 de janeiro de 1991; e dá outras providências. Diário Oficial da República Federativa do Brasil. Brasília, nº 16 Maio 2012

CENTRO DE ATENDIMENTO A INCIDENTES DE SEGURANÇA – CAIS. Rede Nacional de Ensino e Pesquisa. Disponível em: < http://www.rnp.br/cais/ >. Acesso em: 20 mai. 2012

______. Relatório RNP.PPBio.INPA – Relatório de Análise. Manaus: INPA 06 jun. 2010.

CENTRO DE ESTUDOS, RESPOSTA E TRATAMENTO DE INCIDENTES DE SEGURANÇA NO BRASIL – CERT.BR. Centro mantido pelo NIC.br, do Comitê Gestor da Internet no Brasil. Disponível em: < http://www.cert.br/ >. Acesso em: 15 mai. 2012.

CERON, J. et al. O processo de tratamento de incidentes de segurança da UFRGS. TRI - Time de Resposta a Incidentes de Segurança da Universidade Federal do Rio Grande do Sul. Disponível em: < http://www.ufrgs.br/tri/publicacoes >. Acesso em: 12 out. 2012

DIAS, Cláudia. Segurança e Auditoria da Tecnologia da Informação. Rio de Janeiro: Axcel Books do Brasil, 2000.

Departamento de Segurança da Informação e Comunicações - Gabinete de Segurança Institucional da Presidência da República – DSIC/GSIP 2012 -, Disponível em: < http://dsic.planalto.gov.br. > Acesso em: 20 out. 2012.


��

Instituto Nacional de Pesquisas da Amazônia. INPA. Disponível em: < http://www.inpa.gov.br >. Acesso em: 10 mai. 2012.

KILLCRECE, Georgia. Incident Management. Build Security in. 2005. Disponível em: < https://buildsecurityin.uscert.gov/bsi/articles/best-practices/incident/223-BSI.html >. Acesso em: 15 mai. 2012.

KILLCRECE, Georgia; KOSSAKOWSKI, Klaus-Peter; RUEFLE, Robin & ZAJICEK, Mark. Organizational Models for Computer Security Incident Response Teams (CSIRTs) (CMU/SEI-2003-HB-001,ADA421684). Pittsburgh, PA: Software Engineering Institute, Carnegie Mellon University, 2003.

LANDWEHR, C.E. Computer Security. Tutorial paper, International Journal on Information Security, Vol. 1, n. 1, p. 3-13, Julho, 2001.

LEITE, Cícero. Estudo da aplicabilidade de grupo de resposta a incidentes de segurança (CSIRT) no ambiente computacional do INPA. Manaus: Fucapi, 2012.

Rede Nacional de Ensino e Pesquisa. RNP. Disponível em: < http://www.rnp.br >. Acesso em: 20 mai. 2012.


��

GeraQuest: um sistema para pesquisas de opinião através de dispositivos móveis: uma proposta para melhorar a

acuracidade da coleta e do processamento de dados

1Unidade Acadêmica de Garanhuns – Universidade Federal Rural de Pernambuco

Avenida Bom Pastor s/n – 55.292-270 – Garanhuns – PE – Brasil

{joaoferreirape, sftdom}@gmail.com

Abstract. This paper reports the result of analysis about the conventional method of opinion research, conducted through paper forms, showing the disadvantages related to its development logistics. As general purpose, was sought to create a platform for the development and application of research. In order to structure the work, we will show the following secondary goals: understand the problem, study IHC techniques, choosing development tools and keep interactions of creation and evaluation of prototypes. In the end of this work are expected development a platform with the most user experience, robust, that minimize cost and accelerate all research context. Resumo. Este artigo relata o resultado da análise sobre o método convencional de pesquisa de opinião, realizado por meio de formulários em papel, mostrando as desvantagens em relação a sua logística de desenvolvimento. Como propósito geral buscou-se criar uma plataforma para o desenvolvimento e aplicação de pesquisas. A fim de estruturar o trabalho, mostraremos as seguintes metas secundarias: entender o problema, estudar técnicas de IHC, escolher ferramentas de desenvolvimento e manter iterações de criação e avaliação de protótipos. Ao final deste trabalho espera-se desenvolver uma plataforma com o máximo de experiência de usuário, que seja robusta, minimize custos e acelere todo o contexto de pesquisa.

1. IntroduçãoA pesquisa de opinião é uma excelente forma para as organizações tomarem

conhecimento da opinião de um grupo alvo. Diante disso, é crucial que as informações

coletadas sejam precisas, pois os dados coletados através de uma metodologia incoerente

implicam em resultados equivocados, e também precisam ser tempestivos, pois a

obtenção de dados após a ocorrência de um evento pode trazer prejuízos sérios na tomada

de decisão de uma organização. [Rossi e Slongo, 1998].

No Brasil é muito comum o uso de formulários impressos como meio de coleta

de informação, mesmo que este modus operandi aumente os custos de processamento dos

dados e deixe uma grande margem de erro em seu processo. Raramente se vê o uso de

tecnologias móveis para suportar esta atividade, em grande parte devido ao alto custo dos

programas e/ou dispositivos utilizados [Andrade e Petreca, 2012].

Observando um caso típico, em uma pesquisa eleitoral, normalmente se faz

necessário realizar centenas e, em alguns casos, até milhares de entrevistas. Entretanto


��

esta é uma atividade tipicamente complexa e, caso seja realizada com alguma incorreção,

pode acarretar em resultados equivocados [Boni e Quaresma 2005]. Segundo [Ladner,

Wingenbach e Raven 2005] e [John 2012], a primeira vantagem em se conduzir pesquisas

eletrônicas encontra-se na redução de gastos. Quando a informação é transmitida

digitalmente, órgãos de pesquisa poupam custos com materiais e recursos necessários em

pesquisas tradicionais, como a impressão e tratamento de papéis, grampos, envelopes ou

outros materiais. A segunda vantagem remete-nos aos custos decorrentes do tempo para

execução da atividade, logo, propõe-se para este trabalho: a realização de pesquisas

eletrônicas através de interfaces móveis, visto que oferecem resultados quase que

instantâneos, reduzindo o que seriam meses de espera, em semanas [Johnson e Fawson

2010].

Apresentamos na “Figura 1 – Exemplo de formulário de pesquisa tradicional”, um

formulário em papel voltado à coleta de dados, utilizado por uma empresa que realiza este

tipo de entrevista. Apresenta uma grande quantidade de questões, dispostas em certa

ordem horizontal, que tanto o entrevistador quanto o entrevistado facilmente ficariam

confusos, além da demanda de tempo necessário para a coleta e tabulação de dados e a

consolidação dos resultados.

Figura 1 – Exemplo de formulário de pesquisa tradicional

Neste artigo apresentamos uma plataforma denominada GeraQuest, que se utiliza

de equipamentos portáteis e de baixo custo para coleta e de um ambiente Web para


��

construção dos questionários e monitoramento da pesquisa. Contendo também tabulação

imediatamente persistida, o que implica na obtenção de resultados logo após a realização

de cada entrevista.

Para implementação da presente proposta, estabeleceu-se os seguintes objetivos

específicos: i) identificar e compreender o problema presente no contexto de uso, através

da Análise de Cenários e da Atividade; ii) estudar técnicas e conceitos da área de Interação

Humano-Computador que subsidie as escolhas de interação; iii) propor uma ferramenta

de coleta de dados (pesquisas de opinião), através de dispositivos móveis; iv) avaliar e

validar a solução com base nos conceitos envolvidos no Método de Inspeção Semiótica.

2. GeraQuest: aplicação de coleta de dados para pesquisa de opinião A motivação inicial deste projeto surgiu do interesse em, através do uso de soluções

computacionais, melhorar a forma como tais pesquisas são feitas. Para isso o projeto

oferece suporte a diversas etapas da realização da uma pesquisa. Tal suporte é provido

através de duas plataformas, uma delas web, destinada à criação e monitoramento das

pesquisas; e a outra móvel, desenvolvida para o sistema operacional Android, destinada

a atividade de coleta de dados. Os trabalhos relativos ao projeto de ambas são

apresentados a seguir.

2.1. Estado da Arte O modelo de processo de design baseado em cenários, [Rosson e Carroll 2002] e [Carroll

1995], foi escolhido como base para nossos trabalhos. Nele são utilizados diversos tipos

de cenários como representação básica e fundamental durante todas as atividades

envolvidas na concepção de uma solução de Interação Humano Computador [Barbosa e

Silva 2010], além de seguir um ciclo iterativo de aperfeiçoamento da proposta de design.

Num primeiro momento foi feita uma entrevista informal com um pesquisador

que trabalhava na área e realizava as pesquisas por meio de formulários impressos. Neste

primeiro dialogo foram levantados diversos questionamentos em relação à sua forma de

trabalho, problemas enfrentados e expectativas em relação ao uso de uma ferramenta

eletrônica.

A partir deste primeiro contato foi possível identificar os seguintes fatos: numa

pesquisa de opinião, para uma amostra de mil pessoas, são necessárias dez pessoas para

realizar as entrevistas e seis para tabular os dados; em relação aos questionários, eles

seguem formato similar ao da “Figura 1 – Exemplo de formulário de pesquisa

tradicional”. Os questionários respondidos têm, posteriormente, suas respostas

contabilizadas manualmente e os dados são lançados em planilhas eletrônicas.

Com base nessas informações criamos alguns cenários onde personagens fictícios,

ou personas [Cooper 2007], interagem com cada um dos protótipos que foram criados ao

longo do processo de desenvolvimento, nos auxiliando a focar o projeto nas necessidades

comuns dos usuários. Além disso, visando minimizar a curva de aprendizagem envolvida

no uso do aplicativo móvel, buscamos manter um padrão de layout que não destoasse do

já utilizado nos questionários impressos, porém que aproveitasse as vantagens da

interação por telas sensíveis ao toque.

Seguindo as etapas do modelo de processo de design baseado em cenários, para

cada protótipo foram aplicadas avaliações visando identificar pontos a serem corrigidos


��

ou melhorados. Devido às limitações do escopo do projeto, optamos por utilizar uma

avaliação através de inspeção, mais especificamente a avaliação heurística [Nielsen

1993]. Nesta avaliação tomamos como base um conjunto de diretrizes de usabilidade e

avaliamos a adequação dos protótipos a elas. Como saída para este processo, obtivemos

vários protótipos, os quais apresentaremos na Seção 2.2.2, com uma clara evolução na

qualidade do aplicativo do ponto de vista de usabilidade.

[Nielsen 1993] traz a facilidade de aprendizado (learnability) como um dos

fatores de usabilidade. Este pensamento norteou nossos esforços ao longo deste trabalho,

pois, por melhor que uma proposta do tipo possa ser, se ela não for adotada por seus

usuários os trabalhos perderiam seu propósito.

2.2. Protótipos Nesta fase do processo utilizamos amplamente o método de prototipação em papel

[Snyder 2003], onde avaliamos a usabilidade de um design em IHC. Segundo [Barbosa e

Silva 2010] uso em papel é um modo rápido e barato de identificar problemas de

usabilidade antes mesmo de construir uma solução em IHC executável. E devido ao uso

do processo de design baseado em cenários e da avaliação heurística, durante todo o

desenvolvimento os membros da equipe foram convidados a pensar e agir como usuários

finais.

2.2.1. A Plataforma Web A decisão de construir o módulo para gestão das pesquisas através de uma plataforma

web surgiu do interesse da equipe de prover máxima portabilidade entre computadores e

sistemas operacionais. Além disso, tal escolha dispensa qualquer tipo de envolvimento,

por parte da equipe na instalação, resumindo a atividade de suporte ao treinamento e

atendimento de problemas isolados. Aqui o gestor poderá: i) estruturar e registrar uma

coleta de dados; ii) acompanhar a entrevista em tempo real; iii) analisar os resultados; e

iv) verificar, também, o histórico de pesquisas anteriores.

Para a criação dos questionários serão disponibilizados os tipos de perguntas com

resposta subjetiva e objetiva, e essa ainda pode ser definida como de seleção única ou

múltipla. Para ambos os tipos é possível impor restrições como obrigatoriedade, e para as

objetivas impor um número mínimo e/ou máximo de alternativas marcadas. Tais

restrições são ferramentas úteis para reduzir erros por parte dos entrevistadores e garantir

a consistência dos dados coletados.

Após criar um questionário com todas as especificações necessárias o Gestor deve

disponibilizá-lo para download nos dispositivos de coleta (smartphones ou tablets). À

medida que os entrevistadores forem coletando os dados, estes serão sincronizados com

o servidor da aplicação. Assim será possível acompanhar a pesquisa em tempo real. Na

“Figura 2 – Relação entre os colaboradores da Plataforma GeraQuest” temos uma

representação simplificada da plataforma web, em especial a área denominada

Middleware, que tem a função de criar uma interface de comunicação entre as partes

ativas, o Gestor e o Entrevistador.


��

Figura 2 – Relação entre os colaboradores da Plataforma GeraQuest

Vejamos, na “Figura 3 – Diagrama de elaboração de pesquisa”, o diagrama

correspondente à criação de uma pesquisa genérica. Como próximo passo, foram

construídas duas interfaces para a criação de uma pesquisa, de forma a escolher a versão

de protótipo que mais se adequaria do ponto de vista da usabilidade, “Figura 4 – Protótipo

– Área do Gestor – Criação de questionário”.

Figura 3 – Diagrama de elaboração de pesquisa

Em ambos protótipos, os campos “Título da pesquisa”, “Informações sobre a pesquisa” e “Titulo da pergunta” foram colocados próximos a fim de ajudar o Gestor a

localizá-los mais rapidamente, conforme o princípio da proximidade das leis de Gestalt, onde entidades visuais que estão próximas umas das outras são percebidas como um

grupo ou unidade [Barbosa e Silva 2010].


��

Figura 4 – Protótipo – Área do Gestor – Criação de questionário

Os protótipos da “Figura 4 – Protótipo – Área do Gestor – Criação de

questionário” nos permitiram tomar decisões relevantes acerca do agrupamento e das

caraterísticas de cada componente. A avaliação heurística [Nielsen 1993] nos orientou

acerca da forma dos pontos onde deveríamos ater mais nossa atenção. O principio de

buscar um design minimalista, por exemplo, esteve sempre como meta de projeto.

Destacamos também o agrupamento de elementos relacionados em regiões delimitadas,

outro princípio de Gestalt. E, como resultado, podemos observar na “Figura 5 – Protótipo

da área do Gestor” uma interface que, embora seja simples, deixa suas principais

funcionalidades claramente perceptíveis ao usuário.

A partir deles foi analisado qual teria a melhor dinâmica para inserção de uma

nova questão. No lado esquerdo da “Figura 4 – Protótipo – Área do Gestor – Criação de

questionário”, cada nova pergunta seria adicionada imediatamente embaixo da outra; já

no lado direito da mesma figura a cada nova pergunta abrir-se-ia uma nova tela. Foi

observado que, do ponto de vista do Gestor, a primeira opção apresenta um meio mais

claro e direto de produzir uma pesquisa, tendo em vista que os objetos serão dispostos em

uma única tela, implicando em uma maior visão do que foi produzido. Resultado

mostrado no lado esquerdo da “Figura 5 – Protótipo da área do Gestor”.

Figura 5 – Protótipo da área do Gestor


��

No lado direito da “Figura 5 – Protótipo da área do Gestor” mostramos a Área do

Gestor, onde ele pode acompanhar as pesquisas em andamento ou finalizadas. Para o

exemplo que consta na referida, a pesquisa está em andamento e já foram realizados 89%

do trabalho. Clicando no botão “Ver Questionário” o Gestor terá acesso ao questionário em si, e clicando em “Ver Resultados”, será apresentado o resultado parcial conforme “Figura 6 – Resultados parciais de uma pesquisa”.

Figura 6 – Resultados parciais de uma pesquisa

2.2.2. Plataforma móvel Optamos por construir este aplicativo para o sistema operacional Android, pois

atualmente é o mais difundido entre Smartphones e Tablets, além de seus aparelhos terem,

em geral, um custo inferior ao dos principais concorrentes, em especial os da Apple [IDC

2012], exibido na “Figura 7 - Marketing Share de sistema operacional para Smartphone”. Neles os entrevistadores irão trabalhar com um questionário digital provido por nosso

aplicativo móvel, o qual será compatível com os diversos tamanhos de tela destes

aparelhos.

Figura 7 - Marketing Share de sistema operacional para Smartphone


��

Figura 8 – Diagrama de execução de entrevista

Após a análise das decisões de projeto, foi criado o primeiro protótipo do

aplicativo móvel “Figura 9 – Primeiro protótipo da aplicação móvel”, baseando-se no

diagrama exibido na “Figura 8 – Diagrama de execução de entrevista”. Nele foi criada a

região comum de interação com as questões, a barra superior que é apresentada após

iniciar a pesquisa, seguindo o princípio de Gestalt denominado região comum, onde

objetos dentro de uma região espacial confinada são percebidos como um grupo [Palmer

1992], [Palmer e Rock 1994].

Esta região comum contém três componentes, sendo dois botões para avançar e

retroceder entre questões e um texto de status que referencia a questão corrente com o

quantitativo total.

A limitação a uma pergunta por página, que foi tomada visando simplificar a

estrutura de tarefas [Norman 1988], reduziu a quantidade de planejamento envolvido no

uso do aplicativo.

Figura 9 – Primeiro protótipo da aplicação móvel

Uma nova interação de análise foi realizada e constatou-se que a cor verde, no

texto de status da pergunta corrente na barra superior, dificulta a leitura, diminuindo assim

a capacidade de percepção do usuário.

Neste mesmo sentido a cor preta da barra superior ficou inapropriada por tirar a

atenção do entrevistador. Segundo propostas do design minimalista [Bertoni 2004] e

[Arbex, Fialho e Rados 2011].

Com estes dados foi criado um novo protótipo, “Figura 10 - Terceiro protótipo da

aplicação móvel”.


��

Figura 10 - Terceiro protótipo da aplicação móvel

3. Conclusão Através do presente artigo buscamos apresentar os resultados do trabalho desenvolvido

para atender a necessidade de agilizar a obtenção dos resultados e garantir uma maior

fidelidade dos dados obtidos em pesquisas de opinião.

Neste trabalho identificamos quais as etapas do processo de execução de uma

pesquisa de opinião e onde poderíamos atuar para entregar uma solução computacional

que auxiliasse essa atividade, evitando o uso de papel e apurando os resultados com maior

fidelidade em tempo reduzido.

A presente solução foi projetada através do modelo de processo de design baseado

em cenários, que nos permitiu modelar conceitualmente as necessidades do usuário e, a

partir disso, construir um aplicativo que as subsidiassem.

Para as ferramentas de desenvolvimento e execução do aplicativo, a equipe de

projeto decidiu adotar a plataforma Android e a linguagem de programação JAVA,

conforme explicitadas anteriormente. E paralelamente as atividades de projeto e

codificação, mantivemos as atividades de prototipação por apresentar baixo custo e

possibilitar um melhor entendimento por parte da equipe de desenvolvimento, a cada

iteração, dos objetivos do cliente.

O resultado, como mostrado na Seção 2.2.2, foi um aplicativo simples, funcional

e que tem todo potencial para cumprir seu objetivo.

O projeto continua ativo e, seguindo as linhas de trabalho definidas, com previsão

de em alguns meses apresentar ao mercado uma nova plataforma de suporte a pesquisas

de opinião. Como sugestão de trabalhos futuros, estender a ideia deste aplicativo para

outros sistemas operacionais de dispositivos móveis; realizar, também, a implementação

de técnicas de Inteligência Artificial e Simulação Computacional, para estabelecer

cenários prováveis, cálculo de desvio-padrão, estimativas de alcance, aplicação de teorias

e métricas de análise de dados.

4. Referências Barbosa, Simone Diniz Junqueira. Silva, Bruno Santana da. (2010) “Interação Humano-

Computador”, Elsevier. Rio de Janeiro, Brasil.


��

Carroll, John M. (1995) “Scenario-Based Design: Envisioning Work and Technology in

System Development”, Wiley, 1st Edition. New York, New York, United States of

America.

Cooper, Alan. Reimann, Robert, Cronin, David. (2007) “About Face 3: The Essentials

Interaction Design”, Wiley, 3rd

Edition. Indianapolis, Indiana, United States of

America.

Dempsey, Chang. Laurence, Dooley. Juhani, E Tuovinen. (2002) “Gestalt Theory in Visual Screen Design – A New Look at an Old Subject”, In: Proceedings of the Seventh world conference on computers in education conference on Computers in

education: Australian topics, Volume 8, pages 5-12. Clayton, Victoria, Australia.

Nielsen, Jakob. (1993) “Usability Engineering”, Morgan Kaufmann Publishers Inc. San

Francisco, California, United States of America.

Norman, Donald Arthur. (1988) “The psychopathology of everyday things”, Basic Book.

New York, New York, United States.

Palmer, Sephen E. (1992) “Common region: A new principle of perceptual grouping”, In:

Journal Cognitive Psychology, Volume 24, Issue 3, pages 436-447. Elsevier.

University of California, Berkeley, United States of America.

Palmer, Stephen E. Rock, Irvin. (1994) “Rethinking perceptual organization: The role of uniform connectedness”, In: Journal Psychonomic Bulletin & Review, Volume 1,

Issue 1, pages 29-55. Springer-Verlag. University of California, Berkeley, United

States of America.

Rosson, Mary Beth. Carroll, John M. (2002) “Usability Engineering: Scenario-Based

Development of Human-Computer Interaction”, Academic Press, Morgan Kaufmann Publishers Inc., San Francisco, California, United States of America.

Ladner, M Damon. Wingenbach, Gary J. Raven, Matt R. (2005) “Internet and paper based

data collection methods in agricultural education research”, In: Journal of Southern

Agricultural Education Research, pages 40-51. New Albany, Indiana, United States of

America.

Seal, John. (2012) “Using Tablet Computers for Intentional Mobile Research”, In: Journal 2012-13 of Council of American Survey Research Organizations – CASRO.

Disponível em: http://www.casro.org/?page=journal Acesso em: 05/11/2012.

Johnson, Paul. Fawson, Bob. (2010) “Can Routers Safely Increase the Carrying Capacity

of Online Respondents?”, In: Panel Conference at Journal 2010 of Council of

American Survey Research Organizations – CASRO. Disponível em:

http://www.casro.org/?page=journal Acesso em: 05/11/2012.

International Data Corporation IDC. (2012) “Android Marks Fourth Anniversary Since

Launch with 75.0% Market Share in Third Quarter”, According to IDC. Disponível

em: http://www.idc.com/getdoc.jsp?containerId=prUS23771812 Acesso em:

05/11/12.

International Data Corporation IDC. (2012) Android Tablets Gain Momentum in the

Third Quarter, Expectations Remain High for the Holiday Quarter, According to IDC.

Disponível em: http://www.idc.com/getdoc.jsp?containerId=prUS23772412 Acesso

em: 05/11/12.


��

Andrade, Josmar. Petreca, Renata. (2012). “Impacto do instrumento de coleta de dados

nas respostas obtidas”, In: PMKT Ciência - Revista Brasileira de Pesquisas de

Marketing, Opnião e Mídia. ABEP. São Paulo, São Paulo, Brasil. Disponível em:

http://www.abep.org/novo/Content.aspx?ContentID=833 Acesso em: 06/11/2012.

Rossi, Carlos Alberto Vargas. Slongo Luiz Antonio. (1998) “Pesquisa de satisfação de clientes: o estado-da-arte e proposição de um método brasileiro”, In: Revista de Administração Contemporânea, Volume 2. Curitiba, Paraná. Brasil. Disponível em:

http://www.scielo.br/scielo.php?pid=S1415-65551998000100007&script=sci_arttext

Acesso em: 01/11/2012.

Arbex, Dafne F. Fialho, Francisco Antonio Pereira. Rados, Gregório Varvakis. (2011)

“Design thinking how an interative process for innovation of products and services”. In: Anais do VI Congresso Internacional de Pesquisa em Design. Lisboa, Portugal.

Bertoni, Franco. (2004) “Minimalist Design”. Birkhäuser Verlag für Architektur. Basel,

Switzerland.

Boni, Valdete. Quaresma, Sílvia Jurema. (2005) “Aprendendo a entrevistar: como fazer entrevistas em Ciências Sociais”, In: Revista Eletrônica de Pós-Graduandos em

Sociologia Política da UFSC, Volume 2, Número 3, pages 68-80. Florianópolis, Santa

Catarina, Brasil.


��

Índice de Autores !!!Anderson F. Esteves! 81 André Lara Temple de Antonio! 1, 24 Andréa Corrêa Flôres Albuquerque! 118 Bruno Morozini 61 Carlos Antonio de Oliveira 1 Celly de Siqueira Martins 1, 24 Cicero Paes Leite 124 Clodomir S. Souza Junior 118 Delano Campos de Oliveira 118 Demétrio do Nascimento Lopes 14 Fábio A. E. Mendes 118 Gabriel Sampaio La Greca de Paiva 101 Janaína M. P. Nascimento 118 João Ferreira 133 José Laurindo Campos dos Santos 118, 124 Marcelo Batista de Souza 71, 90 Marcio André Andrade Silva 71 Marcos Paulo Alves de Sousa 118 Maykon Diego Silva Ribeiro 109 Paulo Roberto Farah 14, 34 Ricardo Luís da Costa Rocha 124 Ricardo da Silva Barboza 81 Romero G. da Silva 90 Rosana Noronha Gemaque 124 Sérgio Luiz Pereira 61 Sérgio Mendonça 133 Thais Oliveira Almeida 90, 101 Wagner Rodrigo de Morais 14 Wanderlan Albuquerque 81 Wender Antonio da Silva 34, 101, 109 Willian Eduardo de Moura Casante 24, 53 Wollace de Souza Picanço 81 !!!!!!!!!!!!!