Introdução ao Desenvolvimento de Jogos para Facebook

Transcrição

Ficha Catalográfica elaborada pela Bibliotecária
Christiane Maria Montenegro Sá Lins CRB/3 - 952
E56a
ENCONTRO UNIFICADO DE COMPUTAÇÃO EM
PARNAÍBA. (5: 2012: Parnaíba, PI).
Anais do V ENUCOMP 2012, Parnaíba, PI, 12 a 14 de
novembro de 2012: [recurso eletrônico]/ Organização [de]
Thiago C. de Sousa e Rodrigo Augusto R. S. Baluz. Parnaíba: FUESPI, 2012.
194 p.: Il.
ISBN: 978-85-61946-80-7
1. Ciência da Computação. 2. Congressos. I. Sousa,
Thiago C. de (org.) II. Baluz, Rodrigo Augusto R. S. (org.)
III. Título.
CDD 001.642
ii
PREFÁCIO
Em 2008, as instituições parnaibanas que atuam no ensino superior, técnico e profissional de
informática sentiram a necessidade de criar um evento de computação maior e mais completo para a
cidade. Assim, surgiu o projeto ENUCOMP (Encontro Unificado de Computação em Parnaíba),
criado numa parceria do CEEP, FAP, IFPI e UESPI, cujas propostas foram pautadas na contribuição
para a troca de experiências, buscando a união dos acadêmicos; no fortalecimento da parceria no
desenvolvimento da educação e da informática; e no incentivo à produção de trabalhos científicos
ligados à tecnologia. Mantendo estes mesmos ideais, o evento vem alcançando um crescimento
consistente ano após ano e ganhando envergadura. Em sua quinta edição, com cerca de 300
participantes vindos de diversos Estados brasileiros, o ENUCOMP já é uma referência regional no
Norte-Nordeste do Brasil na área de computação.
A edição deste ano, que ocorre nos dias 12, 13 e 14 de novembro, inclui cinco palestras, com
temas sobre inovação, acessibilidade, métodos ágeis, computação ubíqua e educação à distância,
bem como seis mini-cursos com assuntos relativos à criação jogos 2D e para Facebook, simulação e
segurança de redes, desenvolvimento web e sistemas embarcados. Além disso, a programação do
ENUCOMP 2012 também fortaleceu a sua vertente científica ao montar um excelente Comitê de
Programa, composto por quase quarenta pesquisadores e professores de renomadas universidades e
empresas de todas as cinco regiões brasileiras, para realizar a arbitragem de artigos por pares. Como
consequência, foram recebidos trabalhos provenientes de 1/3 dos Estados da Federação, sendo
selecionados apenas nove para apresentação no evento, o que significou um taxa de aceitação de
26%, nível dos melhores congressos nacionais da área. Os artigos versam sobre três grandes áreas da
computação: Inteligência Artificial, com trabalhos sobre agentes inteligentes, testes de agentes e
algoritmos genéticos para estimação de sistemas de potência; Sistemas Distribuídos, com temas
relacionados à transmissão de imagens em redes sem fio, sistemas colaborativos para gerenciamento
de download; e Visão Computacional, com assuntos referentes à aplicação de realidade aumentada,
análise de imagens via séries temporais e conversão de dados em RDF. Assim, este volume dos
Anais Eletrônicos do ENUCOMP 2012 é composto por 12 capítulos: 6 relacionados aos mini-cursos
trabalhados durante o encontro, e outros 6 formados pelos artigos científicos selecionados pelo
Comitê de Programa para apresentação mas não premiados.
Por último, gostaríamos de agradecer enormemente aos palestrantes, aos ministrantes de minicursos e aos membros da equipe de apoio e do comitê de programa, por acreditarem em nosso
evento. O trabalho voluntário realizado por vocês de foi fundamental importância para o sucesso do
ENUCOMP. Desejamos que o evento possa trazer frutos para o trabalho de todos.
Até a próxima!
Thiago Carvalho de Sousa
Coordenação Geral
ENUCOMP 2012
iii
COMISSÃO ORGANIZADORA
Coordenação Geral:
Athânio de S. Silveira, Instituto Federal do Piauí (IFPI)
Francisco das Chagas C. do Nascimento, Centro Estadual de Educação Profissional (CEEP)
Rodrigo Augusto R. S. Baluz, Faculdade Piauiense (FAP)
Thiago C. de Sousa, Universidade Estadual do Piauí (UESPI)
Equipe de Apoio:
Antônio S. de Sousa, Instituto Federal do Piauí (IFPI)
Átila R. Lopes, Universidade Estadual do Piauí (UESPI)
Francisco das Chagas Rocha, Universidade Estadual do Piauí (UESPI)
José Flávio G. Barros, Faculdade Piauiense (FAP)
Mayllon V. da Silva, Faculdade Piauiense (FAP)
Nécio de L. Veras, Instituto Federal do Ceará (IFCE)
Régis P. Magalhães, Instituto Federal do Piauí (IFPI)
Comitê de Programa:
André Fujita, Universidade de São Paulo (USP)
Aryldo Russo Júnior, Grupo AeS
Atila Lopes, Universidade Estadual do Piauí (UESPI)
Carlos Giovanni Nunes, Universidade Estadual do Piauí (UESPI)
Celina Takemura, Embrapa
Christian Paz-Trillo, Centro Universitário SENAC-SP
Claudia Melo, Thought Works
David Pereira, Banco Central do Brasil (BCB)
Eduardo Guerra, Universidade Federal do Pará (UFPA)
Eduardo Ueda, Petrobras
Esdras Bispo Júnior, Universidade Federal de Goiás (UFG)
Eyder Rios, Universidade Estadual do Piauí (UESPI)
Fábio Kepler, Universidade Federal do Pampa (UNIPAMPA)
Fábio Siqueira, Programa de Educação Continuada da Escola Politécnica da USP (PECE)
Flávio Coutinho, Universidade de São Paulo (USP)
Harilton Araújo, Centro de Ensino Unificado de Teresina (CEUT)
José Flávio Barros, Faculdade Piauiense (FAP)
Francisco das Chagas Rocha, Universidade Estadual do Piauí (UESPI)
Haniel Barbosa, Universidade Federal do Rio Grande do Norte (UFRN)
Jaclason Machado, Universidade Federal do Piauí (UFPI)
Jesus Mena, Universidade Federal do ABC (UFABC)
José Bringel Filho, Universidade Estadual do Piauí (UESPI)
Karina Valdivia, Universidade de São Paulo (USP)
Márcio Monteiro, IBM do Brasil
Marcos Couto, Oracle do Brasil
Mayllon Silva, Faculdade Piauiense (FAP)
iv
Comitê de Programa (cont.):
Mehran Misaghi, Sociedade Educacional de Santa Catarina (SOCIESC)
Nécio Lima, Instituto Federal do Ceará (IFCE)
Pedro Alcântara Neto, Universidade Federal do Piauí (UFPI)
Raphael Cobé, Instituto Federal do Rio Grande do Norte (IFRN)
Régis Magalhães, Instituto Federal do Piauí (IFPI)
Raimundo Barreto, Universidade Federal do Amazonas (UFAM)
Ricardo Lira, Universidade Estadual do Piauí (UESPI)
Ricardo Sekeff, Centro Internacional de Pesquisas A.C. Camargo
Rodrigo Baluz, Faculdade Piauiense (FAP)
Rodrigo Veras, Universidade Federal do Piauí (UFPI)
Sérgio Barros, Universidade Estadual do Piauí (UESPI)
Thiago Carvalho, Universidade Estadual do Piauí (UESPI)
Vladimir Rocha, Infomobile
v
SUMÁRIO
1. Introdução ao Desenvolvimento de Jogos para Facebook......................... 1
2. Criação de jogos 2D com técnicas 3D utilizando Python/C...................... 13
3. Fundamentos em Segurança e Hardening em Servidores Linux
baseado na Norma ISO 27002..................................................................... 27
4. Desenvolvimento Web com Framework Primefaces................................. 67
5. Introdução à simulação de redes de computadores com o NS-2
(Network Simulator) - Teoria e Prática.......................................................... 78
6. Desenvolvimento de Aplicações para Plataforma Google Android......... 103
7. Desenvolvimento de um Museu Virtual 3D Utilizando Agentes
Inteligentes.................................................................................................. 130
8. Transmission of Images Captured in Real Time through Wireless
Network using the Python Language: A possible way of Wireless
Transmission............................................................................................... 140
9. Project OurDown: Collaborative System for Download Management in
Overlay....................................................................................................... 144
10. SenseRDF: Uma Ferramenta para Conversão de Dados em RDF
seguindo os Princípios Linked Data........................................................... 152
11. Utilização de Realidade Aumentada e Dispositivos Móveis para
Auxiliar na Manutenção de Instrumentos de Medição de Barragens......... 159
12. QoSTVApp:Uma Aplicação Semântica para o SBTVD........................ 165
vi
ANAIS ELETRÔNICOS V ENUCOMP
Introdução ao Desenvolvimento de Jogos para
Facebook
Erick Baptista Passos
Resumo
Nesse capítulo, mostramos um pouco da história dos jogos eletrônicos, conceitos de game
design, e um tutorial inicial sobre a criação de jogos para Facebook usando ferramentas
simples, tais como HTML dinâmico e Javascript.
1.1 - Introdução
Jogos eletrônicos são uma das áreas de trabalho mais interessantes da atualidade. Os motivos são
diversos, desde a atração que as pessoas tem pelo produto desse trabalho, até o fato de ser uma
produção com base em criatividade, competência, sendo uma mistura de arte e ciência.
Nesse capítulo, apresentaremos um breve histórico dos jogos eletrônicos, faremos uma
apresentação sobre game design, o principal conceito por trás de jogos, sejam eles eletrônicos ou
não, e discutiremos sobre algumas ferramentas para o desenvolvimento de jogos simples para a
rede social Facebook. Nas seções principais do texto, serão mostrados todos os passos para a
criação de um jogo web simples para Facebook.
1.2 - Histórico
Os primeiros jogos eletrônicos de que se tem notícia, Tennis for Two e Spacewar, foram
desenvolvidos como um experimento pessoal, e como uma demonstração do poder gráfico de um
novo modelo de computador do MIT, respectivamente. Na Figura 1.1 podemos ver o jogo Tennis
for Two, que consiste de um osciloscópio onde você move a onda de um lado para o outro como
se fosse uma bola de tenis.
1
Figura 1.1 - O jogo Tennis for Two
Comercialmente, a história dos jogos eletrônicos se inicia com o advento das máquinas arcades,
uma evolução das máquinas mecânicas de pinball, adotando botões, circuitos eletrônicos e um
monitor de TV para exibir as imagens. Os arcades obtiveram muito sucesso, e várias empresas
proeminentes surgiram nessa época, entre elas a Atari. A Figura 1.2 mostra o jogo Atari Night
Driver.
Figura 1.2 - Atari Night Driver, um jogo arcade que também fez bastante sucesso nos consoles.
Os consoles surgiram após o sucesso dos arcades, e visavam expandir o mercado para o ambiente
doméstico, no que sucederam. Os principais exemplos dessa primeira geração são o Odissey e o
2
Atari, mostrado na Figura 1.3, je um de seus maiores sucessos, o jogo Space Invaders, também
lançado originalmente como um arcade, mostrado na Figura 1.4.
Figura 1.3 - O Atari VGS 2600, de 1978, o primeiro console de grande sucesso.
Figura 1.4 - O jogo Space Invaders
O aquecimento do mercado de jogos levou a uma expansão muito rápida das empresas de
desenvolvimento, o que gerou uma grave crise de conteúdo entre 1983 e 1984, que culminou
com a falência e dissolvição da Atari original. Muitos jogos de baixa qualidade, e cópias baratas
de produtos de sucesso foram a principal causa dessa crise. Muitos previram o fim dos jogos
eletrônicos, mas o advento dos consoles NES, da Nintendo (Figura 1.5), e Master System da
Sega, em 1985 e 1986 respectivamente, mostraram que o mercado estava apenas no seu início.
3
Figura 1.5 - NES, Nintendo Entertainment System
O lançamento das séries Super Mario (Figura 1.6) e Zelda para NES, mostraram o quanto o uso
de personagens carismáticos pode alavancar as vendas desse tipo de produto. Desde essa segunda
geração, todos os consoles e produtoras buscam a criação de séries e personagens marcantes.
Figura 1.6 - O jogo Super Mario 1, para NES
4
No final dos anos 1980, o mercado de jogos eletrônicos para computador se iniciou através de
empresas de garagem, principalmente na Inglaterra. Em meados da década de 1990, começaram
a surgir jogos com o uso de ponto de vista de primeira pessoa, onde a imagem aparenta ser a
visão do personagem. Exemplos desses jogos são o Wolfenstein 3D, Doom e Duke Nukem.
Entretanto, o advento dos jogos em perspectiva 3D real (três dimensões) só ocorreu realmente
com o lançamento do jogo Quake (Figura 1.7), de 1996. Desde então, muitos jogos de sucesso
usam essa técnica de visualização.
Figura 1.7 - O jogo Quake, desenvolvido em 1996 pela ID Software
1.3 - Game Design
Antes de se começar a desenvolver um jogo, é importante se trabalhar os conceitos que irão
compor essa experiência de entretenimento. Esse é o assunto abordado numa área do
conhecimento milenar chamada de game design, ou projeto de jogos. Game design trata de como
se projetam as mecânicas de jogos, ou seja, as regras que definem como o jogo funciona, seja
ele eletrônico, de tabuleiro, ou um esporte.
Todos nós jogamos, mesmo que não concientemente, já que jogos basicamente exploram
instintos que estão presentes nos nossos cérebros. Um game designer precisa conhecer um pouco
desses instintos para poder criar experiências interessantes para o jogador.
Os principais instintos que são explorados em game design são os seguintes:
5
● Exploração - o ser humano é curioso por natureza, e em jogos isso pode ser explorado
através da criação de ambientes interessantes, o que faz o jogador ter vontade de
continuar jogando para descobrir as novas áreas, paisagens e personagens. Essa
característica é mais marcante nas mulheres, mas muitos homens também gostam de
exploração;
● Aprendizado - nós somos recompensados quimicamente quando aprendemos algo novo,
quando desenvolvemos uma nova habilidade que antes não tinhamos. Esse instinto é
responsável por grande parte do desenvolvimento técnico da humanidade. Em jogos, é
importante estimular o jogador a aprender novas ações que lhe permitam vencer os
desafios;
● Desafios - vencer desafios em si também é uma atividade recompensadora, especialmente
para os homens, que são normalmente mais competitivos.
Mecânicas de jogo
Mecânicas de jogo são os elementos mais básicos que definem a atividade. Ao se projetar um
jogo, são as primeiras decisões a serem tomadas. Para entender o que são as mecânicas, podemos
fazer um exercício simples: remova tudo o que puder de um jogo que você conhece, como
gráficos, música, estória, personagens. Substitua tudo por elementos visuais simples, como
círculos, caixas, etc. O que sobram são as mecânicas, ou seja, a coordenação entre os controles, o
visual e o tempo (para atingir alvos, pular em plataformas, evitar obstáculos, tudo no momento
exato).
Em alguns jogos, as mecânicas podem envolver áudio, como em jogos musicais de ritmo, mas
mesmo nesses casos, podemos substituir as músicas em questão por batidas ritmadas,
coordeanadas com o visual da tela, onde o jogador deve apertar a tecla de cor correspondente no
momento exato para ganhar os pontos.
Na Figura 1.8 temos uma visão simplificada do que poderia ser o protótipo de um jogo de
plataforma usando apenas elementos visuais simples. Um protótipo desses permite que se testem
as mecânicas rapidamente, antes de se comprometer com o design visual. Se o jogo for divertido
apenas com caixas simples, será também divertido com visual apurado. Entretanto, se o jogo não
for divertido dessa forma, dificilmente será após a adição da arte.
6
Figura 1.8 - Um protótipo de jogo de plataforma usando apenas elementos visuais simples.
Um outro conceito importante de game design é o loop de desafio, que ajuda a se projetar como
se apresentam as regras para o jogador. Todo jogo é uma repetição da seguinte sequência:
apresenta-se um desafio ao jogador; o jogador realiza uma ação; através das regras, se verifica se
o jogador venceu o desafio; caso afirmativo, o jogador é recompensado (usando os instinto
citados anteriormente), caso negativo, o jogador é punido; volta-se ao passo de apresentar um
desafio. A Figura 1.9 mostra um desenho esquemático desse conceito.
Figura 1.8 - O loop de desafio, um conceito de game design.
1.4 - O Jogo Exemplo
7
Agora iremos apresentar o jogo que será usado como exemplo. Será um jogo simples, para um
único jogador, onde o seu desafio é atravessar uma sala até uma porta do lado oposto ao que ele
inicia. Como o jogo é em turnos, a sala é composta por um conjunto de casas (células quadradas)
em um tabuleiro, e o jogador deve usar o mínimo de movimentos possíveis para chegar ao
destino final.
O problema é que a sala está infestada de monstros que o jogador não pode ver. Se o jogador
parar numa casa que possui um monstro, ele perde a partida. Felizmente, ele pode perceber a
presença de um monstro em uma casa adjacente, quando isso ocorrer. A estratégia então é recuar
e buscar outro caminho, ou então arriscar para tentar não perder movimentos. A Figura 1.9
mostra uma imagem do protótipo desenvolvido em HTML dinâmico.
Figura 1.9 - Protótipo do jogo. A casa verde é a saída, a casa amarela é onde o jogador está, e as
casas pretas mostram onde ele já passou. Ao chegar numa casa próxima a um monstro, um aviso
é emitido.
1.5 - Implementação de Mecânicas
8
O protótipo do jogo foi todo criado em HTML 4 dinâmico, usando a linguagem Javascript, sem
necessidade de uso de tecnologias de servidor, como PhP, Ruby ou Java. Na Figura 1.10
podemos ver o código base HTML que carrega a página do jogo. Observe que apenas fazemos
carga da biblioteca jQuery, para facilitar o trabalho em HTML dinâmico, e dos arquivos
Javascript criados especialmente para o jogo.
Figura 1.10 - Arquivo HTML básico do jogo. O elemento DIV chamado “container” servirá
como tabuleiro, e seu conteúdo será criado dinamicamente com Javascript.
A criação das casas do tabuleiro é feita através da inserção de elementos DIV diretamente no
HTML através de Javascript. Cada uma das 100 casas (tabuleiro 10x10) é representada por uma
DIV de fundo cinza, a qual é associada uma função ligada ao evento clique. A Figura 1.11
mostra o trecho de código Javascript que cria as DIVs para representar as casas do tabuleiro.
Figura 1.11 - Trecho de código Javascript que cria as casas do tabuleiro. Cada casa é uma DIV,
que é posicionada proceduralmente, e tem uma função associada ao evento clique.
A função associada ao evento clique é responsável pela lógica do jogo. Os seguintes passos são
verificados sempre que o jogador clica em uma casa do tabuleiro:
9
●
●
●
●
●
O jogador pode se mover para essa casa? A função só continua em caso afirmativo;
Move o jogador para a nova casa e conta o movimento;
A nova casa contém um monstro? Caso afirmativo, o jogador perde a partida;
A nova casa é o destino final? Caso afirmativo, o jogador vence a partida;
Existe um monstro em casa adjacente? Caso afirmativo, emitir alerta.
Para implementar essa lógica, o tabuleiro é representado por uma matriz 10x10 de números
inteiros, onde o valor zero (0) representa uma casa livre, e o valor um (1) representa a presença
de um monstro. As funções de checagem de derrota e presença de monstro usam essa matriz,
enquanto a função de checagem de movimentação possível apenas verifica se a casa clicada é
adjacente à atual. Na Figura 1.12 podemos ver o código da função que checa a validade do
movimento.
Figura 1.12 - Função que checa se a casa clicada é adjacente àquela ocupada pelo personagem, o
que indica um movimento válido.
O restante do código fonte para as mecânicas está incluído no DVD de anais do evento, num
arquivo chamado “jogo.js”. O arquivo zipado incluído no DVD contém esse e os demais
arquivos que fazem parte do jogo desenvolvido.
1.6 - Integração com o Facebook
Ao se criar um jogo para Facebook, ao contrário do que muitos imaginam, não se está criando
um aplicativo web que irá rodar nos servidores dessa rede social. O que o Facebook permite é a
autenticação, e o acesso remoto (via serviços web) a vários dados do perfil dos jogadores, seu
grafo de amigos, entre outras informações.
Esses serviços remotos podem ser acessados diretamente através de requisições em protocolo
HTTP, mas é mais produtivo se utilizar uma das SDKs disponibilizadas, seja ela oficial, ou
mantida por uma comunidade. Existem SDKs para as linguagens mais populares, tais como PhP,
Objective C (iOS), Android/Java e Javascript, entre outras. Para isso, basta que você registre a
sua aplicação no endereço http://developers.facebook.com/ e baixe uma das SDKs oficiais para
10
iniciar
a
programação.
Para o nosso exemplo, usaremos a SDK oficial Javascript para fazer a integração diretamente do
browser. Iremos apenas fazer a autenticação/autorização do jogador via Facebook, para, em caso
de vitória numa partida do jogo, publicar uma mensagem no mural do jogador. O arquivo
“facebook-utils.js” inclui todo o código de acesso à rede social, e é bastante simples, sendo
baseado no exemplo incial de autenticação da documentação oficial.
A função de inicialização contida no arquivo verifica se o jogador está logado no Facebook, e se
já autorizou o uso do aplicativo. Caso contrário, o código abre uma pequena janela para que o
jogador possa fazer isso. A função mais interessante, mostrada na Figura 1.13, usa a API de
grafos do Facebook para postar a mensagem de vitória no mural do jogador.
Figura 1.13 - Função que publica uma mensagem no mural do usuário logado no Facebook.
1.7 - Conclusão e Outras Idéias
Nesse capítulo, mostramos alguns conceitos básicos sobre o projeto de jogos, e um exemplo
simples, feito como um protótipo em HTML4 dinâmico, de um jogo com elementos de rede
social. A tendência que tem-se observado é o uso cada vez mais acentuado dessas tecnologias
abertas que permitem a criação de jogos para diversos dispositivos diferentes (PC, Android, iOS,
Mac, Linux), especialmente com o novo padrão HTML5.
Nesse exemplo preferimos utilizar HTML4 por ser uma tecnologia que funciona em browsers
antigos, como o IE 8 e inferior. Uma atualização interessante seria desenvolver os gráficos do
jogo para uso da tag CANVAS de HTML5, permitindo um melhor uso de animações e efeitos.
Para tanto, recomenda-se o uso de alguma biblioteca que facilite o trabalho, tal como a CreateJS.
Também é possível se utilizar animações e efeitos interessantes com HTML4. No jogo Cangaço,
da Sertão Games, utilizamos apenas HTML4 com a biblioteca Spritely, com resultados bastante
interessantes.
11
Outro aspecto que recomendamos explorar é uma maior imersão nas características sociais dos
jogos, tal como o uso de desafio multiplayer, ou pelo menos contra um único amigo, como
explorado nos jogos Song Pop, e Cangaço Wargame.
Referências
Cook, Daniel (2012). What are game mechanics? http://www.lostgarden.com/2006/10/what-aregame-mechanics.html. Acessado em 09/11/2012.
CreateJS (2012). A suite of Javascript libraries and tools for building rich, interactive
experiences with HTML5. http://www.createjs.com/#!/CreateJS. Acessado em 09/11/2012.
Facebook Inc. (2012). Facebook Developers Portal. http://developers.facebook.com. Acessado
em 07/11/2012.
Sertão Games (2012). Sítio oficial do Cangaço Wargame. http://cangaco.com. acessado em
09/11/2012.
W3Schools (2012). Introdução ao padrão HTML5.
http://www.w3schools.com/html/html5_intro.asp. Acessado em 09/11/2012.
12
Criação de jogos 2D com técnicas 3D utilizando
Python/C
Leinylson Fontinele Pereira
Abstract
The game in our context is the electronic game, a simulation and interactive visual displays on a
screen. The interaction is such that the player must have some specific goal or how to go out
somewhere, destroy something, solve a problem, etc. The game developer should be aware of all
possible situations that will be experienced by the player, the knowledge and application of
specific techniques to create an immersive environment and free of errors typical of computer
graphics, as well as all processes that involve the creation of a game / animation, for use by
companies in disseminating their products through the adoption of "gamification" or for
personal entertainment.
Resumo
O jogo no nosso contexto é o jogo eletrônico, uma simulação visual e interativa exibida numa
tela. A interação é tal que o jogador deve ter algum objetivo específico como ir ou sair para
algum lugar, destruir algo, resolver um problema, etc. O desenvolvedor de jogos deve estar
ciente de todas as situações possíveis que serão sentidas pelo jogador, o conhecimento e
aplicação de técnicas específicas para criar um ambiente imersivo e livre de erros típicos da
computação gráfica, bem como todos os processos que envolvem a criação de um
jogo/animação, seja para uso de empresas na difusão de seus produtos por meio da adoção de
“gamificação” ou ainda para entretenimento pessoal.
2.1. Do que é feito um jogo?
Um jogo nos dá um controle sobre um personagem ou um objeto virtual, de modo que possamos ter um
controle e uma imersão no ambiente virtual que se aproxime do nosso controle e imersão no ambiente
real só que com regras e motivações diferentes.
13
Figura 2.1 Componentes da criação de um jogo
2.2. O Jogador
O Jogador é um participante do jogo. Um jogador pode ser uma pessoa real ou um jogador controlado
pelo próprio jogo. Neste artigo, estamos nos referindo a um jogador real, onde a interação do jogo com
o jogador é feito com dispositivos de entrada e saída do jogo, geralmente a tela e um controle em que
na maioria das vezes, o jogador controla o personagem central do jogo.
2.3. Personagem
O personagem de um jogo de videogame é personagem fictício para que o jogador controle. Nos
primeiros jogos o personagem era apenas uma figura sem expressão, dotada de alguma característica
especial (andar, pular) e não possuíam uma história ou motivação. O primeiro personagem de
videogame foi o Mario (ver figura 2.2), criado por Shigeru Miyamoto para a Nintendo. Com o tempo, os
personagens de videogame foram incorporados à cultura pop. Com Mário surgiu o conceito de mascote
do jogo. Esse tipo de personagem carismático agrega um grande valor por sua importância publicitária
graças a sua identificação com o público. Muitas ideias vêm dos sonhos, surgem de pequenos conceitos
expandidos em Brainstorm. Grandes ideias poder parecer ridículas no começo.
Figura 2.2 A criação do Mário
14
2.4. Menus
Os menus são interfaces de texto e/ou imagens onde o jogador deve fazer escolhas e ajustes. Antes de o
jogo começar, os menus servem para fazer ajuste de preferenciais do jogo, escolha do tipo de jogo,
desempenho do hardware, etc. Dentro do jogo eles servem para fazer escolhas e ajustes mais
complexos. Nem todo jogo precisa de menus dentro do jogo, mas certamente vai precisar de um menu
antes do jogo começar .
2.5. HUD
Sigla para Head Up Display. É um método de representação visual de informações importantes para o
jogador. São como menus não interativos. Em geral eles exibem informações como munição, life, arma
selecionada, pontuação, dinheiro ou itens. O HUD (ver figura 2.3) é desenhado por último na tela, de
modo que ele fique sempre visível para o jogador. Ele não deve se mover muito ou conter palavras para
que não distraia o jogador e sempre que possível ser iconográfico, ou seja, usando imagens que
representem a informação (ícones).
Figura 2.3 Exemplo de HUD
2.6. Som e Música
Embora não sejam fundamentais no jogo, os sons existem nos jogos desde o primeiro jogo. Os sons
ajudam a caracterizar certas ações, aumentar o nível de imersão do jogador e deixa-lo mais concentrado
no jogo. Os sons podem ser construídos por sonoplastia. Deve-se ter em mente que diferentes sons
provocam diferentes efeitos sobre o sistema sensorial do jogador. Os sons ligados a uma ação ou
personagem não precisam ser os mesmos sons ligados a estes no mundo real. Pose-se usar sons
diversos a fim de obter efeitos cômicos, criar tensões, força ou simplesmente obter sensações
agradáveis.
A música serve para se criar uma base para as imagens e os outros sons. Com a construção da
música certa, pode-se criar ambientes agradáveis, tensos, pode-se deixar o jogador mais nervoso com
uma música mais rápida e pode-se até usar o recurso do silêncio para criar um clima de suspense. É
sempre bom ter algum repertório de músicas no jogo, e ter músicas de duração razoável, caso contrário,
15
as músicas podem ficar chatas e repetitivas. As músicas de jogos também criam uma lembrança especial
do jogo nos jogadores e cria um sensação agradável ao se jogar.
2.6. Física
Um jogo é uma simulação e na maioria das vezes, uma representação do mundo em que vivemos. Essa
representação, seja por limitações de software e hardware ou por escolha estética, não contém todos os
aspectos do mundo real. Porém, um aspecto que quase sempre está presente é o físico.
Esse aspecto se manifesta principalmente na detecção de colisão. Se o objeto A depois que ele
se mover colide em algo então faz alguma coisa. Essa alguma coisa pode variar de jogo para jogo. Pode
ser que o objeto A seja um personagem e o algo seja uma parede. Então o "faz alguma coisa” pode ser
nada, ele bate na parede, portanto não anda, mas pode ser que o personagem tenho batido em algo
que o machuque como o fogo, então o "faz alguma coisa" pode ser tirar vida do jogador. Uma técnica de
colisão bem simples e que vamos usar aqui é verificar se o retângulo que envolve o sprite toca o
retângulo que envolve o outro sprite (ver figura 2.4 e 2.5).
Figura 2.4 Colisão entre retângulos
Figura 2.5 Máquina de Estados Finitos
2.7. Quem participa da criação?
Você que sempre gostou de jogar e decidiu cursar Ciência da Computação para aprender como é
que aqueles games são feitos e logo se viu travando uma batalha para passar em Cálculo,
Álgebra Linear e Geometria Analítica. O desenvolvimento de um moderno e comercialmente
16
viável game, envolve uma ampla variedade de habilidades e uma equipe especializada (ver figura
2.6).
2.7.1. Game Designer
Elabora os elementos do jogo bem como sua mecânica. Os elementos são os personagens e
o cenário, a mecânica são as possibilidades que o jogador tem de interagir com o jogo.
Empresas que elaboram jogos de ponta modernos dividem as responsabilidades do game
designer com outros profissionais relacionados, sendo os principais, o combat designer e o
level designer.
2.7.2. Roteirista
Descreve como é a trama do jogo, o perfil psicológico dos personagens e a interação entre
eles (social e/ou psicológica), a qual não necessariamente corresponde àquela entre o
jogador e os personagens do jogo.
2.7.3. Tester
Trabalha na equipe de Q&A (Quality Assurance - Controle de qualidade). Testa diversos
aspectos do jogo e relata os pontos falhos ou a serem melhorados.
2.7.4. Programador
Elabora a programação do jogo, desenvolvendo códigos para lidar com AI, música,
interação, etc.
2.7.5. Engenheiro de software
Projeta os componentes de software do jogo envolvendo diversos aspectos como a
composição dos objetos, a interface deles, a interrelação existente entre eles, etc.
2.7.6. Programador Web e Programador de redes
Realiza toda a implementação e configuração necessária para a execução do jogo em
navegadores e a disponibilização de interatividade em rede nos jogos multiplayers on-line.
2.7.7. Programador de AI
Responsável por programar os algoritmos de Inteligência Artificial usados no jogo. Dentre
estes algoritmos estão o de planejamento estratégico de grupo num atirador de primeira
pessoa, a montagem da estratégia do time controlado pela CPU num jogo de esportes, o
planejamento de caminho para levar um personagem NPC (personagens não-jogáveis) de
um local ao outro, etc.
2.7.8. Engenheiro de som
Produz os efeitos sonoros e a música tema.
2.7.9. Level designer
17
Faz o projeto da fase em que o jogador se encontra. Determina quais elementos compõem a
fase, verifica a presença de alguma característica distintiva no terreno como aclives,
declives, montanhas, etc.
2.7.10. Combat Designer
Projeta como será o combate entre o jogador e o computador. Quais são os elementos que
devem estar presentes no combate, qual o papel destes elementos (dano, cobertura, etc).
Figura 2.6. Equipe de desenvolvimento de jogos
2.8. Como é feito um jogo de duas dimensões?
De maneira similar ao modo convencional, a criação de jogos de duas dimensões (2D),
utiliza-se da orientação do plano cartesiano (x,y) bastando observar algumas peculiaridades
quanto a orientação do eixo y (ver figura 2.7).
Figura 2.7. Sistema de coordenadas
2.9. O que são engines?
18
Definição: “É a ferramenta que se encarregará por entender como o hardware gráfico, irá
controlar os modelos para serem renderizados, tratará das entradas de dados do jogador,
tratará de todo o processamento de baixo nível e outras coisas que o desenvolvedor de jogos
normalmente não deseja fazer ou não tem tempo para se preocupar” (ver figura 2.8).
Figura 2.8 Estrutura de um Motor de Game (Game Engine)
2.9.1. PyGame
O Pygame é um conjunto de módulos que você importa num código em Python, os quais lhe
disponibilizam uma série de funcionalidades auxiliares para criação de aplicativos
multimídia e games.
Segue abaixo algumas características da engine para programadores da linguagem
python:
 Vários processadores podem ser usados facilmente:
O uso de vários núcleos adiciona um desempenho muito maior ao seu jogo.
 As funções internas são implementadas em C e Assembly:
Código em C costuma ser de 10 a 20 vezes mais rápido que Python. Já
Assembly tem uma performance de mais de 100 vezes maior que Python.
 Portátil:
Aplicativos programados em Pygame podem rodar tanto em plataformas Windows
(ver figura 2.9) quanto em Linux, Solaris, FreeBSD, Mac OS, Android, entre outros. O
código ainda dá suporte a Dreamcast e também pode ser usado em dispositivos móveis.
 Simples:
O Pygame é usado no projeto OLPC (One Laptop Per Child) para ensinar
programação a crianças. Ao mesmo tempo, também é a preferência de programadores
experientes.
19
Figura 2.9 Janela gráfica do PyGame
2.9.2. Allegro
Allegro é uma biblioteca de funções para jogos 2D feita em C. Apesar de ter algumas
funções para jogos 3D ela não é indicada para isso, sendo no lugar dela uma API3d como
OpenGL ou DirectX. De acordo com a Companhia Oxford de Música, Allegro é o italiano
para "rápido, vivo e brilhante". Ele também é um acrônimo recursivo que representa
"Allegro Low Level Game Routines" (Rotinas de jogo de baixo nível Allegro).
Segue abaixo algumas características da engine para programadores da linguagem C:




Biblioteca para construção de jogos e aplicações multimídia em geral;
Free Source e multi-plataforma (DOS, Windows, Linux, Mac (OS X), BeOS e QNX);
Voltada mais especialmente para jogos 2D;
Conhecida pela facilidade de adicionar entrada de dados via teclado, mouse e
joystick;
 Suporta arquivos de configuração e de dados comprimidos (.dat);
 Temporizadores.
2.10. Inicialização das bibliotecas
Esta é a principal função, e deve obrigatoriamente ser chamada para uma aplicação
funcione, a chamada desta função deve ser a primeira a ser feita, antes de qualquer outra
função.
Allegro: #include <allegro.h>
int allegro_init();
PyGame: import sys, os, pygame
from pygame.locals import*
2.11. Paleta de cores
A especificação de uma paleta (ver figura 2.10) de cores, dar-se através dos parametros
R(Red), G(Green), B(Blue) nas seguintes funções:
Allegro: int makecol( int iRed, int iGreen, int iBlue );
20
Passando-se os valores dos tons (que variam de 0 a 255), de vermelho, verde e azul,
esta função retorna o código da cor. Exemplo de uso: makecol (255, 0, 0 );
PyGame: Realizada de forma similar
Figura 2.10 Paleta de cores
2.12. Temporizadores
Interrompe a execução do programa durante um intervalo de tempo igual ao passado
como parâmetro, em milisegundos:
Allegro: void rest(unsigned int uiTime);
PyGame: Clock = pygame.time.Clock()
Clock.tick(int Time)
2.13. Pixel a pixel
Colore um pixel do bitmap, nas coordenadas especificadas no segundo parâmetro e terceiro
parâmetro, na cor passada no quarto parâmetro:
Allegro: void putpixel(BITMAP *bmp, int iX, int iY, int iColor);
Recupera o valor da cor de um pixel do bitmap, nas coordenadas especificadas no segundo
parâmetro e terceiro parâmetro, na cor passada no quarto parâmetro:
Allegro: void getpixel(BITMAP *bmp, int iX, int iY, int iColor);
Preenche um bitmap com a cor especificada, em um espaço fechado, a partir do ponto X e
Y:
Allegro: void floodfill(BITMAP *bmp, int iX, int iY, int iColor);
2.14. Formas primitivas
A primeira função desenha uma linha vertical, a segunda função desenha uma linha
horizontal e a ultima função desenha uma linha entre 2 pontos quaisquer, respectivamente:
21
Allegro: void vline(BITMAP *bmp, int iX, int iY1, int iY2, int iColor);
void hline(BITMAP *bmp, int iX1, int iY, int iX2, int iColor);
void line(BITMAP *bmp, int iX1, int iY1, int iX2, int iY2, int iColor);
A primeira função desenha um retângulo sem preenchimento, com o contorno colorido,
enquanto a segunda função desenha um retângulo com preenchimento:
Allegro: void rect(BITMAP *bmp, int iX1, int iY1, int iX2, int iY2, int iColor);
void rectfill(BITMAP *bmp, int iX1, int iY1, int iX2, int iY2, int iColor);
A primeira função desenha um círculo sem preenchimento, com o contorno colorido,
enquanto a segunda função desenha um círculo com preenchimento:
Allegro: void circle(BITMAP *bmp, int iX, int iY, int iRaio, int iColor);
void circlefill(BITMAP *bmp, int iX, int iY, int iRaio, int iColor);
A primeira função desenha uma elipse sem preenchimento, com o contorno colorido,
enquanto a segunda função desenha uma elipse com preenchimento:
Allegro: void ellipse(BITMAP*bmp, int iX, int iY, int iXRaio, int iYRaio, int iColor);
void ellipsefill(BITMAP *bmp, int iX, int iY, int iXRaio, int iYRaio, int iColor);
2.15. Texto
Função para exibir um texto na tela, o sexto parâmetro deve ser -1 para um fundo
transparente:
Allegro: void textprintf_ex(BITMAP*bmp,FONT font,int X,int Y, int Color,int CorFundo,char Text);
PyGame: Font = pygame.font.Font("font.ttf",128)
2.16. Modo gráfico
Especificado antes de começar a desenhar:
Allegro: int set_gfx_mode (int card, int w, int h, int v_w, int v_h);
 Onde:

O
valor
de
card
é
usualmente
GFX_AUTODETECT,
ou GFX_AUTODETECT_WINDOWED;
GFX_AUTODETECT_FULLSCREEN
 w, h largura e altura, respectivamente;
 v_w, v_h largura e altura virtual (normalmente, 0), respectivamente.
2.17. Desenhando objetos - BITMAPs
Bitmaps são matrizes de pixels, em que cada valor indica uma cor. Tela é um BITMAP
especial chamado screen, BITMAPs adicionais podem ser criados com:
Allegro: BITMAP *bmp = create_bitmap(int width, int height);
2.18. Periféricos de entrada
2.18.1 Teclado
22
Para inicializar as rotinas do teclado:
Allegro: install_keyboard();
 Váriável global int key[ ], permite ver quais teclas estão pressionadas, através de
constantes definidas para identificar cada tecla (ver tabela 2.1).
PyGame: Realizada de forma similar.
Tabela 2.1. Constantes representativas de cada tecla
2.18.2 Mouse
Para inicializar as rotinas do mouse:
Allegro: install_mouse();
PyGame: Realizada de forma similar
2.19. Som digital (WAV) e música (MID)
Antes de se tocar um som digital ou música deve-se carregá-los da seguinte forma:
Allegro: som1 = load_wav(“arquivo.wav”);
musica = load_midi(“arquivo.mid”);
2.20. Algumas técnicas de programação de jogos
2.20.1. Animação
Dar a impressão de que coisas se movem, pode significar mover um pixel ao longo da tela
mas, geralmente, significa uma mudança repetitiva da apresentação de algo para que dê a
ideia de que se move.
23
A técnica mais simples de animação é quando limpamos a tela, desenhamos os
objetos, limpamos a tela novamente, desenhamos os objetos nas novas posições. O Desafio
é como causar a impressão de movimento dos personagens? A solução é utilizarmos sprites,
ou seja, um conjunto de dados que definem determinado objeto ou personagem num jogo
(ver figura 2.11). Para uma pessoa, por exemplo, podemos ter um sprite que contenha as
posições vertical e horizontal dela no mundo, a direção para onde ela está virada e os
bitmaps que podem representá-la durante o jogo.
Figura 2.11 Exemplo de sprite
2.20.2. Double Buffering
O Problema:
Quando vamos fazer animações usando o Allegro, surgem alguns problemas relacionados
aos vários métodos que podem ser utilizados. O método mais simples que podemos imaginar é
aquele em que limpamos a tela, desenhamos os objetos, limpamos a tela novamente, desenhamos
os objetos nas novas posições, e assim por diante. Este método, porém, tem um grave problema:
a tela pisca a cada limpeza.
A Solução:
Dispomos de um bitmap auxiliar (chamado de buffer) que, normalmente, possui o
tamanho da tela (ou o tamanho da região onde ocorre a animação). Desenhamos, neste buffer, os
objetos que devem ser apresentados na tela. Após isso, desenhamos o conteúdo do buffer na tela,
fazendo com que os objetos apareçam. Limpamos, então, o buffer, desenhamos os objetos
novamente em suas novas posições, passamos o conteúdo do buffer para a tela, e assim por
diante.
2.20.3. Scrolling
24
O Problema:
Como dar movimento ao personagem e aos objetos envolvidos?
A Solução:
Movimento de cenário. O scrolling consiste em movimentar o fundo do cenário e,
normalmente, deixar o personagem controlado parado, o que causa uma sensação de movimento.
O scrolling pode ser horizontal, vertical ou em ambas as direções.
2.20.4. Parallax Scrolling
O Problema:
Como causar a sensação de profundidade presente em jogos 3D?
A Solução:
Utilizar vários fundos que se movimentam em velocidades diferentes.
2.20.5. Detecção de Colisão
O Problema:
Como verificar se dois sprites estão sobrepostos, ou seja, se houve uma colisão?
A Solução:
Existe o método que chamamos de força bruta (checar cada ponto de um sprite com cada
ponto de outro sprite) qué é ineficiente, a maior parte dos outros métodos são aproximativos.
Veremos o principal deles, que consiste em dividir os sprites em retângulos, de forma que
possamos verificar se cada retângulo está ou não sobreposto a outro. Fazer com que
o sprite tenha sua movimentação limitada às bordas do nosso jogo não deixa de ser uma forma
de detecção de colisão, bem simples, é verdade. Porém, em jogos 2D, geralmente se deseja
realizar detecção de colisão entre dois ou mais sprites no jogo.
2.20.5.1 Colisão entre Esferas
O Problema:
Contudo, apesar do sistema de detecção de colisões estar utilizando o algoritmo
do bouncing box, depois de alguns testes você perceberá um problema. Se os sprites colidirem
25
diagonalmente, eles irão colidir antes de atingirem um ao outro de verdade. Isso está ocorrendo
justamente por utilizarmos caixas para representar a forma geométrica das esferas, e agora?
A Solução:
Quando queremos testar colisões entre esferas, teremos que verificar se a distância entre
os centros delas são menores que a soma dos seus raios. Em caso positivo, então uma colisão
ocorreu. Essa é a forma mais eficiente de detectar colisões entre duas esferas. Para detectar a
colisão entre duas formas circulares, usamos o teorema de Pitágoras: (r2 = x2 + y2) (ver figura
2.12).
Figura 2.12. Teorema de Pitágoras
Referências
Andrade, Kleber de Oliveira, “Introdução ao Desenvolvimento de Jogos”,
http://pt.scribd.com/doc/79874524/desenvolvimento-de-jogos, Outubro.
McGugan, Will, “Beginning Game Development with Python and Pygame”, 2007.
“Game Level Design”,
http://www.gamasutra.com/view/feature/175950/the_fundamental_pillars_of_a_.php
, Outubro.
“PyGameLib”, http://www.pygame.org/, Outubro.
26
Fundamentos em Segurança e Hardening em
Servidores Linux baseado na Norma ISO 27002
Felipe Santos Barbosa
Abstract
Lack of maturity concept of information security, both as managers from the IT technical staff
about potential problems that may occur due to the lack of correct management of sensitive
information of the company and the impacts that may cause the image of the corporation. Many
administrators with little security experience preparing their servers with a basic installation
and after their applications are already in operation they leave the way it is, the adoption of
hardening techniques in the UNIX solutions come with standard ISO27002 controls. Having as
its main objective to show how to seek compliance of best practices suggested in the standard.
Resumo
Falta amadurecimento do conceito segurança da informação, tanto de gestores como por parte da
equipe técnica de TI sobre possíveis problemas que podem ocorrer pela falta do gerenciamento
correto das informações sigilosas da empresa e os impactos que possam causar a imagem da
corporação. Muitos Administradores sem muita experiência em segurança preparam seus
servidores com uma instalação básica e, depois que suas aplicações já estão em funcionamento
eles deixam da maneira que está, a adoção de técnicas de Hardening em ambientes UNIX
provem soluções de controles com a norma ISO27002. Tendo como seu principal objetivo
mostrar como buscar a conformidade das boas práticas sugeridas na norma.
3.1.Introdução
A segurança da informação possibilita que o negócio da empresa seja realizado e sua
missão alcançada, fazendo com que a informação seja um ativo de grande importância que
necessita ser protegida, independente do formato em que ela se encontra como, por exemplo:
impressa ou escrita em papel, armazenada eletronicamente, apresentada em filmes ou através de
conversas.
Investir em segurança da informação não é apenas uma questão de investimento
tecnológico, mas também de gestão de pessoas, o que faz com que esse aspecto seja um dos mais
difíceis de ser abordado e que merece bastante atenção dos especialistas na tentativa de mitigar
os riscos sofridos pelas empresas, pois são as pessoas que executam e suportam os processos de
uma organização.
A necessidade do uso das informações e os riscos estão presentes em todos os negócios
sendo preciso saber conviver com eles e administrá-los com competência, pois uma
indisponibilidade pode causar danos irreparáveis e as pessoas ainda não possuem consciência ou
27
não é disponibilizada a elas a importância de terem responsabilidade de ajudar a manter a
confidencialidade e a integridade dessa informação.
Uma das estratégias utilizada pela equipe de segurança da informação para ajudar a
atingir os seus objetivos é desenvolver um programa de conscientização com a finalidade de
fazer com que todas as pessoas da organização entendam a necessidade de segurança e passe a se
preocupar com esses aspectos em todas as situações do cotidiano, além de transformar o elo mais
fraco da cadeia em um grande aliado na estratégia da segurança corporativa.
3.2.Ambiente Organizacional
O aumento da competitividade fez com que as empresas buscassem novos modelos de
negócio, com maior rapidez, eficiência e qualidade nos serviços prestados e nos produtos. A
informação passou a ser o ativo mais valioso da organização, exigindo um controle mais rígido e
complexo.
Diante desse novo cenário, a segurança da informação, que antes era de conhecimento
apenas de grandes empresas e profissionais especializados, passou a ser conhecida por um
número maior de pessoas, porém a maioria das organizações toma uma postura reativa em
relação à segurança, tomando decisões após a ocorrência de um incidente ou até mesmo
chegando a ignorá-lo dependendo do seu impacto nos negócios.
Devido às constantes mudanças nas organizações e ambientes de TI é comum o
surgimento de diferentes formas de ameaças e vulnerabilidades, tornando a sua gestão uma tarefa
complexa e bastante abrangente.
Para auxiliar no processo de implementação e manutenção do sistema de gestão de
segurança da informação as empresas utilizam as principais normas série 27000 que são a NBR
ISO/IEC 27001:2006 - Tecnologia da Informação - Técnicas de Segurança - Sistema de Gestão
de Segurança da Informação (SGSI) - requisitos, norma que trata da definição de requisitos para
SGSI, e a NBR ISO/IEC 27002:2005 - Tecnologia da Informação - Técnicas de Segurança Código de Prática para Gestão de Segurança da Informação, que é o código de melhores práticas
para gerência da segurança da informação.
De acordo com Fontes (2000, p.53), há oito dimensões da segurança da informação (SI)
que podem auxiliar em todos os aspectos e facilitar esse processo. São elas:
a) Organizacional: deve abranger as políticas, os termos de compromisso e as auditorias de
acordo com a filosofia e a cultura da empresa;
b) Controle de acesso a informação: envolve a identificação e autenticidade dos usuários nos
sistemas computacionais e como ele deverá ser feito. Também identifica o gestor e o responsável
pelo controle de acesso á informação;
c) Desenvolvimento e a manutenção de sistemas: define os procedimentos, padrões,
metodologias e regras de desenvolvimento, aquisição e manutenção de sistemas;
d) Ambiente físico: envolve o controle de acesso e monitoramento do ambiente, além das
condições técnico/ambientais para os equipamentos de informática funcionem corretamente;
e) Ambiente descentralizado: deve levar em consideração a importância que os micros e redes
locais estão ganhando nas empresas;
28
f) Continuidade do negócio: planejamento de ações que permitem a continuidade do negócio,
recuperação ou contingência caso algum desastre ocorra. Deve levar em consideração todos os
riscos e ameaças que envolvem o negócio da empresa;
g) Telemática: garante a comunicação da empresa com o mundo exterior. Deve ser monitorada e
garantir a proteção das informações internas, assim como a confidencialidade nas comunicações
entre cliente/empresa;
h) Recursos Humanos: Fator de grande importância na implementação da SI. Abrange a
campanha de conscientização dos usuários e as medidas que deverão ser tomadas para que isso
ocorra.
A NBR ISO/IEC 27002-2005 cita a conscientização dos usuários como um processo,
porém não há um detalhamento ou procedimento de como isso deve ocorrer, permitindo que os
gestores desenvolvam planos estratégicos de como isso deve ser feito, levando-se em
consideração a realidade e a cultura da organização e lembrando que é uma estratégia à ser
realizada de maneira abrangente, contínua e testada.
Na descrição de acordo com a ABNT NBR ISO/IEC 27001-2006: A organização deve
assegurar que todo pessoal que tem responsabilidades atribuídas definidas no SGSI seja
competente para desempenhar as tarefas requeridas:
a) determinando as competências necessárias para o pessoal que executa trabalhos que afetam o
SGSI;
b) fornecendo treinamento ou executando outras ações (por exemplo, contratar pessoal
competente) para satisfazer essas necessidades;
c) avaliando a eficácia das ações executadas; e mantendo registros de educação, treinamento,
habilidades, experiências e qualificações.
A organização deve também assegurar que todo o pessoal pertinente esteja consciente da
relevância e importância das suas atividades da informação e como eles contribuem para o
alcance dos objetivos do SGSI (FONTES, 2006).
Diante dos dados de pesquisa da Módulo Security na sua 10ª Pesquisa Nacional de
Segurança da Informação (2010), a estrutura da área de segurança da informação na maioria das
empresas envolve profissionais que desempenham outras funções na área de TI, como Gerentes
de TI/Redes. Somente em um pequeno número de empresas (13%) existe um cargo de
CSO/Diretor de segurança (Figura 3.1).
29
Figura 3.1 Percentuais de Profissionais que desempenham funções na área de TI nas
empresas
Fonte: Módulo Security Solutions 10ª Pesquisa Nacional de Segurança da Informação (2006,
p.8)
Segundo a Módulo Security (2006), apenas 25% das empresas preferem não terceirizar a
área de Segurança da Informação, enquanto que aquelas que terceirizam dão a preferência aos
serviços de administração e suporte a firewall e IDS (16%), help desks (13%) e análise de riscos
(9%).
3.3.Segurança da Informação
3.3.1. Uma Visão Geral
O conteúdo publicado nas redes sociais nem sempre são relevantes aos negócios da
organização e muitas vezes podem reduzir a produtividade dos profissionais. A disponibilização
de informações e a sensação de conforto, gerados pela liberação da utilização dessas ferramentas,
pode favorecer o trabalho de pessoas maliciosas que utilizam de estratégias como a de
Engenharia Social para obter informações sigilosas.
De acordo com Frank Wazmer, ChiefInformation Officer (CIO) da rede hospitalar norteamericana Health First, explica que a ameaça à imagem das companhias é latente quando seus
funcionários fazem parte de redes sociais. “Esses sites tornam-se plataforma para que eles
possam fazer reclamações, comentários impertinentes ou até divulgar dados confidencias de
forma maciça”, Tendo como única solução a conscientização dos usuários e a definição das
regras que devem ser aceitas por todos que fazem parte da empresa. “É o único caminho
eficiente que conheço, já que nenhuma ferramenta até agora consegue deter os criminosos
virtuais”, conclui (COMPUTERWORLD, 2010, p.55).
Dawel (2005, p.26) acredita que há no mínimo três explicações para que isso ocorra:
desconhecimento do perigo que pode estar dentro da empresa, negligência em tratar as ameaças
30
internas e a imperícia em lidar com assuntos relativos à segurança e tratá-las de forma amadora,
achando que está sendo profissional.
Em uma pesquisa realizada pela empresa Módulo Security com Guelman (2006) foi
publicado que uma das principais constatações de um estudo realizado pelo "CSI/FBI Computer
Crime and Security Survey" que a segurança da informação é muito mais uma questão gerencial
do que tecnológica, pois de nada adianta investir em tecnologia e proteção física se não temos a
colaboração e o comprometimento das pessoas.
A 10ª Pesquisa Nacional de Segurança da Informação, realizada em 2006, pelo Módulo
Security Solutions, empresa especializada em segurança da informação, com cerca de 600
profissionais ligados a área de tecnologia e segurança da informação de diversos segmentos de
negócio, revelou que apesar de haver uma maior preocupação com investimentos em SI para
ajudarem as empresas a estarem mais bem preparadas pra enfrentar algumas falhas de segurança,
ainda é grande o número de empresas (33%) que não sabem quantificar as perdas ou sequer
identificar os responsáveis pelo problema (21%). Porém a maioria das corporações (55%)
considera como principal obstáculo para a implementação da segurança da informação a falta de
conscientização dos executivos e usuários (Figura 3.2).
Figura 3.2 Principais obstáculos para a implementação da Segurança da Informação
Fonte: Módulo Security Solutions 10ª Pesquisa Nacional de Segurança da Informação
(2006, p.7)
Para ajudar a melhorar esse cenário é fundamental que a alta gerência tenha claro que a
conscientização de seus funcionários é um fator crítico de sucesso no plano de segurança da
informação. Para isso é necessário que seja realizada uma avaliação do nível de conhecimento
que a direção da empresa possui sobre o assunto e que seja feito um nivelamento de informações
utilizando as recomendações das normas, as melhores práticas e cases de sucesso, tendo como
apoio, caso se faça necessário, uma consultoria especializada no assunto.
31
O aumento do nível de conscientização dos altos executivos e o crescente número de
ataques, invasões e vazamento de informações enfrentadas pela empresa, têm incentivado a
capacidade dos funcionários que trabalham na área de Segurança da Informação, conforme
demonstrado na (Figura 3.3).
Figura 3.3. Nível de capacitação dos profissionais que lidam com a Segurança da Informação na
corporação
(2006, p.14)
3.3.2. Generalidades e Conceitos
A preocupação com a segurança da informação e com os conhecimentos que ela
proporciona vem desde o inicio da existência do ser humano, antes mesmo da invenção e uso dos
computadores. As civilizações antigas desenvolveram métodos de segurança da informação,
como a cifra, onde cada letra do alfabeto era modificada e somente a pessoa que possuía a chave
para decifrar o manuscrito conseguia ler a informação corrente. Esse método de cifra foi
utilizado por muito tempo, inclusive na Segunda Guerra mundial para proteger informações
estratégicas de guerra dos exércitos.
Com o avanço tecnológico, o aumento do uso e das facilidades que o computador
proporciona, fez-se necessário o surgimento da segurança da informação e, ao longo do tempo, o
desenvolvimento de normas e padrões que servem como guias de melhores práticas e auxiliam
na sua estruturação.
Para que a segurança da informação tenha sucesso na sua implementação é necessário
que ela envolva todas as áreas da empresa, ativos e pessoas e a atividade de conscientização do
uso das políticas de segurança da informação e seja uma cultura da organização (FONTES,
2000).
3.3.3. Objetivos
A segurança da informação tem como objetivo a proteção das informações através de um
conjunto de orientações, normas, procedimentos, políticas e demais ações para garantir a sua
32
preservação contra possíveis danos, perdas, furtos e mau uso, afetando a continuidade do negócio
e alcance de seus objetivos.
De acordo com a norma ABNT NBR ISO/IEC 27002:2005 a informação é um ativo e
como outro qualquer ativo importante, é essencial para os negócios de uma organização e,
consequentemente, necessita ser adequadamente protegida. Isto é especialmente importante no
ambiente dos negócios, cada vez mais interconectado. Como um resultado desde o incrível
aumento da interconectividade, a informação está agora exposta a um crescente número e a uma
grande variedade de ameaças e vulnerabilidades (ABNT, 2005).
Um ativo é qualquer coisa que tenha valor para empresa, como serviços, equipamentos,
pessoas, conhecimentos, sua imagem e reputação.
Segundo a NBR ISO/IEC 27002-2005 (ABNT, 2005) para que a informação possa estar
protegida é necessário que ela possua os três princípios básicos da segurança, que são:
Confidencialidade, Integridade e Disponibilidade.
Confidencialidade: somente indivíduos autorizados possuem acesso a esse ativo,
impedindo que a informação acabe sendo acessada por pessoas erradas ou divulgada sem
autorização prévia. Exemplo: Acesso á folha de pagamento do RH por um funcionário não
autorizado.
Integridade: o ativo ou a informação devem estar em seu formato original preservando a
sua exatidão e completeza, ou seja, a informação não pode ter sofrido alteração.
Disponibilidade: o ativo deve estar disponível e acessível para o individuo autorizado
sempre que necessário.
Além desses princípios básicos, a proteção também pode ser obtida através da
auditabilidade (registro do acesso e uso da informação para posteriores consultas e
averiguações), da legibilidade (de acordo com as leis aplicáveis, regulamentos, licenças e
contratos para o negócio), do não repúdio (garantia de que o usuário da informação não possa
negar as suas responsabilidades pelo seu uso) (TI EXAMES ISO/27002 FOUNDATION, 2011).
Para que sejam elaboradas as normas e diretrizes, como políticas de segurança da
informação, de acordo com o tipo de negócio da empresa e o seu porte, tendo que haver um total
comprometimento de toda a organização com nesse processo, desde a alta direção até os
estagiários, prestadores de serviço e/ou partes envolvidas.
3.3.4. Políticas de Segurança da Informação
A política de segurança da informação (PSI), de acordo com Fontes é um documento que
deve ser elaborado pela equipe técnica, geralmente a equipe de segurança da informação,
juntamente com a alta direção visando estabelecer regras, normas e diretrizes de acordo com
cada empresa. Ela deve garantir que todas as áreas e recursos da empresa sejam abrangidos e ser
coerente com a sua visão, missão e objetivos, além de ser elaborado em uma linguagem de fácil
entendimento por todos, evitando utilização de termos técnicos e aspectos de implementação
(FONTES, 2000).
Todas as pessoas que fazem parte da empresa devem conhecer e seguir as políticas de
segurança, independentemente do seu nível hierárquico ou do seu grau de participação, inclusive
33
os prestadores de serviço e stakeholders (FONTES, 2000).Segundo Fontes (2000, p.38) a PSI
deve conter os seguintes tópicos:
a) a informação como um bem da empresa;
b) controle do acesso a informação;
c) definição do gestor da informação;
d) responsabilidades do usuário, da gerência e do gestor da informação;
e) preparação para situações de contingência, garantindo a continuidade da execução do negócio;
f) definição do uso profissional da informação da empresa;
g) definição da possibilidade, ou não, da empresa acessar arquivos pessoais do usuário, quando
de investigações criminais;
h) definição da identificação do usuário como pessoal e única, bem como a responsabilidade do
sigilo da senha;
i) conscientização dos usuários;
j) medidas disciplinares que serão utilizadas caso a política não seja cumprida.
A implantação da PSI tende a ser longa e deve ser realizada de maneira formal e
adaptável para que possa se adequar à realidade da empresa. Sua manutenção deve ser constante
e seus tópicos revisados e atualizados de acordo com as suas necessidades e importância
(FONTES, 2000).
3.3.5. Vulnerabilidades
A vulnerabilidade pode ser considerada uma falha no sistema computacional que cria
deficiências na segurança e que pode ser ocasionadas por configurações incorretas do
computador ou de segurança (FONTES, 2000).
Segundo Sêmola (2002) e Moreira (2001) respectivamente, a fragilidade presente ou associada a
ativos que manipulam e/ou processam informações que, ao ser explorada por ameaças, permitem
a ocorrência de um incidente de segurança, afetando negativamente um ou mais princípios da
segurança da informação: Confidencialidade, Integridade e Disponibilidade.
A vulnerabilidade é o ponto onde qualquer sistema é suscetível a um ataque, ou seja, é
uma condição encontrada em determinados recursos, processos, configurações, etc. Condição
causada muitas vezes pela ausência ou ineficiência das medidas de proteção utilizadas com o
intuito de salvaguardar os bens da empresa (SÊMOLA, 2002).
As vulnerabilidades podem ser encontradas em praticamente todos os ambientes,
podendo ser de vários tipos, como: físicas, naturais, hardware, software, mídias, comunicação e
humana. A identificação dessas vulnerabilidades e a implantação de medidas de segurança
diminuem o grau de ameaça e aumenta a possibilidade da continuidade do negócio (MOREIRA,
2001).
Em relação a segurança da informação, a vulnerabilidade humana é um dos pontos mais
frágeis e ela pode ser causada devido a negligência ou não conhecimento das políticas de
segurança, falta de treinamento, sabotagens, compartilhamento de informações confidenciais
34
como senhas e envio de e-mails a pessoa não autorizada, destruição ou roubo de propriedade ou
dados, entre outros. (SÊMOLA, 2002).
3.6. Ameaças
Para Araújo (2005), as ameaças são muitas das vezes consequências das vulnerabilidades
existentes, provocando assim perdas de confidencialidade, integridade e disponibilidade.
A perda da confidencialidade ocorre quando há a quebra do sigilo de alguma forma,
como o vazamento de informações e a descoberta da senha de um usuário. Quando a informação
é acessada por pessoas não autorizadas e há alterações dessas informações ocorre a perda da
integridade. Já a perda de disponibilidade é quando, por exemplo, a informação não está
acessível a quem precisa dela, ou por motivos acidentais, fatores internos ou externos, má
intenção ou ainda falha nos equipamentos (ARAUJO, 2005).As ameaças podem ser naturais,
quando são causadas devido a fenômenos da natureza e não naturais quando são causadas pelo
ser humano.
O erro humano é a causa mais comum para a perda de dados, que pode ocorrer de forma
acidentalmente por apagar ou sobrescrever um arquivo existente na rede. Usuários
frequentemente utilizam seus computadores com configurações pré-configuradas sem entender o
que elas significam o que pode causar sérios danos. Muitos problemas originados nos
computadores das empresas são causados por atividades executadas por seus próprios
funcionários.
Kevin Mitnick, um dos maiores cyber criminosos dos EUA, que atualmente trabalha em
prol da segurança da informação considera as pessoas como o elo mais fraco da segurança,
devido à falsa sensação de segurança ocasionada pelo desenvolvimento e utilização de melhores
tecnologias de segurança, tornando mais difícil a exploração de vulnerabilidades técnicas. Para
Mitnick (2006), a quebra do "firewall humano" quase sempre é fácil, não exige nenhum
investimento além do custo de uma ligação telefônica e envolve um risco mínimo.
As empresas estão se preocupando cada vez mais com a proteção da informação, pois
estão convencidas de que ela é um ativo de grande importância e valor. Um dos pontos
relevantes para que a proteção dessa informação ocorra é a conscientização dos seus funcionários
quanto à utilização desse ativo.
De acordo com Fontes (2006) conscientização é mais do que um simples conhecimento:
estar conscientizado em proteção da informação é internalizar os conceitos e agir com
naturalidade no cumprimento dos regulamentos. Significa que a segurança da informação deve
fazer parte do dia-a-dia e não ser considerada um peso em nossas responsabilidades profissionais
para a organização. Significa também que os executivos da organização devem avaliar e testar
comprometidos com o nível estabelecido para a proteção.
Fontes (2006, p.32) destaca que vulnerabilidade humana pode ocorrer por diversos tipos
de problemas, como descritos a seguir.
Pouco ou nenhum entendimento sobre segurança: segurança não é um instinto e deve ser
ensinada às pessoas.
35
As ameaças devem ser claramente explicadas: muitas pessoas não acreditam que um problema
realmente exista por nunca terem sofrido ou conhecerem alguém que já tenha sido de algum tipo
de fraude eletrônica.
Questões culturais: o comportamento das pessoas não muda facilmente. O hábito de usar regras
de segurança não deve ser utilizado apenas dentro da organização. As pessoas também devem ter
hábitos fora do ambiente empresarial, fazendo com que a segurança seja uma rotina em seu diaa-dia.
Resistência às medidas de segurança: as pessoas costumam ter a falsa sensação de perda de
liberdade ao se submeterem às políticas de segurança, ou ainda, que são pessoas não confiáveis
perante a organização.
Necessidades: geradas principalmente pela necessidade financeira.
Oportunidades: os funcionários têm o conhecimento de como a organização funciona
diariamente, consequentemente possuem o conhecimento das fragilidades dos controles internos.
Racionalização: a conduta da pessoa a faz acreditar e a tornar a fraude como algo justo.
O fator humano no desenvolvimento e implantação das políticas de segurança da
informação é o ponto mais problemático para a organização, pois é o único aspecto que não pode
ser diretamente controlado, como ocorre com os diversos tipos de sistemas e computadores que
são programados a executar com fortes políticas de segurança.
A organização deve desenvolver um plano de conscientização dos usuários, como o objetivo de
introduzir a preocupação com a SI na cultura organizacional. Deve envolver todos os
funcionários da organização e, caso se faça necessário, fornecedores e terceiros.
O processo de seleção dos profissionais também deve ser realizado de maneira criteriosa,
levando-se em consideração a importância do ativo pelo qual o colaborador será responsável,
além dos seus conhecimentos e da titularidade exigida pela função.
Os riscos considerados ativos podem ser mais bem gerenciados de acordo com as
vulnerabilidades humanas se todas as pessoas reconhecerem o seu papel, suas responsabilidades
e habilidades, fazendo a diferença na prática e contribuindo para a SI.
A empresa deve estabelecer regras que sejam claras e objetivas, medir a adesão às
políticas de segurança da informação periodicamente, ter um criterioso processo de seleção,
prover treinamento, atualizações e reciclagens, fornecer informações de como se defender de
ataques tecnológicos e engenharia social além de possuir um conjunto de tecnologias aplicadas a
SI.
3.4. Motivos de Ameaça à Segurança
No começo dos anos 70 poucos eram as ameaças e danos que poderiam ser causados a
informação pela utilização dos computadores, onde a maioria dos perigos era causada pela
utilização de disquetes contaminados e, posteriormente, de CDs e jogos que carregavam vírus e
cavalos de Tróia.
O aumento do uso de computadores pelas organizações para processar e armazenar informações
importantes e confidenciais sobre o seu negócio, o compartilhamento das informações através da
rede, o desenvolvimento de novos negócios na internet, a sua facilidade de uso, baixo custo,
36
anonimato e, consequentemente, impunidade contribuíram exponencialmente para o crescimento
dos ataques às informações pessoais e, principalmente empresárias.
Conforme publicado na 10ª Pesquisa Nacional de Segurança da informação há uma grande
dificuldade das organizações em conseguir identificar os responsáveis pelas ameaças, fazendo
com que elas se dediquem apenas a corrigir as falhas (48%), quando descoberta, ou tomar
providências internas (25%), acionando por conta própria o causador do problema (MÓDULO
SECURITY SOLUTIONS, 2006).
Os danos causados por vários tipos de ameaça podem gerar perdas significantes para as
organizações. O conhecimento das vulnerabilidades dos sistemas e suas ameaças ajudam a
mitigar os riscos com a implementação de medidas corretivas e custos aceitáveis para a
organização.
Ainda de acordo com a mesma pesquisa, quando as organizações conseguem identificar
os responsáveis é verificado que a maioria das falhas de segurança é causado por funcionários
(24%) e hackers (20%). As ameaças que mais causam danos financeiros são os vírus (15%),
spam (10%) e as fraudes (8%) (Figura 3.4).
Figura 3. 4 Problemas que geraram perdas financeiras
(2006, p.6).
Para Mitnick (2003) não existe um computador 100% seguro, pois um criminoso fará de
tudo para conseguir a informação desejada.Há um ditado popular que diz que um computador
seguro é aquele que está desligado. Isso é inteligente, mas é falso: o criminoso convence alguém
37
a entrar no escritório e ligar aquele computador. Tudo é uma questão de tempo, paciência,
personalidade e persistência. É nesse ponto que entra a arte da fraude (MITNICK, 2003).
O conhecimento das causas e riscos que as ameaças trazem se faz necessário, pois os
usuários repetem seus comportamentos domésticos diários nos ambientes corporativos,
comprometendo igualmente a segurança dos computadores utilizados.
3.4.1. Erros e Omissões
Também chamados de bug's do sistema, os erros e as omissões podem causar ameaças à
integridade dos sistemas devido a problemas que podem ser gerados pela edição das informações
diária, por diversos funcionários e/ou automaticamente pelo próprio sistema, como através de
atualizações ou erros de programação, podendo contribuir direta ou indiretamente com as
brechas de segurança. Alguns desses tipos de erros podem causar perdas irreparáveis ou criar
vulnerabilidades e podem ocorrer durante todo o ciclo de vida do sistema. Uma pesquisa
publicada pelo portal terra em julho de 2007 mostra que uma falha de segurança foi descoberta
em um erro de programação bastante comum. O erro era considerado apenas “preguiça de
programador", no entanto agora ele é considerado um defeito gravíssimo em segurança e está
presente em milhares de programas e sistemas em todo o mundo.
Atualizações de segurança também são frequentemente liberados com frequência por
diversos desenvolvedores de sistemas para correção de vulnerabilidades, descobertas em seus
diversos sistemas para evitar que erros e/ou falhas de programação sejam explorados por pessoas
mal intencionadas.
3.4.2. Fraude e Roubo
Podem ser ações causadas tanto por pessoas externas (conhecidas ou não) como, na
grande maioria das vezes pelos próprios funcionários, utilizando-se de métodos tradicionais,
como desvio de dinheiro e falsificação de documentos, ou através de novas formas. Os softwares
e hardwares em geral também são alvos vulneráveis de roubo.
De acordo com uma recente comparação feita pelo Centro de Estudos, Respostas e
Tratamento de Incidentes de Segurança - CERT.br (2011) notificações relacionadas a tentativa
de fraude apresentam crescimento de 45,8%, em relação ao trimestre anterior e de 23,6% sobre o
mesmo período de 2010. Houve aumento de 73,4% no número de notificações de páginas falsas
de bancos e de sites de comércio eletrônico (Phishing), em relação ao quarto trimestre de 2010 e
de 134,4% em relação ao mesmo período de 2010 (Tabela 3.1).
Tabela 3.1 Notificações de ataques classificados por tipo de ataque
Fonte: http://www.cert.br/stats/incidentes/2011-jan-mar/total.html
38
Os itens apresentados na Tabela 3.1 têm os significados a seguir descritos.

Worm: notificação de atividades maliciosas relacionadas com o processo
automatizado de propagação de códigos maliciosos na rede.

DoS(DoS – Denialof Service): notificação de ataques de negação de serviço, onde
o atacante utiliza um computador ou um conjunto de computadores para tirar de operação
um serviço, computador ou rede.

Invasão: um ataque bem sucedido que resulte no acesso não autorizado a um
computador ou rede.

Web: um caso particular de ataques visando especificamente o comprometimento
de servidores Web ou desfiguração de páginas na internet.

Scan: notificações de varreduras em redes de computadores, com o intuito de
identificar quais computadores estão ativos e quais serviços estão sendo disponibilizados
por eles. É amplamente utilizado por atacantes para identificar potenciais alvos, pois
permite associar possíveis vulnerabilidades aos serviços habilitados em um computador.

Fraude: segundo Houaiss, é "qualquer ato ardiloso, enganoso, de má-fé, com
intuito de lesar ou ludibriar outrem, ou de não cumprir determinado dever, logro”. Esta
categoria engloba as notificações de tentativa de fraudes, ou seja, de incidentes em que
ocorre uma tentativa de obter vantagens.

Outros: notificações de incidentes que não se enquadram nas categorias
anteriores.
3.4.3. Sabotagem dos Funcionários
Os funcionários têm um amplo conhecimento de como é a estrutura organizacional da
empresa, o funcionamento diário de sistemas e possíveis brechas facilitando a sabotagem. O
número de incidentes gerados por esse tipo de ameaça não chega a ser maior do que o número de
roubos, porém o custo desses incidentes pode ser significativamente maior. A insatisfação do
funcionário, como a não aprovação constante de seu chefe, a falta de reconhecimento ou
promoção de cargo ou salarial, pode levá-lo a esse tipo de ação, ajudando-o a atingir um nível
maior de insatisfação no seu trabalho.
O site BR-Linux.org publicou em 2008, em uma de suas reportagens, que um problema
na rede da telefônica que deixou boa parte de São Paulo off-line pode ter sido causado por
sabotagem interna. Segundo os próprios funcionários da companhia, uma semana antes do
incidente, foram demitidos cerca de 700 funcionários da Telefônica, por conta de fechamento de
contrato de terceirização com fornecedores. Um dos funcionários ainda citou que esse mesmo
problema já havia ocorrido há um ano, porém o incidente não havia sido tão grave.
3.4.4. Hackers Maliciosos
Também chamados de crackers, referem-se a pessoas que se aproveitam de brechas e
vulnerabilidades do sistema para invadi-lo. Podem ser tanto pessoas internas quando externas da
empresa. Atualmente os danos causados pelos crackers são menores do que os causados pelos
roubos e sabotagem de funcionários, porém recebem mais atenção do que as demais ameaças por
39
não haver o conhecimento do seu objeto e por tomar as pessoas vulneráveis por não conhecer a
identidade dos hackers.
Em dezembro de 2009 um e-mail circulava pela internet oferecendo vacina para antigripe
H1N1. Através desse e-mail os hackers maliciosos redirecionavam o usuário para um site falso
que baixava automaticamente programas maliciosos para o computador da vítima. O computador
contaminado era utilizado para furtar dados cadastrais, atacar outros computadores e transformar
a máquina em um servidor de "spam" (REUTERS, 2009).
3.4.5. Espionagem Industrial
É a ação em que se obtêm informações confidenciais de empresas particulares ou
privadas com o propósito de vendê-las para outras empresas. A espionagem industrial pode ser
encomendada por empresas para obter informações precisas de empresas concorrentes ou pelo
próprio governo para buscar vantagens econômicas ou nos seus negócios industriais. Os três
maiores tipos de danos causados pelo roubo de informação são: o custo dessa informação, a
informação do processo de manufatura e a especificação da informação no processo de
desenvolvimento de novos produtos e serviços.
A ABIN (Agência Brasileira de Inteligência) publicou em 2008 no seu site uma
reportagem realizada por Xavier (2008) sobre espionagem industrial relacionado ao furto
ocorrido na Petrobrás de informações sigilosas sobre pesquisas sísmicas que estavam
armazenadas em dois laptops que estavam sendo transportados em um container pela empresa
norte-americana Halliburton. Para Advir, diretor e dono da Ormax, uma empresa especializada
em contra-espionagem localizada em São Paulo, “A espionagem industrial é praticada há muitos
anos, mas tem crescido a passos largos graças à tecnologia mais barata e ao número da
competição entre as empresas" (XAVIER, 2008, p.88).
3.4.6. Código Malicioso
Refere-se a vírus, worms, trojans, malwares em geral. Atacam tanto computadores
pessoais quanto outros tipos de plataforma, como celulares. Atuais custos atribuídos à presença
de códigos maliciosos podem resultar primeiramente pela parada do serviço para remoção do
malware ou o tempo do funcionário envolvido no reparo do sistema, entretanto esses custos
podem ser significantes.

Virus: é pequeno programa de computador que se replica propositalmente, algumas
vezes em forma alterada. As versões replicadas do vírus original também são vírus.

Worm: programa de computador que se replica propositalmente. O resultado da
replicação são cópias do original que se espalham por outros sistemas fazendo uso dos recursos
da rede.

Trojans: programa que propositalmente conduz atividades secundárias, não observadas
pelo usuário do computador e que podem causar dano à integridade do sistema infectado. (TI
EXAMES ISO/27002 FOUNDATION, 2011).
Em uma entrevista realizada pela Módulo Security com Rob Slade (2006), especialista
em vírus de computador, foi publicado que os vírus de macros surgiram em 1995 e acreditava-se
que somente programas eram perigosos. Já em 1998 os criadores de vírus começam a disseminá40
los pela internet infectando um número maior de pessoas e se espalhando pela rede mundial
quase que instantaneamente, porém o maior problema surgiu em 2003 quando esses
desenvolvedores perceberam as possibilidades de fazer dinheiro com o uso desses malwares. O
risco passou a aumentar de forma gradativa e a conscientização dos usuários não acompanhou
esse processo.
Dessa forma, a conscientização passa novamente a ser um fator importantíssimo para as
empresas na mitigação de riscos e vulnerabilidades em seus ativos, conforme Slade (2006)
recomenda em um trecho de sua entrevista citando sobre as tendências para o futuro e o que as
empresas poderiam fazer para melhor se protegerem.
Nós não podemos saber como as tecnologias perigosas podem ser, mas sabemos que
serão como aplicações que colaboram para a "conveniência do usuário". Muito provavelmente,
se relacionarão com ferramentas que existam. Em termos de proteção a conscientização
continuará sendo a melhor defesa. Organize palestras para seus funcionários, ensine o que é
perigoso e que todos os atalhos geralmente resultam em infecções. É apontado também que
seminários para os usuários em geral são uma das mais efetivas proteções, em termos de custobenefício: ensinando usuários que não trabalham para você, você ajuda na proteção. Os vírus que
atingem usuários infectados enviam cópias e uma destas pode atingir você. (SLADE, 2006, p.2).
3.4.7. Spam
É um nome coletivo para mensagens indesejadas. O termo é normalmente usado para email, mas mensagens de publicidade e em web sites também são consideradas como spam.O
número de spams reportados para o CERT.br, órgão responsável por receber, analisar e
responder a incidentes de segurança envolvendo redes conectadas à internet, chegou a um total
de 31.367,42 somente entre janeiro e junho de 2011 e esse número vem crescendo
exponencialmente a cada ano (Figura 3.5).
Figure 3.5 Spams reportados ao CERT.br por ano
Fonte: http://www.cert.br/stats/spam/
41
3.4.8. Exploração de Vulnerabilidades
Vulnerabilidades ocorrem, principalmente, em softwares comerciais ou, até mesmo, nas
ferramentas de segurança como antivírus e firewalls. A Figura 3.6 exibe os incidentes reportados
em 2011 referentes aos tipos de ataque pelos sistemas e usuários de computadores.
Figura 3.6 Tipos de ataques reportados ao CERT.br no ano de 2011
Fonte: http://www.cert.br/stats/incidentes/2011-jan-mar/tipos-ataque.html
De acordo com resultados da 16ª edição do internet Security ThereatReport, divulgado
pela Symatec só em 2010 foram descobertos mais de 286 milhões de novas ameaças com ataques
direcionados às organizações. No universo da mobilidade, as incidências de ameaças subiram
para 42%. Com isso, as empresas norte-americanas gastam em média, $7,2 milhões para sanar
um vazamento de dados.
Em matéria divulgada pela DecisionReport (2011) Vendramini diretor Comercial da
Symantec Brasil cita como tendência de ameaça para os próximos anos ataques direcionados
como o Hydraq e o Stuxnet, esse último tem se mostrado uma ameaça crescente em todo o
mundo pelo fato de ser considerado o maior ataque cibernético da história. O Stuxnet abriu uma
porta para os malwares que alteraram a frequência de energia do motor, que ocasionou também a
capacidade de produção de uma empresa.
3.4.9. Ameaça à Privacidade
Podem ter várias origens, uma delas é a venda de informações pessoais dos cadastros de
moradores de uma determinada região ou país por funcionários públicos para empresas privadas
para que elas possam disseminar sua marca e promover propagandas de seus produtos e serviços.
A divulgação de informação também pode favorecer a engenharia social facilitando o ataque.
As informações também devem ser descartadas de forma adequada, evitando que pessoas
mal intencionadas possam conseguir informações valiosas, como contas e senhas de usuários,
configurações de computadores, número de contas bancárias, vasculhando o lixo de uma
empresa.
3.4.10. A Fragilidade das Senhas Fracas
Na tentativa de se obter sucesso em um acesso não autorizado o primeiro alvo a ser
atacado são as senhas de usuários, que geralmente não possuem uma complexidade na sua
42
elaboração, são anotadas e armazenadas em locais com pouca ou sem nenhuma segurança ou
compartilhada com demais usuários. Ao obter sucesso na invasão o hacker pode acessar
informações particulares ou confidenciais, instalar ou executar programas, tornar a máquina
vulnerável e trazer sérios riscos à organização.
De acordo com a redação do site Correio 24 Horas (2011), o apresentador Luciano Huck
teve a sua senha do Twitter roubada e divulgada aos seus seguidores. O hacker dizia que tinha
trocado a sua senha e mandado de forma privada para a mulher do apresentador, Angélica.
Poucos minutos depois, Huck brincou escrevendo para os seguidores. "Depois da indelicadeza de
ser hackeado no twitter... estou de volta! Ah... minha nova senha é: Angélica!", brincou.
3.5. Engenharia Social
Um engenheiro social recebeu a atribuição de obter os planos do seu novo produto que
deve ser lançado em dois meses. O que vai impedi-lo? O seu Firewall? Não. Dispositivos
avançados de autenticação? Não. Sistemas detectores de invasão? Não. Criptografia? Não.
Acesso limitado aos números de telefone de discagem por modems? Não. Nomes de códigos nos
servidores para dificultar que um estranho determine qual servidor podem conter os planos do
produto? Não.
A verdade é que não existe uma tecnologia no mundo que evite o ataque de um
engenheiro social (MITNICK, 2003).A ausência das medidas de segurança e a fragilidade
humana podem facilitar o uso da engenharia social, que é uma técnica para obtenção de
informações de uma organização ou pessoal através de métodos para enganá-las ou explorá-las.
Geralmente o infrator se passa por outra pessoa, fingindo ser um profissional ou outra
personalidade, não utilizando de força bruta ou falhas de equipamentos para explorá-los.Segundo
Mitnick (2003) a engenharia social usa a influência e a persuasão para enganar as pessoas e
convencê-las de que o engenheiro social é alguém que na verdade ele não é, ou pela
manipulação. Como resultado, o engenheiro social pode aproveitar-se das pessoas para obter as
informações com ou sem o uso da tecnologia.
Em uma reportagem exibida pelo programa Fantástico - Globo (2011) nos deparamos
com a notícia de que "No Rio falso tenente-coronel do Exército atuava nas barbas da cúpula da
Segurança Pública..." Esta noticia, que muitos devem ter visto ou ouvido, causou um verdadeiro
alvoroço tanto na mídia como na alta cúpula de Segurança Pública no Estado do Rio de Janeiro,
que foi colocada em uma situação um tanto constrangedora.
Em um dos seus trechos o falso coronel cita "Eu consegui porque entrei e ninguém me
perguntou nada e nem pediu nenhuma identificação. “E se já não bastasse” ainda apresentava
documentos falsos criados por ele próprio e por último em mais uma de suas colocações cita
"...que a parte que mais engana as pessoas é tão somente a convicção com que o engenheiro
social se porta, a forma como coloca os assuntos e os resultados apresentados...". Enfim, ele
utilizou-se de suas habilidades em convencer as pessoas, para se tornar parte de um projeto
maior, que neste caso específico, era estar/atuar na cúpula da Secretária de Segurança Pública do
Rio de Janeiro.
Algumas das características humanas utilizadas para a aplicação da engenharia social são
(MITNICK, 2003, p.8):
43
a) vaidade pessoal e/ou profissional;
b) autoconfiança;
c) formação profissional;
d) vontade de ser útil;
e) busca por novas amizades;
f) propagação de responsabilidades;
g) persuasão.
Inúmeras ferramentas podem ser utilizadas pelos engenheiros sociais para alcançar os
seus objetivos, entre eles podem-se destacadas a utilização do telefone, internet, e-mail, e/ou
correspondências, chats, malwares em geral, espionagem, roubo de informações através de
documentos descartados incorretamente (MITNICK, 2003).
Geralmente os engenheiros sociais bem-sucedidos têm a habilidade de lidar com as
pessoas, são educados e agradam facilmente, o que ajuda no estabelecimento de afinidade e
confiança. Utilizam-se de documentos aparentemente sem grande importância, o qual as pessoas
da organização não veem nenhum motivo pelo qual ela deva ser protegida e restrita, e
desenvolvem um ambiente de credibilidade, além de explorar a confiança da vítima sem levantar
qualquer suspeita utilizando-se da crença de que a probabilidade de ser enganado é muito baixa
(MITNICK, 2003).
Para que uma empresa ou pessoa evite a trapaça Mitnick (2003, p.32) diz que:
A sua empresa tem a responsabilidade de informar os empregados sobre
como pode ocorrer um erro sério quando informações não públicas são
tratadas da forma errada. Uma política de segurança bem desenvolvida,
combinada a educação e treinamento adequados, aumenta bastante a
consciência do empregado sobre o tratamento correto das informações
comerciais corporativas. Uma política de classificação de dados ajuda
você a implementar os controles adequados para divulgação das
informações. Sem uma política de classificação de dados, todas as
informações internas devem ser consideradas confidenciais, a menos que
seja especificado o contrário.
De acordo com Mitnick (2003, p.33) as empresas devem seguir alguns passos que ajudam
a protegê-la contra a divulgação de informações aparentemente inofensivas:
a) realização de treinamentos e conscientização fornecidos pela equipe de Segurança da
informação sobre os métodos utilizados pelos engenheiros sociais;
b) determinar o método apropriado de autenticação a ser usado quando os empregados interagem
com as pessoas que eles não conhecem pessoalmente ou por telefone.
c) classificação das informações que aparentam ser inofensivas verificando se o acesso a elas não
poderá levar o engenheiro social a acessar informações sigilosas da empresa;
d) o uso da terminologia interna pode fazer com o que o engenheiro social pareça assumir
autoridades e conhecimento;
44
e)evitar a divulgação dos telefones diretos dos CEOs ou diretos para pessoas desconhecidas.
Elaborar uma política de identificação positiva pode auxiliar no fornecimento dessas
informações somente aos colaboradores da empresa;
f) ter uma política escrita e bem divulgada sobre a divulgação de informações de código
contábeis dos grupos de trabalho e departamentos;
g)verificar sempre a identidade do solicitante juntamente com a necessidade que o requisitante
tem que saber;
h) os funcionários deverão ser treinados a negar educadamente alguma informação até que a
solicitação possa ser verificada. As políticas e procedimentos da empresa com relação à
divulgação de informação não pública devem ser sempre seguidos.
Portanto, trazendo isso à realidade corporativa, fica evidente que combater um
engenheiro social é um dos mais difíceis papéis, até mesmo para os mais experientes CSO, pois
depende da colaboração de todos da empresa. Essa colaboração só é possível de acontecer com
um mínimo nível de maturidade em segurança da informação, e para alcançar isso, uma das
ações que mais apresenta resultado são as políticas de conscientização de usuários (CORREIA,
2011).
3.6. Conscientização e Treinamento em Segurança
Um programa de conscientização e treinamento deve ser desenvolvido de acordo com os
motivos pelo qual as pessoas são vulneráveis aos ataques. Um estudo realizado por Robert B.
Cialdini durante 50 anos resumiu seis tendências básicas da natureza humanautilizadas pelos
engenheiros sociais (MITNICK, 2003, p.12).
Autoridades: as pessoas têm a tendência de atender solicitações que são feitas por pessoas com
autoridades ou que estão autorizados a fazer tal solicitação.
Afabilidade: as pessoas têm a tendência de atender solicitações quando o solicitante se faz
passar por alguém agradável ou com interesses, crenças e atitudes semelhantes aos da vítima.
Reciprocidade: costumamos a atender a solicitações quando acreditamos que recebemos algo de
valor como retribuição.
Consistência: após fazer um comprometimento público ou adotar uma causa as pessoas têm a
tendência de atender as solicitações para não parecem pouco confiáveis ou indesejáveis.
Validação Social: o cooperativismo quando a ação parece estar de acordo com aquilo que as
pessoas estão fazendo aparentando estar de forma correta e apropriada.
Escassez: as pessoas costumam cooperar quando o objeto que está sendo procurado está em falta
ou disponível por um curtoperíodo de tempo e que outras pessoas estão competindo por ele.
O programa de conscientização e treinamento deve visar à mudança de comportamento
dos funcionários motivando-os a querer fazer parte do programa protegendo os ativos da
empresa e também as suas próprias informações. Ele deve atingir cada pessoa que tem acesso as
informações confidenciais ou aos sistemas corporativos de computadores. Deve ser realizado de
forma contínua e atualizado sobre as novas ameaças e vulnerabilidades e divulgado a todos os
funcionários da corporação fazendo com que eles aprendam que cada colaborador tem um papel
importante na defesa contra tentativa de invasão aos dados confidenciais.
45
Por definição, a engenharia social envolve algum tipo de interação humana.Com
frequência, um atacante usa vários métodos de comunicação e tecnologias para tentar atingir o
seu objetivo. Por esse motivo, um programa de conscientização bem feita tenta abortar alguns ou
todos estes itens:
a) as políticas de segurança relacionadas com senhas de computador;
b) o procedimento de divulgação de informações ou material confidencial;
c) a política de uso do correio eletrônico, incluindo as medidas para evitar ataques maliciosos de
código;
d) a responsabilidade de questionar as pessoas que estão nas instalações sem o crachá;
e) como determinar a classificação das informações e as medidas adequadas para proteger as
informações confidenciais;
f) a eliminação adequada de documentos confidenciais e mídia de computador que contenham,
ou que já tenham contido material confidencial.
O programa de conscientização deve ser realizado de forma constante, além de ser criativo e
utilizar todos os canais disponíveis de comunicação para que todos os colaboradores tenham
acesso às mensagens e possam ter em mente os bons hábitos de segurança. Outra tática que pode
ser utilizada é a linguagem no qual as mensagens são redigidas evitando que elas tornem
familiares demais para serem ignoradas (MITNICK; SIMON, 2006).
3.7. O que é Hardening ?
Segundo o WikipediaHardening é um processo de mapeamento das ameaças, mitigação
dos riscos e execuçao das atividades corretivas – com foco na infraestrutura e objetivo principal
de torná-la preparada para enfrentar tentativas de ataques.
Muitos administradores sem muita experiencia em segurança preparam seus servidores
com uma instalação básica e, depois que suas aplicações já estão funcionando eles a deixam da
maneira que está. Eis que muitas vezes surge a seguinte frase “ Ah, já esta funcionando, então
está bom!”, e é ai que está o maior problema: achar que está bom.
O Sistema Linux torna-se bastante seguro uma vez devidamente trabalhado. E é por isso
que deve ser aperfeiçoado suas configurações padrões. Apesar de ser seguro quando
devidamente configurado é possível torná-lo ainda mais seguro. Adotar técnicas de hardening é
ter que pensar em três fatores: Segurança, risco e flexibilidade. É necessário saber dosar muito
bem esses três fatores para levar o sistema a uma ótima produtividade e segurança.
Sabe-se que não é possível ter 100% de segurança, mas, quanto mais segurança menos
risco mas também pouca flexibilidade, ou seja é uma razão inversa proporcional. Por outro lado,
se há grande flexibilidade no servidor, que permita qualquer tipo de programa nele, a segurança
ficará baixa e os riscos vão aumentar (MELO, 2006).
Tabela 5.2 para visualizar uma representação gráfica desses cenários.
Segurança
Risco
46
Flexibilidade
Não há uma regra direta para esses três fatores representados na Tabela 5.2, isso vai
depender de cada situação, de acordo com o tipo de necessidade. Por isso toda implentação de
um servidor deve ser bem definida antes de ser feita, nem que ela tenha que ser desenhada no
papel e analisada por várias vezes.
Embora as técnicas de hardening sejam de extrema importância, elas não se aplicam em
todas as situações. Cada caso é um caso. É preciso analisar e descobrir o procedimento que será
mais adequado para a necessidade em questão. Outro ponto importante é que ela é focada na
camada de “userland”. Hardening é composto por 4 etapas bem definidas são elas:
1º Mapeamento das ameaças
Ameaças é qualquer evento que possa gerar impacto negativo em nossos ativos. Ex:
usúario insatisfeito, incêndio, falata de recurso. Pra uma ameaça poder se concretizar ela
necessita de uma vulnerabilidade. Mesmo porque vulnerabilidade sozinha não faz nada. Quando
se tem diversas vulnerabilidades e ameaças que possam comprometer nosso ambiente
explrorando essa vulnerabilidade, temos um risco.
Dessa forma, enttão ameaças são circunstância e incidentes que podem gerar impactos
negativo explorando uma vulnerabilidade tornando um potencial risco.
2º Mitigação do Risco
Visa reduzir/eliminar os riscos ao nível aceitável, mas qual é o nivelaceitavel ?aquele que
meu ambiente pode trabalhar adequadamente de forma segura a zelar pelos 3 pilares da
segurança da informação e que esteja proteigo contra ataques.
Há 3 formas de lidar com os riscos:

Evitar o risco: Medidas são tomadas para eliminar a ameaça de tal forma que a ameaça
não leve a um incidente.

Suportar / Aceitar o risco: Considera que certos riscos são aceitos. Isto pode acontecer
quando o custo da medida de segurança execede o dano. Nesta estratégia a organização vai optar
por medidas de segurança repressivas. Ex: se houver um incêndio na sala deve-se apagar o fogo
com o extintor de incêndio.

Neutralizar o risco – Tomar o risco neutro: Medidas são tomadas mesmo que as
ameaças já não se manifestam mais, mas se por ventura venham a se concretizar, o resultado do
dano é minimizado. Nesta estratégia a organização pode optar pela combinaçao de medidas
preventivas, detectivas e repressivas.
3º Ações corretivas e preventivas
Ações Corretivas e preventivas para os Riscos de TlAs ações corretivas e preventivas
fazem parte do dia-a-dia dos técnicos e gerentes operacionais de TI. São inerentes às suas
funções e atreladas aos riscos do negócio sob sua responsabilidade. É recomendável que as ações
preventivas
sejam
mais
utilizadas
queascorretivas.
As ações preventivas devem estar previamente orçadas, contratadas, acompanhadas e
atuantes. Podem se restringir a uma ação puramente técnica controlada internamente ou pode
requerer uma ação externa (fornecedores, terceiros etc). As ações Preventivas estão atuantes pré47
ocorrência do Risco. Por outro lado as ações corretivas são ativadas pós-ocorrência do Risco.
Podem ser o último estágio antes do acionamento de um Plano de Contingência.
Ações corretivas em demasia podem ser o resultado de um planejamento ou operações
inadequadas ou mesmo a falta deles. Ações corretivas, na maioria das vezes ocorrem de forma
emergencial, sem planejamento e dependendo do procedimento e das ferramentas adotados
podem ser mais nocivas para o ambiente de Tl do que benéficas.
Podem ser evitadas caso haja ações Preventivas.Um exemplo clássico é a gestão de
servidores: é requerido que este passe por manutenções preventivas de hardware periódicas
(disco, memória, capacidade, performanceetc), assim como é requerido também que seu
ambiente operacional (sistema operacional, software gerenciador de banco de dados etc) seja
atualizado permanentemente de acordo com as orientações do fornecedor. Não havendo
manutenções e atualizações preventivas Hardware e Software, riscos de indisponibilidade do
ambiente
são
potencializados.
As ações preventivas possibilitam uma gestão de menos risco. No caso citado, contratos
de manutenção e suporte técnico junto a fornecedores e terceiros; treinamento técnico ao pessoal
interno e outras ações impedem que haja exposição e perdas financeiras da empresa em função
de indisponibilidade dos sistemas/serviços (IETEC-Instituto de Educação Tecnológica).
4º Estratégia de Segurança
Antes de decidir implementar um sistema de segurança um firewall por exemplo é
importante ter o conhecimento de algumas estratégias básicas empregadas na construção destes,
visando uma maior segurança e confiabilidade no firewall são métodos que podem e devem ser
analisados.
 Privilégio Mínimo: Garantir que o usuário só tenha acessoaos recursos que ele necessita ter
acesso. Tomando o cuidado de não atribuir privilégios menores que o necessário, pois desta
forma, tal objeto não conseguirá realizar suas tarefas. Este método é largamente utilizado,
sendo importante para eliminar ou amenizar os danos causados por pessoas mal
intencionadas.
No contexto de Internet, existem vários exemplos:

Todo usuário não precisa acessar todos os serviços de Internet existentes;

Todo usuário não precisa modificar todos os arquivos em seu sistema;

Todo usuário não precisa saber a senha de root (administrador) da máquina;

Todo administrador de sistema não precisa conhecer as senhas de root de todos os
sistemas;

Todo sistema não precisa acessar todos os arquivos de todo outro sistema.
Muitos dos problemas se segurança comuns na internet podem ser evitados com a
utilização deste princípio. Por exemplo, o Sendmail é um alvo muito visado pelos atacantes,
devido sua complexidade e o fato de que ele funciona acoplado ao root. O nível de complexidade
deste daemon aumenta a ocorrência de bugs, isto implica que, programas privilegiados devem
ser tão simples quanto possíveis. Caso um programa complexo exija privilégios acentuados,
48
devemos procurar meios de separar e isolar as partes que necessitam destes privilégios das que
não precisam (MELO, 2006).

Segregação de função: Consiste na separação entre as funções de autorização, aprovação
de operações, execução, controle e contabilização, de tal maneira que nenhum funcionário
detenha poderes e atribuições em desacordo com este princípio de controle interno.
A segregação de funções proíbe o usuário de, exercendo certa atividade, executar outra
atividade ao mesmo tempo que implique em risco operacional para o negócio. A hierarquia
organizacional reflete a estrutura dos papéis desempenhados pelos colaboradores dentro da
organização.
Várias normas e regulamentos governamentais, como Sarbanes-Oxley (SOX), COBIT,
ISO/IEC 27002, recomendam a implementação de controles, como o Perfil por Função, como
forma de seguir as políticas de acesso. Mas para que os controles funcionem de maneira
adequada, é extremamente importante que as pessoas tenham treinamentos corretos nos sistemas
de informação e conscientização nos temas de segurança da informação.

Segurança por Obscuridade: É um princípio nada confiável, pois consiste unicamente
em ocultar informações.
Exemplos práticos deste método são:

colocar uma máquina na Internet e achar que ninguém tentará invadi-la, simplesmente
porque você não contou a ninguém sobre ela;

abrir um servidor Apache em uma porta diferente para que ninguém o utilize, a não ser as
pessoas que você informou sobre sua existência;

configurar sua rede de forma que usuários internos vejam as informações de uma maneira
e usuários externos (Internet) não consigam ver tais informações, como portas e serviços
prestados em seus servidores.
Observe alguns pontos

sempre utilize esta técnica em conjunto de outras, pois manter a segurança apenas através
da obscuridade é muito ruim;

não anunciar algo não é o mesmo que ocultá-lo;

utilizar um sistema de criptografia desconhecido, não garante segurança nenhuma
(MELO, 2006);

Segurança em Profundidadeou em camada: implementar o máximo de controles
possíveis no ambiente pra proteger o ativo. Este princípio de segurança é destinado à prevenção
dos acidentes, e a minimização das respectivasconsequências, evitando que um problema isolado
se alastre pelo sistema; instituindo múltiplos, redundantes e independentes níveis de proteção. A
idéia aqui é não depender de um únicométodo de defesa, instalando vários níveis de proteção.
Tornando a tentativa de invasão arriscada demais ou cansativa demais para os atacantes. Isto
porque as chances de violar um nível de proteção do sistema são muito maiores do que as
chances de violar um sistema com vários níveis de segurança(MELO, 2006).
49
3.8. Segurança no Sistemas de Arquivos
Sempre que o sistema Linux é instalado, as boas práticas de instalação aconselha
particionar o disco e a colocar os principais diretórios em partição separadas, isso proporciona
uma maior segurança, pois cada partição tem sua tabela separada.
Caso o diretório /está em uma partição e o /home em outra, no caso de algum problema
no sistema ou até uma reinstalação, não perderia as informações no diretório
/home.Entretanto,segurança de um particionamento não é apenas isso. Todas essas partições são
montadas no diretório, e um erro que muitos administradores de sistema Linux cometem é não
ler a documentação para conhecer melhor os recursos e descobrir que o
camandomountpossibilita a utilização de algumas opções muito interessante, que permitem
melhorar muito a segurança nas partições.
Caso todos os diretórios estivessem na mesma partição, no /, não seria possível ter essas
opções e usufruir desses recursos. É possível retirar a permissão de Suid bit dos binários, mas só
isso tambem não resolveria. Vamos cortar o mal pela raiz, com essas opções do mount, dizendo
que na partição em questão os binários com permissão de Suid bit não terão efeito, entre outras
configurações.
Conformidade com as recomendações
A segurança em sistemas de arquivos, a norma ABNT NBR ISO/IEC 27002:2005,
recomenda, no item 10.4, que devemos proteger a integridade do software eda informação.
Execução do procedimento
A primeira opção do mounté o nosuid,que faz com que binários com permissão de Suid
bit não surtam efeito na partição na qual está definido.
Ex: prático, adicionar um usuário.
# adduser teste
Faça uma cópia das shells do seu sistema para o diretório home desses usuário e atribua as shells
a permissão de Suid bit.
# cp /bin/*sh /home/teste
# chmod 4755 /home/teste/*sh*
Logar em outro terminal com o usuário que foi criado e teste executar uma dessas shells.
$ cd /home/teste
$ ./sh
$ id
Na saida do comando id, podemos ver que esse usuário conseguiu permissão de root.
50
OBS.: Recomenda-se, para fins de melhor conhecimento do sistema, que esse teste seja feito
em todas as shells disponíveis.
Para resolvermos isso, vamos remontar a partição onde está montada o /home, mas agora
com a opção de nosuid.
# mount -o remount,rw,nosuid /home
# mount
O camandomountsem parâmentros nos mostra quais as partições estão montadas e suas
respectivas opções.
Com a partição remontada com nosuid, faça o teste novamente e veja que as asshells
continuam com o suid bit ativado. Entretanto, quando forem executadas, não vão mais
possibilitar o acesso no nível de root.
Outra opção que pode ser utilizado é o noexec, que impossibilita a execução de qualquer
binário ou arquivo executável dentro da partição na qual essa opção está ativa.
Essa opção pode ser aplicada a todos os diretórios, mas um clássico exemplo é aplicá-la
aos diretórios /home e /tmp. Crackerspodem ser aproveitar do diretório /tmp, onde por padrão
qualquer usuário pode introduzir backdoors ou qualquer outro programa malicioso para ter um
acesso completo ao seu sistema.
O mesmo exemplo realizado com o nosuid.Agora será remontar a partição com a opção
noexece tentar executar umas shells que copiamos para o /home.
# mount -o remount, rw,noexec /home
# mount
# ./sh
Observe que não foi possível executar a shell. Na tentativa de executá-las, retornou a
mensagem “permissão negada”; nessa partiçao, nada de execução.
Uma última opção que podemos utilizar é o noatime. Ele não é especificamente uma
opção para a questão de segurança, mas sim para a questão de performace, pois faz com que o
kernel do linux execute uma rotina a menos quando o noatime esta definido e destinado à
atuaização do tempo de acesso de arquivo.
Primeiro é conhecer o comando stat, utilizado para verificar o status de um arquivo ou de
um sistema de arquivos.
# stat /etc/passwd
A saida desse comando nos retorna informações importantes, mas vamos nos focar nas
informações do Access(atime), do Modify (mtime)e do Change (ctime).Veremos suas
diferenças.
Será criado dois arquivos, um no diretório /root e outro no /tmp, assumindo que o /root e
o /tmp estão em partiçoes diferentes.
# touch /root/teste1
51
# touch /tmp/teste2
Verificar o seu status, mas focando nas informações do Access,do Modifye do Change.
# stat /root/teste1
# stat /tmp/teste2
Diante das primeiras informações, vamos fazer os testes e ver o que será mudado. Vamos
visualizar o conteúdo dos arquivos, supondo que eles tenham algum conteúdo, e logo em seguida
será verificado o status dos arquivos.
# cat /root/teste1
# cat /tmp/teste2
# stat /root/teste1
# stat /tmp/teste2
Veja que os Accessdos arquivos estão diferentes. Quando nós visualizamos o conteúdo
dos arquivos, fizemos um acesso a ele, logo o seu tempo de acesso (Access) foi modificado.
Agora mais um teste nesses arquivos. Será modificado sua permissão e logo em seguida
visualizar o seu status.
# chmod 777 /root/teste1
# chmod 777 /tmp/teste2
# stat /root/teste1
# stat /tmp/teste2
Com atenção observer que o Access dos arquivos estão diferentes. Quando é
visualizado o conteúdo dos arquivos, é feito um acesso a ele, logo o seu tempo de acesso
(Access) foi modificado.
Será feito um teste nesses arquivos. Modificar sua permissão e logo em seguida visualizar
o seu status.
# chmod 777 /root/teste1
# chmod 777 /tmp/teste2
# stat /root/teste1
# stat /tmp/teste2
Percebe-se que agora o Access não foi modificado, mas o Changefoi. Sempre que
mudarmos a permissão de um arquivo, o Change será mudado, registrando a última data e hora
da mudança.
Agora será inserido um conteúdo nesses arquivos e logo em seguida verificar o que foi
modificado.
# echo abc> /root/teste1
52
# echo abc> /tmp/teste2
# stat /root/teste1
# stat /tmp/teste2
Percebe-se que o Change foi alterado novamente, mas ele não foi alterado sozinho: o
Modify também foi, pois agora não ocorreu só uma mudança de permissões, mas uma alteração
no conteúdo do arquivo.
Veremos a diferença entre o Access,o Modify e o Change,podemos fazer a alteração na
partição e ver o que será melhorado.
Agora é remontar a partição onde foi montado o diretório /tmp com a opção noatime.
# mount –o remount,rw,noatime /tmp
# mount
Com a partição remontada com a opção noatime, vamos fazer o primeiro teste que foi
realizado, o de listar o conteúdo do arquivo, e logo em seguida é verificado seu status dos
arquivos.
# cat /root/teste1
# cat /tmp/teste2
# stat /root/teste1
# stat /tmp/teste2
Observe que o Access(atime) do arquivo teste2 dentro do /tmp não foi modificado,
justamente por causa da opção noatime que colocamos na remontagem da partição.
Isso pode ser muito útil para os diretórios de logs, onde o acesso é feito constantemente
pelo sistema, pois faz com que ookernel deixe de executar uma rotina, o que ajuda sua
performance.
DICA:Essas não são as únicas opções que o comando mount pode nos oferecer.
Para ver todas as opções possíveis, consulte o man do comando mount.
53
Tabela 5.3 : bom exemplo da maneira pela qual podemos aplicar essas opções aos nossos
diretórios que estão montados em partições diferentes.
3.9. Programas Desnecessários
Após a instalação de um sistema Linux, devemos nos preocupar se todos os programas
que foram instalados nele são realmente necessários. Mesmo que tenha sido instalação mas
básica possível a verificação de programas é sempre uma boa escolha. Lembre-se de que o
servidor não deve conter programas “Clientes”.
No que diz respeito a programas instalados, a norma ABNT NBR ISO/IEC 27002:2005
recomenda no Item 11.5.4 que devemos remover todo utilitário ou software desnecessário do
sistema após uma checagem.
Execução de procedimento
Primeiramente é possível fazer uma pesquisa por todos os pacotes instalados no sistema,
justamente com suas versões. Em seguida, enviamos a uma lista para ser mais bem analisada.
Debian:
#dpkg
/root/pacotes
–l
|
awk
‘{print
$2,$3}’
|
sed
‘1,7d’
>
Com esse commando, estaremos pesquisando todos os pacotes instalados. Com o dpkg é
feito um filtro somente na segunda e na terceira coluna, que são os nomes dos programas e as
versões. O sed removerá as sete primeiras linhas que são importantes para a nossa pesquisa e a
direcionará isso para o arquivo de pacotes dentro do /root.
A retirada dos programas desnecessários será de acordo com a situação com que se está
trabalhando. Pode ser que, para um caso específico, seja necessário algum programa que, em
outros casos, não seja obrigatório. É importante que isso seja minunciosamente analisado.
Um exemplo é o programa wget, que é utilizado para fazer download sem a interação do
usuário. Isso pode ser um grande risco para um servidor, já que um cracker pode aproveitar-se de
problemas conhecidos do seu sistema e utilizar o wgetpara baixar programas maliciosos para seu
54
servidor, tais como exploits, backdoors, entre outros. Isso impossibilitará que ele tenha um fácil
acesso ao servidor ou que mesmo o danifique.
Concluindo o exemplo, se o seu Linux tem o wget, podemos então removê-lo,
# apt-getremove –purgewget
Faça uma análise completa dos programas que estão instalados por padrão no seu Linux e
verifique o que é realmente necessário. Lembre-se de cada caso é um caso.
DICA: O sistema Operacional Windows também vem com um programa semelhante
ao wget, o tftp. Caso esteja utilizando o Windows, também tome cuidado com esse
programa, pois muitos Spywares se aproveitam dele.
Podemos ver que, mesmo o sistema seja instalado no seu modo básico, ainda existe
programas que podemos ser retirados, pois talvez sejam até brechas de segurança em seu sistema
se forem bem explorados.
3.10.Arquivos com permissão Suid bit
A permissão de Suid bit possibilita que um determinado binário que só pode ser
executado, por exemplo, pelo usuário root seja executado por outro usuário comum do sistema.
Muitos binários no sistemajá vêm com a permissão de Suid bit, pois alguns binários que somente
o root pode executar precisam ser utilizados por um usuário. Exemplos clássicos desses
comandos o su, o ping, o passwde muitos outros. Mas em uma coisa devemos pensar: será que
todas esses binários que já estão com a permissão de suid bit vão ser utilizados por seus
usuários? Será que eles precisam de todas esses comandos a disposição?
Mas qual o problema de se ter um Suid bit ativado. O problema pode ser muito grande se
um cracker souber aproveitá-lo, explorando vulnerabilidades conhecidos para conseguir uma
shell do root. Podemos pensar no exemplo clássico das shells com permissão de suid bit que
quando executada por um usuário, pode liberar uma shell de root. O administrador tem que
atenta-se para essas coisas. Como o sistema possui muitos binários com suid bit, problemas
como esses das shells podem passar despercebidos.
Então o que podemos fazer?
Retirar todas as permissões de Suid bit do sistema de depois vamos setar essas
permissões somente para os binários que julgamos fundamentais para um usuário. Devemos
pensar sempre que vão existir casos diferentes, então os binários que julgamos importantes para
um servidor firewall por exemplo, podem não ser os mesmos para um servidor de e-mail.
Por recomendação da norma ABNT NBR ISO/IEC 27002:2005, no item 11.6.1, o acesso
á informaçãoe as funções dos sistemas e de aplicações por usuário e pessoal de suporte deve ser
restrito de acordo com o definido na política de controle de acesso.
55
Para remover todas as permissões de suid bit dos binários, temos que fazer uma pesquisa
no sistema e gerar uma lista com todos eles para uma melhor análise.
Será criado um diretório chamado teste dentro do /root para fazermos os nossos testes e em
seguidautilizaremos o comando findpara localizar com Suid bit.
# cd /root
# mkdirteste
# find / -perm -4000 > /root/teste/lista.suid
OBS.: O número 4000 representa a permissão de Suid bit, sendo que os três zeros
são as permissões padrões do sistema ( 0 para usuário, 0 para grupo e 0 para outros),
e o 4 representa a permissão a permissão Suid bit. Podemos ter também, no lugar do
4, o 2, que é Sgid bit, e o 1, que é Sticky bit, mas não vamos falar sobre eles aqui.
Faça uma listagem detalhada em um desses binários para ver como a permissão de suid bit
aparece.
# ls - l /bin/su
Vemos que nas permissões do usuário aparece um s no lugar do x. Isso representa que a
permissão de Suid bit está ativada, mas a permissão de execução (x) continua-lá.
Com a lista gerada, podemos ver qual desses binários precisa continuar com a permissão
de suid bit. Vamos pegar um exemplo de um Bastion Host, que é o Firewall da sua rede.
Podemos deixar dois binários com o Suid bit setado, que são o passwde o su. Podemos deixar o
passwd para que o usuário possa mudar a sua senha de acesso caso ele seja um administrador e
acesse essa máquina remotamente. Se estamos pensando em um firewall, mas não há motivos
para um usuário comum acessa-lo. Já o suvai ser de vital importância, pois podemos fazer que
tanto local ou remotamente o usuário root não tenha acesso direto. Assim, o administrador vai
logar com seu usuário comum, que pode ter alguns privilégios a mais, e depois utilizar o supara
se tornar o usuário root.
Vamos retirar todas as permissões de Suid bit dos binários.
# chmod -s -Rv /
Onde:
s - retira a permissão de Suid bit
R - é recursivo, do /para baixo
v - é o modo verbose (mostra o que está sendo feito pelo comando)
# ls –l /bin/su
Logo vamos setar a permissão de Suid bit somente para os dois binários que desejamos.
56
# chmod +s /usr/bin/passwd
# chmod +s /bin/su
# ls –l /usr/bin/passwd
# ls –l /bin/passwd
Com esses comandos, as permissões de Suid bit foram setadas novamente para esses dois
binários.
Pode ser que, para o servidor que você esteja configurando só o passawd e o sunão seja
suficiente, talvez outros binários precisem estar com o Suid bit ativado. Cabe analisar o que será
necessário para cada tipo de serviço.
Uma solução alternativa que podemos adotar é o comando sudo. Como ele podemos definir
somente os comandos queremos para o usuário comum executar como se fosse root.
Instalando o sudo.
#apt-getinstallsudo
Depois que o sudo estiver instalado, editaremos o arquivo /etc/sudores, que é onde
definimos quais usuários podem ter acesso aos comandos a serem definidos.
Alguns exemplos:
# vi /etc/sudores
Exemplo 1: teste ALL= /sbin/ifconfig, /sbin/iptables
Neste primeiro exemplo, vamos permitir que o usuário teste, possa executar os comandos
ifconfig e iptablescomo se fosseroot. Dessa maneira, entretanto, ele vai pedir a senha do usuário
na primeira vez que fomos executar esses comandos.
Podemos executá-los da seguinte maneira.
# sudoifconfig
# sudoiptables
Exemplo 2:teste ALL=NOPASSWD: /bin/reboot , /bin/halt
Estamos permitindo que o usuário teste, possa executar os comandos reboot e halt, mas
dessa vez sem que seja necessário que ele digite a senha (NOPASSWD).
Exemplo 3:teste ALL= /usr/bin/passwd [A-z]*, !/usr/bin/passwd root
Este commando permite que o usuário teste mude a senha de qualquer usuário cujo login
esteja no interlavo de A a Z, exceto o root.
No sistema Linux já vem com a permissão de suid bit ativado em muitos binários para
facilitar a utilização deles para outros usuários, mas vimos também que nem sempre essa
facilidade é uma boa, pois pode gerar brechas de segurança. Fiquemos atentos para esses tipos de
permissões.
57
3.11. Segurança no Terminal
Quando falamos em segurança, a primeira coisa que vem à mente é um possível ataque
remoto. Então, os nossos servidores que não estão conectados à internet não estão correndo
nenhum perigo, certo? Errado, alias, dois fatos errados. Não estar conectado diretamente à
internet não quer dizer que se está totalmente seguro, pois se um cracker conseguir passar pelo
nosso firewall, ele vai conseguir chegar até os outros servidores que não tem acesso direto à
internet, já que entrou em nossa rede interna. O outro fato é que um funcionário mal
intencionado pode ter um acesso local (físico) ao nosso servidor, diretamente no teclado do
próprio servidor.
Se somos administradores desprevenidos, vamos resolver um problema fora da sala e sem
perceber deixamos o terminal do servidor logado, com usuário de root. Então, esse funcionário
mal intencionado poderá fazer o que quiser, já que ele finge ser um cara que não entende nada de
informática, mas na verdade tem um conhecimento maior do que o nosso.
Para esse tipo de situação, podemos aplicar alguns procedimentos.
No que diz repeito ao software instalado, a norma diz, nos itens 11.5.5 e 11.5.6, que
devemos ter controle sobre os acessos no sistema a fim de evitar acessos não-autorizados e de
não fornecer informações desnecessárias.
1.
Desabilitar o uso de CTRL+ALT+DEL
Desabilitar o Ctrl+Alt+Del no sistema Linux pode ser uma boa idéia, pois não permitirá
que alguém pressione uma sequencia de teclas e faça com que o servidor reinicie. Isso é bom
principalmente quando seu servidor Linux está no mesmo armário que um servidor com o
sistema Windows, assim se evita que em algum momento você pressione Ctrl+Alt+Del no
teclado do Linux pensando que é o do Windows.
Edite o arquivo /etc/inittab e comente a linha a seguir:
#ca:12345:ctrlaltdel:/sbin/shutdown –t1 –a –r now
Você pode também mapear as teclas para executar um outro comando qualquer, por
exemplo.
#ca:12345:ctrlaltdel:/bin/echo
desabilitado por segurança”
“Esse
recurso
foi
Depois das alterações, precisamos atualizar o arquivo /etc/inittab. Isso é feito com o comando
seguinte:
# init q
2.
Limitar o uso dos terminais texto
Dependendo da situação em um servidor, por questões de segurança não é muito
interessante deixarmos o login habilitado em todos os terminais texto. Por exemplo, para impedir
o login nos terminais 4,5 e 6 devemos editar o arquivo /etc/inittab e comentar as seguintes linhas:
58
# vi /etc/inittab
# 4:23:respawn:/sbin/getty 38400 tty4
Depois das alterações, precisamos realizar novamente o arquivo /etc/inittab
# init q
3.
Bloquear o terminal com a variável TMOUT
No sistema Linux, temos uma variável que não vem setada por padrão. Essa variável é a
TMOUTque controla em quando tempo o terminal será deslogado.
Primeiro, podemos setá-la manualmente com um tempo pequeno para testarmos.
# TMOUT=15
Estamos setando o valor da variável para 15 segundos. Logo, se o terminal não for
utilizado durante os 15 segundos, ele será deslogado e o usuário será obrigado a logar-se
novamente.
Para melhorar, podemos colocar essa variável dentro do arquivo global da variável, para
que ela fixe toda vez que o sistema for iniciado.
# vi /etc/profile
If [ “ ’id –u’ “
-eq 0 ]; then
PATH=”/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/b
in:/usr/bin/X11”
else
PATH=”/usr/local/bin:/usr/bin:/bin:/usr/bin/X11:/usr/games”
fi
if [ “$PS1” ]; then
if [ “$BASH” ]; then
PS1=’ \u@ \h: \w \$ ‘
else
if [ “ ‘id –u’ “ –eq 0 ]; then
PS1=’# ‘
else
PS1=’$ ‘
fi
fi
fi
59
TMOUT=180
Export PATH
TMOUTumask 022
Dessa maneira, o sistema voltará para a tela de login se nenhum commando for executado
num intervala de 180 segundo (3 minutos).
4.
Bloquear o terminal com o programa Vlock
Com a variável TMOUT, fizemos com que o terminal seja deslogado automaticamente
depois de um determinado tempo. Podemos fazer isso também manualmente com um programa
chamado Vlock, que pode travar todos os terminais no momento em que quisermos.Instalação do
programa:
# apt-getinstallvlock
Para travar todos os terminais, digite:
# vlock –a
O Vlockexecutado com o parâmetro –a bloqueia o uso de todos os terminais. Os
terminais só serão liberados mediante autenticação com senha do usuário que os travou.
Pequenos detalhes em configurações, uma variável e um simples programa podem nos
ajudar a manter nosso servidor seguro, com todos os nossos terminais protegidos.
3.12. Gerenciamento de Privilégios
O usuário root é o usuário mais conhecido em sistemas *nix (o termo *nix aborda os
sistemas baseados em Unix). Quando algum cracker ou funcionário mal intencionado tentar um
acesso ao nosso sistema, seu foco vai ser conseguir senha do usuário root. Se ele tiver sorte e
consegui-la, terá acesso ao nosso sistema. Como evitar isso?
Vamos adotar alguns procedimentos para evitar que o usuário root tenha acesso direto ao
sistema. Nós seremos obrigados a utilizar nossos usuários comuns para logar e depois
utilizaremos o sudo ou su para virarmos root.
A norma ABNT NBR ISO/IEC 27002:2005, no item11.2.2, estabelece que concessão e
o uso de privilégio devem ser restritos e controlados.
1. Bloquear o login do root nos terminais texto
Não é seguro deixarmos o login como root habilitado para os terminais texto. O ideal é
bloquear o login do root em todos os terminais texto, logar como usuário comum e, quando for
necessário a realização de alguma tarefa administrativa, viramos usuário root usando o comando
su.
Criando o usuário comum
#adduserlix
60
Uma das maneiras pelas quais podemos bloquear o login do root é editar o arquivo
/etc/securetty e comentar as linhas referentes aos terminais que queremos desabilitar para o root.
Vamos comentar as seguintes linhas:
# vi /etc/securetty
# tty1
# tty2
# tty3
# tty4
# tty5
# tty6
# tty7
# tty8
# tty9
# tty10
# tty12
Agora que as linhas dos terminais estão comentadas, podemos tentar nos logar em outro
terminal com o usuário root. Veremos que não teremos sucesso.
Como dissemos, essa é uma das maneiras pelas quais se pode bloquear o acesso do root
pelos terminais.
2. Determinar datas de expiração para contas de usuários
Se o nosso servidor for alocar uma grande quantidade de usuários, podemos especificar
datas de expiração para as contas dos usuários. Dessa maneira, se aquele usuário utiliza a sua
conta todos os dias, quando sua senha expirar ele poderá modifica-la e renovar a conta. Mas, se
por algum motivo uma conta de um usuário não está sendo utilizada, ela será desativada no
tempo especificado, dando-nos uma segurança de que essa conta não será usada com más
intenções.
Utilizaremos o comando chage, que modifica os parâmetros do arquivo /etc/shadown,
onde são feitos esses controles.
Primeiro vamos visualizar a configuração padrão de uma conta de um usuário, por
exemplo, o usuário teste.
# chage –l teste
E agora faremos algumas modificações para esse usuário.
# chage –M 30 –W 5 –I 2 teste
# chage –l teste
Onde:
-M é o tempo máximo da validade da conta.
61
-Wé o tempo de aviso.
-Ié o tempo antes de uma conta ser desativada.
Com essa configuração, estamos dizendo que a conta do usuário é válida por 30 dias.
Quando estiverem faltando 5 dias para a conta expirar, o usuário começará a ser avisado quando
for logar. Depois desses 30 dias, o usuário terá 2 dias para poder modificar a senha e para que a
conta seja renovada. Enquanto ele não fizer isso, não conseguirá logar no sistema. Se nesses 2
dias o usuário não modificar a senha, a conta será desativada e somente o usuário root poderá
realtivá-la.
3. Remover shells válidas de usuários que não precisam delas.
Usuários que não utilizam shell não têm necessidade de tê-la. Vamos remover as shells
válidas de todos os usuários que não vãoexecutar oficialmente login no sistema através do
terminal local (tty) ou via ssh. Combinado a isso, criaremos um usuário estratégico pertencente
ao grupo de administradores, que também criaremos. Os usuários pertencentes a esse grupo terão
permissão para realizar o logine posteriormente usar o su para se tornar root.
Primeiro vamos criar o grupo administradores. Logo em seguida, criaremos um usuário
administrador e o adicionaremos ao grupo.
# groupadd administradores
# addusertoor
# gpasswd –atoor administradores
Vamos visualizar o arquivo /etc/passwd. Veja que todos os usuários de sistema também
possuem shells válidas.
# cat /etc/passwd | less
Criaremos um script para remover todas as shells válidas dos usuários, menos daqueles
que nós especificamos.
# cd /root
# vi inválidos.sh
# ! /bin/bash
For USER in $(cat /etc/passwd | cut –f l –d “:” | grep –v root |
grep –v toor | grep –v lix)
do
usermod –s /bin/false $USER
done
# ./inválidos.sh
Esse script, ele executa um for que pegará somente a primeira coluna do arquivo
/etc/passwd, que são os nomes dos usuários que não estão especificados no grep–v. Isso é
armazenado dentro da variável USER. Logo depois, com o comando usermod, esse script passa
todas as shells dos usuários que estão na variável USER para /bin/false, ou seja, uma shell
inválida.
62
Depois da execução do script, visualize novamente o arquivo /etc/passwd e veja como
ele ficou.
# cat /etc/passwd | less
Repare que todas shells dos usuários passaram a ser /bin/false, menos as dos usuários
root, toor e lix. Podemos adotar a política de que, sempre que criarmos um usuário novo, ele seja
criado com uma shell inválida. Caso ele precise de uma shell válida depois, podemos mudar isso
no arquivo /etc/passwd.
Para fazer isso, podemos editar os seguintes arquivos.
# vi /etc/adduser.conf
Nesse arquivo podemos mudar a variável DSHELL para uma shell inválida.
DSHELL=/bin/false
Dessa maneira nossos usuários seriam criados por padrão com a shell/bin/false, uma shell
inválida. Finalizando essa parte de shells, podemos visualizar o arquivo /etc/shells. Ele é um
arquivo texto que contém os nomes de caminho completos das shells de login válidos. Esse
arquivo é consultado pelo comando chsh (utilizado para mudar a shell de um usuário) e fica
disponível para consulta por outros programas.
# cat /etc/shells
É preciso ficar atento, porque há programas que consultam esse arquivo para descobrir se
um usuário é um usuário normal. Por exemplo, daemos (processos que são executados em
background) de ftptradicionalmente desaprovam acessos aos usuários com interpretadores de
comando não incluídos nesse arquivo.
3.20.Conclusão
O ambiente computacional e todas as suas tecnologias, com as mais modernas
arquiteturas, plataformas e inúmeras formas de garantir mais segurança da informação ainda não
é, e provavelmente não será, suficiente para conter o ímpeto curioso, criativo e astuto do cérebro
humano.
A engenharia social, combinada com a fragilidade humana, contribui para um dos pontos
mais vulneráveis que estão presentes em todas as organizações e que sempre existirão, pois não
há uma receita milagrosa de como transformar um ambiente que manipulam informações em um
local totalmente seguro.
Uma medida para dificultar o roubo ou o acesso indevido a essas informações são as
condutas, os treinamentos, os hábitos e o conhecimento de técnicas deHardening em servidores,
além da responsabilidade que se deve ter ao manipular, transmitir e descartar informações, sejam
elas confidenciais ou não.
Se a informação não for considerada uma fonte preciosa será preocupante o agravamento
da falta de instruções e conscientizações por parte dos funcionários e se tornará cada vez mais
difícil a implementação da segurança da informação, pois o desafio de manter as informações
confidenciais está cada vez menor e está cada vez mais fácil de encontrá-las e utilizá-las.
63
É importante ter em mente que a tarefa de se possuir profissionais capacitados e aptos a
trabalharem com segurança é realmente difícil, porém é um investimento que não deve ser
encarado como uma despesa a ser adicionada ao orçamento. Deve ser realizado de forma
constante, pois seu retorno será em longo prazo e de acordo com as mudanças culturais da
organização.
Mesmo o tema sendo discutido nas empresas, ainda assim percebe-se certo grau de
desconhecimento em segurança da informação por partes dos gestores e administradores de TI,
que ainda têm a mentalidade de que “as coisas só acontecem aos outros...” de modo que isso
reflete no ambiente corporativo. A verdade é que se tem um longo caminho para ser alcançado e
diante dos resultados pode-se perceber que as empresas já estão mais preocupadas em relação as
suas informações geradas ao longo do dia, que devem ser tratadas e gerenciadas para que não
ocorram situações como a imagem da empresa atrelada em fraudes ou vitimas de cibe
criminosos.
Referências
AMARAL,
Bruno
do.
Segurança
proativa.
Disponível
em
<http://www.decisionreport.com.br/publique/cgi/cgilua.exe/sys/start.htm?infoid=9819&sid=4
2> Acesso em: 12 de Outubro de 2012.
ARAUJO, Eduardo Edson de. A vulnerabilidade humana na segurança da informação. 2005.
Disponível em
<http://svn2.assembla.com/svn/GSIDEI/
Bibliografia/Monografia%20Interven%C3%A7%C3%A3o%20humana%20Seguran%C3%A7
a.pdf>. Acesso em: 01 de Outubro de 2012.
ASSOCIAÇÃO BRASILEIRA DE NORMAS TÉCNICAS. ABNT NBR ISO/IEC 27001:2006.
Rio de Janeiro, 2006.
ASSOCIAÇÃO BRASILEIRA DE NORMAS TÉCNICAS. ABNT NBR ISO/IEC 27002:2005.
2.ed. Rio de Janeiro, 2005.
BR-LINUX.ORG. Pane na telefônica: funcionários suspeitam de sabotagem. Disponível em:
<http://br-linux.org/2008/pane-na-telefonica-funcionarios-suspeitam-de-sabotagem/> Acesso
em: 15 de outubro de 2012.
CERT.BR. Incidentes reportados ao CERT.br janeiro a março de 2011. Disponível em:
<http://www.cert.br/stats/incidentes/2011-jan-mar/total.html> Acesso em: 01 de Outubro de
2012.
COMPUTERWORLD. Falhas de segurança em redes sociais geram risco para o negócio. Março
2010. Disponível em: <http://computerworld.uol.com.br/gestao/2010/03/04/falhas-de
seguranca-em-redes-sociais-geram-risco-para-o-negocio/> Acesso em: 10 de Outubro de
2012.
CORREIA, Marco. Engenharia social no Governo do Rio de Janeiro percebeu?. Disponível em:
<http://marcoacorreia.wordpress.com B/2011/04/03/engenharia-social-no-governo-do-rio-dejaneiro-percebeu/>Acesso em: 18 de Outubro de 2012.
CORREIA, Marco. Segurança da informação é novidade nas empresas. Disponível em:
<http://marcoacorreia.wordpress.com/ 2011/10/12/seguranca-da-informacao-e-novidade-nasempresas/>Acesso em: 14 de Outubro de 2012.
64
CORREIO 24 HORAS. Luciano Huck tem senha do Twitter roubada e brinca com a situação.
Disponível
em:
<http://correio24horas.globo.com/noticias/noticia.asp?codigo=57227&mdl=49>. Acesso em:
15 de Outubro de 2012.
DAWEL, George. A segurança da informação nas empresas. Rio de Janeiro: Editora Ciência
Moderna Ltda., 2005.
DECISION REPORT. A evolução das atividades maliciosas.Disponível em
<http://www.decisionreport.com.br/publique/cgi/cgilua.exe/sys/start.htm?from_info_index=1
53&infoid=8903&sid=4> Acesso em: 27 de Outubro 2012.
ESTADÃO. Hackers espalham vírus com oferta de vacina antigripe H1N1. Disponível em:
<http://www.estadao.com.br/noticias/geral,hackers-espalham-virus-com-oferta-de-vacinaantigripe-h1n1,475155,0.htm> Acesso em: 15 de Outubro de 2012.
FONTES, Edison Luiz Gonçalves. Segurança da informação:o usuário faz a diferença. São
Paulo : Saraiva, 2006.
FONTES, Edison Luiz Gonçalves. Vivendo a segurança da informação:orientações práticas para
as organizações. São Paulo :Sicurezza Brasiliano & Associados, 2000.
GUELMAN, Luiz. Conscientização de usuários: como envolver seu público com a Segurança da
Informação. 2006. Disponível em: <http://www.modulo.com.br/comunidade/entrevistas/616conscientizacao-de-usuarios-como-envolver-seu-publico-com-a-seguranca-da-informacao>.
Acesso em: 30 de Outubro de 2012.
MITNICK, Kevin D. A arte de enganar. São Paulo : Pearson Education do Brasil Ltda, 2003.
MITNICK, Kevin D.; SIMON, Willian L. A arte de invadir. São Paulo: Pearson Education do
Brasil Ltda 2006.
MÓDULO SECURITY SOLUTIONS.10ª Pesquisa Nacional de Segurança da Informação.2006,
Disponível em <http://www.modulo.com.br/media/10a_pesquisa_nacional.pdf> Acesso em:
MOREIRA, Nilton Stringasci. Segurança mínima: uma visão corporativa da segurança de
informações. Rio de Janeiro: Axcel Books, 2001.
REUTERS. Hackers espalham vírus com oferta de vacina antigripe H1N1. 2009, Disponível em
<http://br.reuters.com/article/internetNews/idBRSPE5B00SZ20091201?sp=true> Acesso em:
24 Outubro 2012.
MELO, Sandro. BS7799 Linux da Tática à Prática em Servidores. São Paulo: Alta Books, 2006
SEMOLA, Marcos. Gestão da Segurança da Informação: uma visão executiva. Rio de Janeiro:
Campus, 2002.
SLADE, Robert. Exclusivo: entrevista com Rob Slade– especialista em vírus de computadores.
Jun
2006.
Disponível
em:
<http://www.modulo.com.br/site?from%5Finfo%5Findex=8&infoid=791&lng=br&sid=91>
Acesso em: 24 de Outubro de 2012.
SYMANTEC.InternetSecurity Threat Report, volume 16.2010, Disponível
<http://www.symantec.com/threatreport/#> Acesso em: 24 de Outubro de 2012.
65
em:
TECHOJE.
Planos
de
Contingência
em
TI.
<http://www.ietec.com.br/site/techoje/categoria/detalhe_artigo/219>
novembro de 2012.
Disponível
em
Acesso em: 01 de
TERRA TECNOLOGIA. Erro de programação inofensivo vira ameaça à segurança. Disponível
em: <http://tecnologia.terra.com.br/ interna/0,,OI1790208-EI4805,00.html> Acesso em: 15 de
Outubro de 2012.
TI EXAMES. Curso preparatório para o exame ISO/IEC 27002 FOUDATION, 2011.
XAVIER, Herberth. Furto na Petrobrás traz à tona espionagem industrial. 2008. Disponível em:
<http://www.abin.gov.br/modules/articles/article.php?id=2008> Acesso em: 15 de Outubro de
2012.
WIKIPEDIA, Hardening, Disponível em: <http://pt.wikipedia.org/wiki/Hardening> Acesso em :
66
Desenvolvimento Web com Framework Primefaces
Jailson Nunes Leocadio, Roniere da Silva Sousa e Evaldo Sávio Silva Araújo da
Costa
Abstract
This chapter describes the contents discussed in short course about Web Applications
Development using the framework Primefaces. To this, it is presented a theoretical context of the
technologies used for the construction of systems in order to situate and connect the roles in
development. Understanding the characteristics of JavaServer Faces provides a deeper
understanding of how Primefaces components work and how is their communication with each
other and with the application logic. It is presented the set of elements of the JSF libraries,
HTML and Primefaces.
Resumo
Este capítulo descreve os conteúdos discutidos em minicurso sobre o Desenvolvimento de
Aplicações Web com utilização do framework Primefaces. Para isso, é feito a contextualização
teórica das tecnologias empregadas para a construção dos sistemas, no sentido de situar e
relacionar o papel de cada uma no desenvolvimento. Compreender as características do
JavaServer Faces possibilita entender mais profundamente como funcionam os componentes do
Primefaces e como se dá a comunicação deles entre si e com a lógica da aplicação. Apresentase o conjunto de elementos das bibliotecas JSF, HTML e do Primefaces.
4.1. Aplicações web
As aplicações web surgiram e agregaram benefícios sobre os modelos de sistemas até então existentes.
Isso ocorreu devido ao estabelecimento da rede mundial de computadores e do grande fluxo de
informações que constantemente flui dentro das organizações, e entre as instituições e as pessoas. Esse
tipo de aplicação, geralmente, implementa características de dinamismo, rapidez, disponibilidade,
atualização e portabilidade, que são propriedades necessárias para sobreviver frente ao mercado e ao
modelo social atual. Por isso, as experiências na utilização de tecnologias de desenvolvimento, levam à
criação de modelos e padrões que agregam as melhores práticas e tecnologias que proporcionam a
concepção de produtos que atendam a todas essas demandas de forma simples e segura.
4.2. O Primefaces como uma extensão do JavaServer Faces
O framework open-source Primefaces corresponde a uma biblioteca de componentes UI (User Interface)
que extende os componentes nativos do JavaServer Faces (JSF). Sendo assim, compreender as
características e o modo de funcionamento de uma aplicação desenvolvida em JSF corresponde em
conhecer também a dinâmica do Primefaces. Nos tópicos a seguir, será visto importantes tecnologias
67
que tornam possível o desenvolvimento de aplicações web com Java, e como elas trabalham em
conjunto com o framework de visão aqui em estudo.
4.2.1. JavaServer Faces
Mantido pelo comitê JCP (Java Community Process) com o Java Specification Request (JSR – 314), o
JavaServer Faces é uma tecnologia que se apresenta no formato de um framework, utiliza o padrão de
arquitetura MVC para o desenvolvimento de aplicações web em Java e emprega um modelo de
interfaces gráficas baseado em eventos. Divulgado inicialmente em 2004, atualmente está em sua
versão 2.
Ele possui dois grupos de componentes: a primeira são as Java APIs que modelam e definem os
componentes UI; a segunda são as taglibs JSP que realiza a representação dos componentes em uma
página JSP e também a conexão dos objetos no backend da aplicação. A API é ainda responsável pela
manipulação dos componentes e seu ciclo de vida (estados), handle-event, validação server-side,
conversão de dados, acessibilidade, além do suporte a internacionalização.
De acordo com diversos autores [Marafon 2006], [Rossi 2012], utilizar o padrão JSF proporciona
diversos ganhos no desenvolvimento de aplicações web, dentre esses benefícios, cita-se: reusabilidade
de componentes nas páginas, possibilidade de extensão pela utilização de bibliotecas de terceiros, a
existência de IDEs e plugins adaptados para o desenvolvimento de sistemas que utilizam o framework;
facilidade de construção de novos componentes, entre outros.
A primeira proposta de especificação para o JSF propõe oito principais metas:

Criar um framework de componentes GUI (Graphical User Interface) padrão que pode ser
aproveitado para a criação de ferramentas de desenvolvimento, que permitam criar interfaces
gráficas de alta qualidade e gerenciar as conexões entre os componentes e o comportamento da
aplicação;

Definir um conjunto de classes base simples para os componentes GUI, estados dos
componentes, e eventos de entrada. Estas classes controlarão o ciclo de vida dos componentes
e a persistência de dados referentes a eles;

Fornecer um conjunto de componentes comuns, incluindo elementos padrão HTML de entradas
de formulário. Eles serão derivados do conjunto das classes bases (item 1) e poderão ser usados
para definir novos componentes;

Fornecer um modelo JavaBeans para emitir os eventos acionados no lado do cliente para a
aplicação no lado do servidor, onde ocorre o controle do comportamento da aplicação;

Definir API's para validação de dados de entrada, incluindo suporte para a validação no lado do
cliente;

Especificar um modelo de internacionalização e localização dos componentes.

Gerar automaticamente saídas apropriadas para o cliente, de acordo com os dados disponíveis
de configuração, como versão do navegador e etc.;
68

Gerar automaticamente saídas que contenham suporte de acessibilidade, como definido pela
WAI (Web Accessibility Iniciative).
4.2.2. Padrão de Arquitetura MVC
O padrão de arquitetura MVC (Model, View e Controller) permite a separação entre a lógica de negócio
e as interfaces de visualização, pela divisão do sistema em três partes com responsabilidades distintas.
Essas são denominadas de modelo, visão e controle.
O modelo é responsável por representar os dados, manter o estado da aplicação pela definição
dos dados armazenados e fornecer o acesso às informações quando necessário. A visualização é
responsável por exibir as informações vindas do modelo e por captar e enviar aos controles, as ações
dos usuários sobre os dados apresentados. O controle faz a ligação entre a visão e os modelos,
acionando um ou outro, de acordo com as requisições recebidas. Essa interação produz modificações no
estado do sistema que então provoca respostas diferenciadas ao cliente.
Ao dividir em grupos as diversas tarefas de um sistema, o padrão MVC faz com que a aplicação
passe a ter uma arquitetura onde a interface pode ser modificada sem preocupações com alterações na
camada de lógica do negócio [Engholm Júnior 2010]. A Figura 4.1 [Algaworks 2010], logo abaixo, mostra
a interação entre os componentes do MVC, nela é possível perceber como os componentes interagem
para montar a dinâmica de funcionamento das aplicações que implementam esse padrão.
Figura 4.1 Arquitetura do JavaServer Faces baseada no MVC
Em JSF, a camada de controle é composta por alguns elementos distintos. O servlet chamado de
FacesServlet é quem recepciona e redireciona as requisições vindas da web e é ele também que envia a
resposta que será exibida pela visão; os arquivos de configuração mapeiam as ações realizadas e
definem as regras de navegação; e os manipuladores de ações e observadores de eventos são quem
recebem os dados vindos das interfaces, realizam o acesso ao modelo quando necessário e retornam o
resultado para o FacesServlet.
Já as views são providas pelos componentes de interface do JSF, que incluem componentes de
layout desde os mais simples, até outros mais complexos. Os componentes UI possuem propriedades,
69
métodos e eventos acessíveis pelo desenvolvedor, que possibilita identificar a interação do usuário com
estes componentes de interface.
4.2.3. Características de uma Aplicação Java com JSF
As aplicações Java para a web quando construída de acordo com a especificação J2EE, possui um
conjunto de padrões e modelos característicos bem definidos. Na figura 4.2 [Algaworks 2010], é possível
ver a forma como o JSF está relacionado com outras tecnologias na construção das aplicações dentro
desse padrão.
Figura 4.2 Arquitetura de Aplicações Java para a Web
O Java Servlet é a base para as aplicações Java e são responsáveis pela recepção de requisições
do cliente e envio de respostas, geralmente por meio do protocolo HTTP. Já o JavaServer Pages (JSP)
pode ser compreendido como uma abstração do Java Servlet e torna possível a utilização de código Java
nesses sistemas web. As páginas JSP são executadas nas views e utilizam Java do lado do servidor para a
criação de conteúdo dinâmico junto com as tags HTML. O JSP não oferece nada que não possa ser
criado com servlets puros, porém ele oferece a vantagem de ser facilmente codificado, facilitando assim
a elaboração e manutenção de uma aplicação web [Ferreirra e Martins 2009].
Nessa estrutura, existe o ciclo de vida formal do JSF, como pode ser visualidade na Figura 4.3,
[Jacobi e Fallows 2007]. Quando ocorre uma requisição, enviada pelo navegador, o Faces Servlet
recepciona essa requisição e dá inicio à execução dos seis passos mostrado na imagem: Restore View
(Restaurar a view), Apply Request Values (aplicar os valores do request), Process Validations (processar
as validações), Update Model Values (atualizar os valores do modelo), Invoke Application (invocar a
aplicação) e Render Response (renderizar a resposta).
70
Figura 4.3 Ciclo de vida formal do JSF
4.2.4. Componentes Visuais
A especificação do JSF fornece um conjunto de componentes básicos, incluídos em duas bibliotecas, a
“HTML”, que possui componentes que representam diversos elementos HTML e a biblioteca “Core”, que
é responsável por tarefas comuns no desenvolvimento de sistemas, como internacionalização, validação
e conversão de dados [Algaworks 2010]. A Tabelas1 4.1 e 4.2 mostram as tags disponibilizadas pela
biblioteca nativa do JSF e HTML, respectivamente, além de uma descrição das mesmas.
Tabela 4.1 Tags nativas na biblioteca JSF.
Tag
Descrição
f:actionListener
Registra uma instância de javax.faces.event.ActionListener junto a um
componente
f:ajax
Fornece recurso Ajax de forma padrão
f:attribute
Define o valor de um atributo no componente
f:convertDateTime
Converte datas e possui um conjunto de opções
f:convertNumber
Registra uma instância de NumberConverter
f:converter
Registra uma instância de Converter
f:event
Define o tipo de evento, por exemplo, para chamada de funções Ajax
f:facet
Adiciona um facet a um componente
f:loadBundle
Carrega um pacote de recursos de acordo com o local vigente
f:metadata
Engloba as tags f:viewParam
f:param
Configura um parâmetro para o componente associado
1
http://www.jsftoolbox.com/documentation/help/12-TagReference/
71
f:phaseListener
Adiciona um ouvidor de fases a um componente
f:selectItem
Adiciona um componente filho UISelect para o componente associado
f:selectItems
Adiciona um componente filho UISelectItems para o componente associado
f:setPropertyActionListener
Registrar uma instância de ActionListener no componente relacionado
f:subview
Cria um componente container que terá todo o core JSF e as tags aninhadas via
“jsp:include” ou outra tag dinâmica
f:validateBean
Utilizado para validações de acordo com as definições do Bean
f:validateDoubleRange
Registra uma instância de DoubleRangeValidator no componente associado
f:validateLength
Registra uma instância de a LengthValidator no componente associado
f:validateLongRange
Registra uma instância de LongRangeValidator no componente associado
f:validateRegex
Valida expressões regulares
f:validateRequired
Define componente como requerido
f:validator
Registra uma instância de Validator instance no componente associado
f:valueChangeListener
Registra uma instância de ValueChangeListener no componente associado
f:verbatim
Cria um componente output como um filho do componente associado
f:view
A tag View tag é o container para todo componente JavaServer Faces usado na
página
f:viewParam
Uso para URL
Tabela 4.2 Tags nativas na biblioteca JSF HTML.
Tag
Descrição
h:body
Renderiza um element Body do HTML
h:button
Renderiza um Button
h:column
Renderiza uma coluna dentro de um componente data table
h:commandButton
Renderiza um button que pode está associado a um backing bean ou a uma classe
ActionListener
h:commandLink
Renderiza um link HTML
h:dataTable
Cria uma data table
h:form
Renderiza um elemento tipo form
72
h:graphicImage
Renderiza uma tag de imagem em HTML
h:head
Renderiza um elemento head
h:inputHidden
Renderiza um elemento input do tipo "hidden".
h:inputSecret
Cria um elemento input do tipo "password".
h:inputText
Cria um elemento input do tipo "text".
h:inputTextarea
Cria um elemento input do tipo "textarea"
h:link
Configura links
h:message
Renderiza mensagens específicas para um determinado componente
h:messages
Renderiza todas as mensagens para a view atual
h:outputFormat
Cria um elemento para exibição de texto
h:outputLabel
Renderiza um elemento "label"
h:outputLink
Renderiza um elemento link HTML que possua o atributo "href"
h:outputScript
Renderiza a tag HTML <script/>, que trás um JavaScript existente na biblioteca
JSF 2.0
h:outputStylesheet
Definite arquivos de layout CSS
h:outputText
Tag básica para textos
h:panelGrid
Renderiza um panelGrid compatível com a tabela do HTML4
h:panelGroup
Container de componentes
h:selectBooleanCheckbox
Cria um elemento input do tipo "checkbox".
h:selectManyCheckbox
Cria uma lista de checkboxes.
h:selectManyListbox
Cria um “select” list
h:selectManyMenu
Cria um elemento "select” com múltiplos atributos
h:selectOneListbox
Renderiza um elemento HTML "select" de qualquer tamanho sem atributo
"multiple"
h:selectOneMenu
Cria um elemento do tipo Select One Menu
h:selectOneRadio
Cria um elemento do tipo Select One Radio
4.3. Persistência com JPA
73
A JPA (Java Persistence API) é uma especificação que padroniza as ferramentas ORM (Object Relational
Mapper) para os sistemas desenvolvidos em Java. As ferramentas ORM fazem o mapeamento e
transição automática de dados entre os paradigmas relacional e orientado a objetos (OO). Isso é
necessário, tendo em vista que as aplicações Java são construídas seguindo as regras de OO e os SGDB’s
geralmente são organizados de acordo com o modelo relacional.
Dentre as implementações de JPA, destaca-se o Hibernate que é o mais utilizado para esse
propósito; mas existem outras implementações como o EclipseLink e OpenJPA. As ferramentas que
seguem as regras da JPA caracterizam-se por serem independentes de linguagem SQL, resultando num
baixo acoplamento entre aplicação e os Sistemas Gerenciadores de Banco de Dados (SGDB).
4.4. Manipulação de Dados com JPQL
A Java Persistence Query Language (JPQL) é uma linguagem de consulta ORM que permite a realização
de consultas sobre classes e objetos. A linguagem suporta consultas de campos individuais de uma
entidade e operações como update e delete, subqueries, join, group by, e having. A linguagem é uma
extensão da EJB Query Language (EJB QL), e inclui outras funcionalidades não presentes nesta
linguagem que a antecede. Todas as operações em JPQL podem ser realizadas no modo de consultas
dinâmicas ou estáticas.
4.5. Facelets
Até a versão 1.2 do JSF, existem algumas deficiências que dificultam a vida do programador de páginas,
como a falta de um mecanismo para criação de templates de telas integrado ao JSF e também para
criação de novos componentes visuais a partir da composição de outros componentes já existentes
[Algaworks 2010], a partir disso, foi desenvolvido um framework denominado Facelets para facilitar o
gerenciamento das telas criadas. Na versão 2 do JSF, o Facelets é o engine padrão que gerencia as
interfaces.
Ao se utilizar Facelets, as páginas deverão ser construídas usando XHTML (eXtensible HyperText
Markup Language), e não mais JSP, pois o framework possui um compilador XHTML responsável pelo
gerenciamentos e reaproveitamento dos templates criados. A tag do Facelets possui as bibliotecas a
seguir: component, composition, debug, decorate, define, fragment, include, insert, param, remove e
repeat.
4.6. Primefaces
O Primefaces, em sua versão atual 3.4, é um framework composto por mais de 100 componentes para o
JSF, com suporte nativo a Ajax e HTML5. Possui boa documentação e ricos exemplos de códigos
disponibilizados na web para auxílio na utilização dos mesmos. Para utilizar o Primefaces em um
projeto Java que implemente JSF 2, é preciso fazer o download do arquivo primefaces-{version}.jar no
74
site do framework, adicioná-lo ao classpath da aplicação web desejada, e importar o namespace para
chamada dos componentes: xmlns:p="http://primefaces.org/ui".
A Figura 4.4 [primefaces.org], logo abaixo, mostra a codificação de alguns componentes do
Primefaces numa página web. Nela, os elementos estão definidos dentro de um formulário, que faz
parte da biblioteca HTML e por isso foi definido pela tag <h:form>. Ainda há outros elementos da
mesma biblioteca, são eles o panelGrid e o outputLabel. Neste código encontram-se dois elementos
simples do Primefaces: o inputText e o commandButton.
Figura 4.4 Codificação de componentes HTML e Primefaces
Os componentes são definidos por seus atributos configuráveis, que podem ou não está
vinculado a classes Java denominadas Managed Bean, que são classes que fornecem ao desenvolvedor
o acesso aos estados dos componentes na tela, ou seja, eles fazem a ligação entre interfaces gráficas e a
lógica da aplicação. O resultado do código da Figura 4.4 é exibido na figura abaixo, Figura 4.5
[primefaces.org].
Figura 4.5. Componentes em exibição na tela.
O Primefaces oferece os componentes mais populares utilizados em páginas na internet, e
outros mais complexos, fazendo com que seja possível encontrar em sua biblioteca um elemento para
quase todas as necessidades na construção das interfaces gráficas. Dentre os principais componentes,
cita-se: AutoComplete, BooleanButton, BooleanCheckbox, Calendar, Editor, InputMask, InputText,
InputTextarea, Keyboard, ManyButton, ManyMenu, ManyCheckbox, OneRadio, Password, Slider,
DataExporter, DataList, DataGrid, DataTable, GMap e muitos outros componentes distribuídos nas
categorias Ajax Core, Input, Button, Data, Panel, Overlay, Menu, Charts, Message, Multimedia, File,
DragDrop e Misc.
Sobre a exibição de mensagens de validação, são utilizadas as tags Messages e Growl do
Primefaces, isso torna fácil a construção destas mensagens e outros avisos que se deseja exibir durante
75
a utilização dos componentes na tela. Essas mensagens podem ser geradas pela manipulação da própria
interface ou serem lançadas a partir do managed bean.
O Primefaces disponibiliza um conjunto de 37 temas pré-definidos, alguns deles mostrado na
Figura 4.6, que podem ser utilizados nos projetos de desenvolvimento. Para isso é necessário fazer o
download do theme.jar e adicioná-lo ao classpath da aplicação. Além desses, é possível utilizar a
ferramenta ThemeRoller, divulgado no site do framework, para criar um novo tema sem necessidade de
conhecimentos aprofundados sobre CSS.
Figura 4.6 Temas pré-definidos.
4.7. Conclusão
O framework aqui estudado é uma ferramenta utilizada em muitos projetos relatados na
internet, sempre com críticas positivas da sua utilização. As atualizações de versões são
frequentes, o que vai permitindo a melhoria e o incremento dos componentes
disponibilizados.
Referências
Algaworks. (2010) “DWJSF – Desenvolvimento Web com JavaServer Faces”,
http://www.algaworks.com/treinamentos/desenvolvimento-web-com-jsf
Engholm Júnior, H. (2010) “Engenharia de Software na Prática”. São Paulo: Novatec Editora.
Ferreira, A. D. e Martins, L. A. (2009) “Comparativo Entre as Tecnologias JSP (JavaServer Pages) e ASP
(Active Server Pages)”, http://www.inf.ufrgs.br/gppd/disc/cmp167/trabalhos/sem2001-1/T2/alex/
Jacobi, J. e Fallows, J. R. (2007) “Pro JSF e Ajax - Construindo Componentes Ricos para a Internet”. Rio de
Janeiro: Ciência Moderna.
76
Marafon, L. D. (2006) “Integração JavaServer Faces e Ajax”. Monografia (Graduação em Ciência da
Computação) - Universidade Federal de Santa Catarina, Santa Catarina.
Rossi, C. L. (2012) “Interfaces Ricas para Web: Aplicação com PrimeFaces”. Monografia.
(Aperfeiçoamento/Especialização em II Especialização em Tecnologia Java) - Universidade
Tecnológica Federal do Paraná. Orientador: Beatriz Terezinha Borsoi.
77
Introdução à simulação de redes de computadores
com o NS-2 (Network Simulator) - Teoria e Prática
Marllus de Melo Lustosa
Abstract
Perform real experiments with computer networks is often not a trivial task, because, as you
know, in many cases can have a complex and heterogeneous environment such networks, which
can cause a significant impact on development time of this study. Therefore, computer simulation
is a technique used very often because it enables the performance evaluation of various
scenarios, including the use of new technologies and protocols, plus the ability to evaluate the
impact of different topologies in the environment. This paper attempts to transpose, for students,
teachers and professionals, the idea of using computer simulation in education and research
computer network, using examples of network simulation with the software NS-2 (Network
Simulator).
Resumo
Realizar experimentos reais com redes de computadores muitas vezes não é uma tarefa trivial,
pois, como se sabe, em muitos casos pode se ter um ambiente complexo e heterogêneo dessas
redes, o que pode causar um impacto significativo no tempo de desenvolvimento desse estudo.
Por esse motivo, simulação computacional é uma técnica utilizada com muita frequência, pois
possibilita a avaliação de desempenho de vários tipos de cenários, incluindo a utilização de
novos protocolos e tecnologias, além da possibilidade de avaliação do impacto de diferentes
topologias no ambiente. Este artigo tenta transpor, para alunos, professores e profissionais, a
ideia da utilização da simulação computacional no ensino e pesquisa de redes de computadores,
utilizando-se para isso exemplos de simulação de redes com o software NS-2 (Network
Simulator).
5.1. Introdução
O estudo de redes de computadores propõe analisar, quantita e qualitativamente, o desempenho de
sistemas conectados entre si, como a avaliação de protocolos de roteamento, segurança, topologias e
novas arquiteturas de comunicação. Desde a criação da pilha de protocolos TCP/IP bem como do
modelo OSI, o meio acadêmico e empresarial estuda a implantação de novas tecnologias para compor
este ramo da pesquisa. Para isso, trabalham em conjunto para propor novos protocolos e tecnologias,
que vão desde à camada de aplicação, como os "peer-to-peer" e ssh, à camada física, como as
arquiteturas de transferência de dados usb e wireless. A criação dos modelos TCP/IP e OSI foi
ambientalizada na adoção do modelo "Dividir para conquistar", o qual ataca, em partes, o desafio de se
propor novos estudos na área de redes de computadores.
78
O uso de técnicas de avaliação de desempenho de sistemas também é necessário para compor
estudos na área de redes, como: Análise real, modelagem analítica e simulação computacional. A análise
real faz uso de acompanhamento real do sistema, medindo e criando relatório das variáveis estudadas,
o que pode se tornar um processo árduo e, às vezes, impraticável, pelo alto custo e complexidade do
estudo. Os modelos matemáticos ou analíticos podem ser vistos como um conjunto de fórmulas
matemáticas de natureza estática, porém, muitos sistemas complexos não possuem modelos para
solução analítica, acarretando em hipóteses simplificadoras, o que o torna pouco utilizado em
ambientes de alta dinamicidade (Chwif and Medina 2006). Já a simulação computacional é uma técnica
que faz uso de soluções computacionais para modelagem e análise de situações reais, podendo prever,
com certa confiança, o comportamento de um sistema baseado em dados de entradas específicos e
respeitando um conjunto de premissas (Chwif and Medina 2006).
Nos demais tópicos serão mostrados as características dos modelos TCP/IP e OSI, bem como a
importância para o estudo de redes de computadores, além de promover o estudo de simulação
computacional de redes de computadores com o simulador de eventos discretos NS-2, demonstrando
todo o seu potencial, tanto na abordagem teórica do simulador quanto por meio de exemplos práticos
de simulação de redes.
5.2. Modelo OSI
Sigla para Open System Interconnection, é um padrão da ISO (Intenational Organization for
Stardardization) mundial que define um framework de rede para implementação de protocolos em sete
camadas. Esse padrão ISO, criado em 1984, afeta a forma de como a indústria de TI deve criar
protocolos de redes de computadores [Surman 2002]. Com base na teoria de "Dividir para conquistar", o
modelo foi criado com objetivo de traçar todas as partes de desenvolvimento de uma arquitetura ou
protocolo de comunicação que usa redes de computadores e máquinas heterogêneas em seu
funcionamento. O modelo é composto de várias camadas distribuídas desde o nível do usuário (camada
de aplicação) ao nível físico (camada física). A figura 5.1 mostra como estão dispostas essas camadas.
79
Figura 5.1. Exemplificação das 7 camadas do modelo OSI
5.3. Modelo TCP/IP
Criado e financiado pela ARPANET (Advanced Research Projects Agency), o TCP/IP,
comumente chamado de pilha TCP/IP, é um conjunto de protocolos de comunicação entre
computadores em rede. O nome foi dado em referência aos protocolos TCP (Transmission
Control Protocol) e IP (Internet Protocol). O conjunto de protocolos pode ser visto como um
modelo de camadas, onde cada uma é responsável por um grupo de tarefas, fornecendo um
conjunto de serviços bem definidos para o protocolo da camada superior. Sua evolução emergiu
no final de 1978, e em 1983 se tornou o primeiro modelo aprovado pela ARPANET. Os
protocolos para internet formam o grupo de protocolos de comunicação que implementam a
pilha de protocolos TCP/IP sobre a qual a internet e a maioria das redes comerciais funcionam
[Danzig and Jamin 1991]. A seguir, a Figura 5.2 mostra as camadas referentes ao modelo
TCP/IP.
80
Figura 5.2 Pilha de protocolos TCP/IP
5.4. Modelo OSI vs Modelo TCP/IP
A Arquitetura OSI foi elaborada pelas comissões da ISO, constituídas por representantes técnicos da
maioria dos países com experiência em comunicação de dados [Lima 2006]. O modelo OSI foi elaborado
seguindo métricas determinadas no decorrer do processo. Enquanto que a Arquitetura TCP/IP foi
elaborada no ambiente da Internet de acordo com a demanda e as necessidades do mercado [Lima
2006]. Os estudos da ARPA foram os grandes precursores para o desenvolvimento desse modelo.
A criação dos protocolos TCP e IP deu início a um novo paradigma de comunicação, baseado no
conjunto de vários protocolos que fornecem a possibilidade de transferência de dados por meio das
redes de computadores. A figura 5.3 mostra uma possível comparação entre esses dois modelos de
comunicação de dados.
Figura 5.3 Comparação dos modelos OSI e TCP/IP
5.5. Análise de desempenho de sistemas
Na implantação ou desenvolvimento de qualquer sistema computacional, é imprescindível o uso de
técnicas para avaliação de desempenho, pois permite ao pesquisador uma maior análise das métricas e
características do sistema em questão, objetivando uma maior viabilidade de recursos para o projeto,
além da utilização de diferentes parâmetros no processo de análise.
Existem três técnicas clássicas utilizadas na literatura para a avaliação de desempenho de
sistemas, que são: Medição real, modelagem analítica e simulação computacional. A primeira, também
chamada de métodos de benchmarking, provê o uso de ferramentas para teste diretamente no
hardware de estudo, ou seja, é necessária a disponibilidade do equipamento físico em questão no
ambiente de pesquisa. A modelagem analítica é baseada em métodos analíticos, que são modelos
matemáticos, como Redes de Petri e Cadeias de Markov, e consistem no principal meio de predição do
desempenho de sistemas que ainda não estão fisicamente disponíveis. A criação de um modelo analítico
preciso para determinado sistema é muito difícil, devido à complexidade do seu processo de
desenvolvimento do modelo [Marcari and Manacero 2003]. Por último, a técnica de simulação
81
computacional é empregada em referência à expressões matemáticas ou especificações mais ou menos
formalizadas, com a finalidade de representar um processo ou operação do mundo real. Assim, é
necessária a construção de um modelo de computador que corresponda à situação real que se pretenda
simular [Freitas 2008]. A simulação de sistemas é a utilização de técnicas matemáticas usadas em
computadores, que permitem "imitar" a operação de praticamente qualquer tipo de operação ou
processo do mundo real, o que significa que é o estudo do comportamento dos sistemas reais através
da exercício de modelos [Freitas 2008] [Chwif and Medina 2006].
A partir dessas técnicas, vários parâmetros são disponibilizados objetivando uma melhor
postura por parte do pesquisador em seus critérios de avaliação e adoção de um modelo para o estudo
de avaliação de desempenho de sistemas. Tais parâmetros podem ser vistos na tabela 5.1, retirada de
Jain [Jain 1991].
Tabela 5.1 Critérios para escolha de técnicas de análise ou predição de desempenho
[Jaim 1991]
Métodos
analíticos
Critério
Simulação
Benchmarking
1. Estágio de desenvolvimento
Qualquer
qualquer
pós-protótipo
2. Tempo na obtenção dos
resultados
Pequeno
médio
varia
3. Ferramentas para análise
analistas humanos
linguagem de
computadores
instrumentação
4. Exatidão
Baixa
moderada
varia
5. Avaliação de alternativas
Fácil
moderada
varia
6. Custo
Baixo
médio
alto
7. Credibilidade do método
Baixo
médio
alto
82
.5.1. Simulação computacional
Simulação, segundo [Longman Dictionary of Contemporary English 2003], é uma atividade ou
situação que reproduz uma condição real, mas tem uma aparência realística, sendo usada para
testar qualquer coisa. Segundo [Law e Mccomas 1991], simulação é a imitação de um sistema
real, modelado em computador, para avaliação e melhoria de seu desempenho. Ou seja,
simulação é o desenvolvimento virtual e controlado de uma realidade, afim de se estudá-la,
objetivando propor melhorias no ambiente, assim como [Banks 2000], que afirma que a
simulação envolve a criação de uma história artificial da realidade e, com base nesta história
artificial, são realizadas observações e inferências nas características de operação do sistema real
representado. A figura 5.4 esquematiza este conceito da transformação da realidade em modelo
e novamente dos resultados em realidade.
Figura 5.4 Realidade x Modelo [Duarte 2003]
Existem na literatura três tipos de modelos de simulação: Modelos discretos e contínuos.
Também existem os modelos híbridos, que trabalham com eventos estáticos e discretos em um
mesmo ambiente. Mais especificamente, de acordo com [Filho 1995], Um modelo é discreto se
todas as variáveis de estado têm seus valores alterados apenas em um número contável de
instantes de tempo. Já em um modelo contínuo, todas essas têm seus valores alterados a qualquer
instante de tempo. Um modelo é misto ou híbrido, se algumas variáveis de estado têm os seus
valores alterados a qualquer instante de tempo e outras apenas em um número contável de
instantes de tempo. A figura 5.5 demonstra como funciona uma simulação de eventos contínuos,
mostrando como exemplo a simulação do esfriamento de uma xícara de chá. A variável estudada
é a temperatura, que varia continuamente com o tempo.
Figura 5.5 Simulação contínua do estudo da temperatura do chá ao longo do tempo [Chwif and
Medina 2006].
83
Ao contrário dessa, a figura 5.6 exemplifica uma simulação de eventos discretos, ou seja, eles
são disparados em instantes de tempo descontinuados, pois, no modelo discreto, a execução dos
eventos ocorre em saltos.
Figura 5.6 Evolução dos estados na simulação de eventos discretos da preparação de uma xícara
de chá [Chwif and Medina 2006].
5.6. Simuladores de redes de computadores
Na literatura de redes de computadores, vários são os simuladores disponíveis para quem deseja
estudar a área, a exemplo do Jist [Barr and Haas 2004], Sinalgo [Sinalgo 2007] e OMNet++ [György
1993]. Alguns clássicos, como o Network Simulador 2 [NS 2001] e TOSSIM [Levis and Lee et al 2003] são
mais utilizados pela comunidade acadêmica, envolvida em diversos projetos sobre redes wireless,
cabeadas, veiculares, dentre outras.
Muitas são as linhas de pesquisa em redes de computadores, e pela grande quantidade de
pesquisadores envolvidos em projetos na área, é esperado que existam vários simuladores para os mais
diversos fins. Neste trabalho é proposta a iniciação e o desenvolvimento do estudo sobre simulação de
redes de computadores a partir da ferramenta Network Simulator - 2 (NS), cujos objetivos e motivações
serão descritos no próximo tópico.
5.6.1. Network Simulator - NS-2
NS-2 é um simulador de redes de eventos discretos. NS-2 fornece um apoio substancial para a
simulação do TCP, protocolos de roteamento e multicast com fio e sem fio (local e satélite). Ele
é descrito em C++ e uma versão orientada a objeto do Tcl (Tool command language) chamado
OTcl [Fall and Varadhan 2007]. É altamente escalável, com características de acoplamento de
módulos para simulação de diferentes tipos de redes. Na instalação do NS-2 ainda é seguido o
NAM (Network Animator), que é uma ferramenta capaz de realizar uma animação 2D da
simulação. A figura 5.7 mostra o resultado de uma pesquisa feita pelo autor deste trabalho, que
comparou a utilização dos simuladores de redes de computadores, em trabalhos publicados em
conceituadas conferências. Como resultado, apresentou-se a estatística do uso de simuladores de
redes e modelagem analítica, pela comunidade acadêmica no período entre 1998 e 2009, em
84
estudos na área de Redes de Sensores Sem Fio (RSSF). Num total de 46, todos os artigos
analisados na pesquisa foram retirados do portal de periódicos da capes.
Figura 5.7 Análise do uso de simuladores em pesquisas na área de RSSF entre os anos de 1998 e
2009.
Na figura acima, percebe-se que o software de simulação mais utilizado em trabalhos
com RSSF, no período estudado, e atingindo quase 70% de utilização, foi o NS-2, seguido de
simuladores próprios (P.S.) desenvolvidos para determinado fim de pesquisa. Em terceiro lugar
encontra-se o Tossim, e por último, com menos de 5% de uso, estão os modelos analíticos
(M.A.).
Além da motivação citada acima, outros tópicos interessantes favoreceram na
escolha do NS-2 como software de simulação de redes de computadores na composição desse
trabalho, dentre eles:
- Open Source;
- Possibilidade de interações em ambientes multiprotocolos;
- Facilidade de Trancing;
- Disponível em sistemas Unix, GNU/Linux, BSD, Solaris e Windows
(Cygwin);
- Orientado a objetos;
- Estrutura modular;
- Suporte à simulação de redes cabeadas e sem fio;
Percebe-se, portanto, sua grande abrangência tanto em relação ao desenvolvimento do
cenário de simulação de redes quanto na utilização de diferentes sistemas operacionais para
execução do mesmo, facilitados pelo motivo de este ser de código aberto e ter compatibilidade
com diferentes núcleos operacionais. Outra característica bastante interessante é a sua capacidade
de implementação em qualquer camada do modelo OSI, da aplicação à física. Na literatura,
existem modelos prontos de diferentes camadas, propostos por pesquisadores da área e
desenvolvedores do programa. O suporte à simulação de redes cabeadas e sem fio também é um
85
fator decisivo, pois, em ambientes reais, tanto pode-se ter um ambiente de simulação homogêneo
de nós em rede como a fusão desses dois tipos, wired-cum-wireless, como exemplificado na
figura 5.8, retirado de [Fall and Varadhan 2007].
Figura 5.8 Topologia de rede mista, onde se encontram nós móveis e fixos cabeados e sem fio
[Fall and Varadhan 2007].
5.6.1.1. NS-2 - C++ e OTcl
A importância e necessidade de utilizar duas linguagens de programação para compor o NS-2
está descrita a seguir.
- C++: É utilizada para compor o núcleo do simulador. É nela em que ocorre a
implementação e execução dos protocolos e aplicações. Pelo fato dessa linguagem trabalhar bem
com bytes e ter um tempo computacional de processamento relativamente baixo, além da
capacidade de trabalhar com orientação a objetos, ela foi escolhida para compor a padrão de mais
baixo nível do programa, agilizando os processos de recompilação de módulos.
- OTcl: A alta dinamicidade de mudança de uma simulação, aliada à rapidez no processo
de alteração do ambiente a ser simulado sem que os módulos e protocolos sejam recompilados
novamente, foram o que levaram a adoção de uma linguagem de scripts para compor o front-end
do usuário. A linguagem Otcl, variante orientada a objetos da Tcl, e interpretada, é capaz de
interagir com as classes C++ por meio da interface TclCL, que faz a ligação entre estas, numa
correspondência one-to-one [Fall and Varadhan 2007], conforme mostra a figura 5.9, retirada de
[Issariyakul and Hossain 2011].
86
Figura 5.9 Ligação one-to-one entre as classes compiladas e interpretadas, das linguagens C++ e
Otcl [Issariyakul and Hossain 2011].
A correspondência entre essas duas linguagens é melhor descrita por meio da imagem
5.10, retirada de [Rodolfo 2009], na qual são apresentados três níveis: O cenário de simulação, o
script Tcl e a implementação C++. O primeiro, representa um ambiente de simulação constituído
de 2 nós e comunicação sem fio. O script Tcl contém a instanciação e criação de um array de nós
e de um objeto simulador, pelas declarações das variáveis node_ e ns_. A implementação da
classe dos nós, chamada MobileNode (nó móvel), que contém todos os atributos e métodos
referentes a eles, é feita na linguagem C++, e é compilado somente um vez, na criação do
ambiente de simulação.
Figura 5.10 Interação entre as implementações Tcl e C++ no NS-2 [Rodolfo 2009].
5.6.1.2. NS-2 - Nós e enlaces - Modelo wired
Os nós (hosts) são definidos no NS-2, na linguagem OTcl, por meio do comando set
<nome_do_no> [$ns node], que seta um nó e referencia a classe node da instância do simulador
87
$ns. Eles são compostos de agentes, um ponto de entrada no nó, um classificador de endereços e
um classificador de portas. De acordo com [Anton 2003], um pacote gerado por um agente é
entregue ao nó ao qual o agente está ligado, através do ponto de entrada, que também recebe
pacotes cujo destino é o próprio nó. Após passar pelo ponto de entrada, o pacote é recebido pelo
classificador de endereços, que verifica se o pacote deve ser entregue a um agente pertencente ao
nó ou deve ser transmitido para um enlace de saída. Caso o pacote seja destinado a um agente do
próprio nó, o pacote é então repassado ao classificador de porta que, de acordo com o endereço
de destino, entrega o pacote ao respectivo agente. A arquitetura do componente nó é mostrada a
seguir, a partir da figura 5.11, retirada de [Coutinho 2007].
Figura 5.11 Arquitetura do componente do tipo nó, unicast e multicast [Coutinho 2007].
A definição dos nós está diretamente ligada à criação do enlace, que é uma estrutura que
conecta os nós, objetivando formar a topologia. Outro detalhe importante que se deve ter ciência
é o fato de a camada de enlace implementar as políticas de fila, ao contrário do que acorre em
ambientes reais, cujo gerenciamento de buffer é no próprio host. Portanto, o atraso no
encaminhamento dos pacotes de um nó a outro se dá pela soma do atraso do pacote na fila com o
atraso default do próprio enlace, o qual é definido pelo usuário. A camada de enlace também
guarda informações e gerencia o TTL do pacote, valor que vai decaindo com cada salto do
mesmo. Toda a estrutura dessa camada pode ser observada na figura 5.12, retirada de [Coutinho
2007].
Figura 5.12 Estrutura do enlace no NS-2 [Coutinho 2007].
88
O NS-2 suporta dois padrões de encaminhamento de pacotes nos enlaces: O tipo simplex,
em que os dados são enviados apenas em um sentido (exemplo da figura 5.12) e no modo em que
os pacotes trafegam em ambos os sentidos, caracterizando o tipo duplex.
O comando básico que define um enlace entre os nós é $ns duplex-link n0 n1 1Mb 10ms
DropTail. O comando contém parâmetros do tipo de encaminhamento do enlace (duplex ou
simplex), os nós que serão ligados (n0 n1), a largura de banda do link (1 Megabits/segundo), o
atraso do link (10 milissegundos) e a política de fila adotada para o enlace (DropTail).
5.6.1.3. NS-2 - Camadas de protocolos - Modelo Wireless
As camadas de protocolos do modelo wireless, no NS-2, descrevem a pilha de protocolos e
modelos referentes às camadas da arquitetura OSI, utilizadas pelo simulador. Qualquer
implementação de novos módulos para algumas dessas camadas, tem de ser realizada na
linguagem C++, cujas implementações estão na estrutura do próprio simulador. A figura 5.13,
retirada de [Rodolfo 2009] demonstra como funciona o modelo wireless no NS-2.
Figura 5.13 Funcionamento do modelo wireless no simulador NS-2 [Rodolfo 2009].
Iniciando pelo camada de mais alto nível, a camada "Agent" se liga à aplicação (ftp,
telnet, cbr, ...) e tem a função de receber ou transmitir pacotes, funcionando como Src
(transmissor) ou Sink/Null (receptor). Logo após, tem-se os componentes "Addr Demux" e "Port
Demux" que são os classificadores de endereço e porta, respectivamente, e cuja função já foi
explicada anteriormente, a partir da figura 1.10. A camada "RTagent" faz a implementação do
protocolo de roteamento utilizado na simulação, no caso do exemplo da figura 5.13, foi usado o
protocolo DSDV. A camada "LL" implementa a camada de enlace, cuja função é executar os
protocolos da camada de ligação de dados, como fragmentação ou reagrupamento dos pacotes.
Essa camada está também ligada à camada "ARP", que tem a função de converter o endereço ip
89
do pacote em endereço mac e vice-versa. A camada "MAC" implementa os protocolos de acesso
ao meio, como o padrão IEEE 802.11, que simplesmente foi uma transcrição em C++ do
firmware das placas de comunicação que se utilizam desse padrão. A camada "IFq" (interface de
fila) existe para dar prioridade aos pacotes de encaminhamento. O módulo PriQueue, referente a
essa camada, prioriza os pacotes de encaminhamento, colocando-os na cabeça da lista de espera.
As camadas "NetIF", "Radio Propagation Model and Antenna" e "Channel" modelam os
protocolos referentes à camada física, da arquitetura OSI. A primeira, "NetIF" (interface de
rede), implementada pelo módulo WirelessPhy, é usada pela classe MobileNode como uma
interface de hardware para acesso ao Channel. Especificamente, essa camada recebe os metadados, presentes no cabeçalho do pacote recebido, com informações sobre potência de
transmissão, energia gasta na transmissão ou restante (residual), comprimento de onda do sinal, e
encaminha para a camada de propagação de rádio e antena, que, a partir de modelos como o
TwoRayGround e Propagation e Free-space, quantifica as perdas de propagação e testa se o
pacote contém as condições necessárias para ser recebido pelo nó em questão, ou seja, se possui
a potência mínima para ser recebido, caso contrário, será descartado. Os modelos de antena
também são definidos na camada "Radio Propagation Model and Antenna", como por exemplo o
modelo OmniAntenna. Como tipo de canal, tem-se o exemplo do modelo WirelessChannel, que é
um modelo de propagação sem fio.
5.7. Projeto Liowsn
Implantar o ambiente computacional necessário para a iniciação das pesquisas na área de redes é
a primeiro passo para o pesquisador que deseja realizar simulações em seu estudo. No entanto,
além de instalar essas ferramentas, muitas vezes é necessário a configuração dos módulos
adicionais para estudos específicos, como por exemplo, os da área de rede de sensores sem fio
(RSSF), no caso do NS-2.
Considerando que a grande maioria desses programas e módulos são nativos para a
plataforma Linux, é natural que se tenha um corpo técnico para a realização da configuração
adequada do software no sistema operacional. Tendo em vista a grande lista de perguntas sobre
instalação do NS-2, como em [Nabble 2012], bem como dúvidas sobre a configuração de novos
módulos em grandes fóruns desses programas, como pode ser visto em [Nabble 2012], [The
Linux Question 2012], [Gname 2012] e [The Mail Archive 2012], entende-se que essa não é uma
tarefa trivial. A partir desse cenário, o projeto Liowsn (Linux for works with WSN, Linux para
trabalhos com redes de sensores sem fio), idealizado pelo autor deste trabalho, foi criado e
consiste de um sistema operacional GNU/Linux remasterizado com todas as ferramentas
clássicas para simulação de redes, já instaladas e configuradas, assim como a maioria dos
módulos para trabalhos com redes de sensores sem fio, cujo tema foi o foco do projeto [Lustosa
and Singh 2012]. Dentre essas ferramentas estão o NS-2 e OMNet++, além de alguns módulos
específicos para trabalhos na área de RSSF, como a Castalia e Mannasim. A descrição de todas
as ferramentas incluídas no sistema operativo segue abaixo.
- NS-2.34 (Simulador de redes);
- Mannasim (Módulo para simulação de RSSF para o NS-2.34);
- OMNeT++ (Framework para simulação de redes);
- Castalia (Simulador de RSSF, roda sob o OMNeT++);
90
- Xgraph (Analisador de arquivos trace);
- Tracegraph (Analisador de arquivos trace);
- NAM (Animador gráfico da simulação);
Percebe-se, então, que todo o ambiente necessário para iniciação à simulação de redes,
com as ferramentas mais utilizadas na literatura, está instalado no sistema operacional. Ele foi
disponibilizado
em
imagem
.iso
e
se
encontra
no
endereço
http://sourceforge.net/projects/liowsn/. O sistema operacional utilizado para compor o projeto
Liowsn foi o GNU/Linux Ubuntu 9.10, e será usado neste trabalho de simulação de redes por já
conter o NS-2.34 instalado e configurado. O sistema pode ser instalado em computador ou ainda
iniciá-lo pela opção live-cd, que funciona usando somente a memória principal (ram).
O NS-2 ainda pode ser utilizado instalando-o a partir de seus arquivos fontes ou binários
originais,
que
podem
ser
baixados
no
site
http://nsnam.isi.edu/nsnam/index.php/Downloading_and_installing_ns-2/.
5.8. Prática de simulação de redes com NS-2
O tópico a seguir abordará a prática da simulação de redes cabeadas e sem fio no simulador NS2, com exemplos bem claros de ambientes básicos de redes. Mostrará também os tópicos a serem
seguidos no desenvolvimento da simulação, assim como a análise básica dos arquivos trace
(arquivos gerados após a execução da simulação computacional).
5.8.1. Simulando uma rede cabeada
Para iniciar uma simulação de ambientes cabeados, ou seja, redes em que os nós são ligados por
links físicos, 5 passos basicamente são seguidos [Coutinho 2007]:
- Planejar a simulação;
- Definir os nós;
- Definir a ligação entre os nós (topologia);
- Definir o tráfego que será injetado na rede;
- Analisar os resultados;
O planejamento da simulação consiste em definir quais as características dos nós e
enlaces da rede a ser simulada. Segue abaixo a figura 5.14, que mostrando uma modelagem
básica de um ambiente de rede.
Figura 5.14 Planejamento da simulação
91
Na figura acima são definidas todas as características da rede a ser simulada, como a
topologia dos nós, a largura de banda do enlace seguido de seu atraso padrão, o tipo de fila
DropTail (com política FIFO - First In First Out) e os agentes UDP (User Datagram Protocol) e
NULL ligados aos nós, que são os agentes de roteamento de envio e recebimento do pacotes. É
definida também a aplicação CBR (Constraint Bit Rate), cuja é ligada ao agente de roteamento
UDP, que possui característica de entrega não confiável de dados.
A seguir, é mostrado o script, com extensão .tcl, desse cenário, adaptado de [Greiss 2012]
utilizado para ser executado pelo simulador NS-2, a partir do shell do Linux, como o comando
$ns nome_do_script.tcl.
# Criando o objeto simulador
set ns [new Simulator]
# Abre o arquivo de trace .nam e .tr
set nf [open out.nam w]
set f [open out.tr w]
$ns namtrace-all $nf
$ns trace-all $f
# Define o procedimento "finish"
proc finish {} {
global ns nf f
# Limpa os arquivos trace
$ns flush-trace
# Fecha o arquivo trace
close $nf
close $f
# Envia um comando para o shell e abre o arquivo trace do NAM pelo programa NAM
exec nam out.nam &
92
exit 0
}
# Cria dois nós
set n0 [$ns node]
set n1 [$ns node]
# Cria um enlace full-duplex entre eles
$ns duplex-link $n0 $n1 1Mb 10ms DropTail
# Cria um agente UDP e anexa-o ao nó n0
set udp0 [new Agent/UDP]
$ns attach-agent $n0 $udp0
# Cria uma fonte de tráfego e anexa-a ao agente udp0
set cbr0 [new Application/Traffic/CBR]
# Define os parâmetros de tamanho dos pacotes gerados e intervalo entre eles
$cbr0 set packetSize_ 500
$cbr0 set interval_ 0.005
$cbr0 attach-agent $udp0
# Cria um agente null0 e anexa-o ao nó n1
set null0 [new Agent/Null]
$ns attach-agent $n1 $null0
# Conecta os agentes udp0 e null0 (transmissor e receptor)
$ns connect $udp0 $null0
93
# Escalonador de eventos para a aplicação CBR
$ns at 0.5 "$cbr0 start"
$ns at 4.5 "$cbr0 stop"
# Chama o procedimento "finish" no instante de tempo 5 segundos.
$ns at 5.0 "finish"
# Executa a simulação
$ns run
A partir desse código, salvo com extensão .tcl e executado pelo comando acima citado,
tem-se dois arquivos trace: out.nam e out.tr. O primeiro, é o arquivo que será executado pelo
software NAM (Network Animator) e será responsável por realizar a animação gráfica da
simulação. Com ele, se tem a possibilidade de observar se a simulação ocorreu da forma como
foi programada, pela visualização gráfica que este fornece ao pesquisador, assim como é
mostrado pela figura 5.15, em um exemplo de utilização do software NAM. O segundo, out.tr, é
um arquivo trace que contém todos os dados da simulação, ou seja, todos os eventos que
ocorreram ao longo do tempo dado, como o instante de tempo de cada pacote enviado, se ele foi
recebido e/ou descartado, e até mesmo se passou por fila em algum enlace que trafegou. A
seguir, nas figuras 5.16 e 5.17, é mostrado parte do código do arquivo trace gerado pela
simulação acima e o que cada campo representa na análise dos dados, respectivamente.
Figura 5.15 Visualização dos fluxos de dados e estouro de fila, com o software NAM.
94
Figura 5.16 Exemplo de parte do arquivo trace gerado na simulação.
Figura 5.17 Análise dos campos do arquivo trace de uma simulação cabeada, adaptada de [Chung
and Claypool 2012].
Na figura 5.16, tem-se na primeira coluna o evento, que pode ser "r", "+", "-" e "d",
referente ao recebimento do nó ou monitoramento da fila. Logo após está o instante de tempo em
que ocorreu o evento, depois vêm os campos "from node" e "to node", que representa o nó
emissor e receptor. A coluna 5 ("pkt size") é referente ao tamanho do pacote. O campo "flags"
representa os campos seguintes, que são: Id do fluxo de dados do pacote ("fid"), o endereço do
nó fonte ("src addr") e do nó destino ("dst addr") e são representados por "nó.porta", o número
de sequência do pacote ("seq num") e o id do pacote ("pkt id"). A partir desses dados do arquivo
trace, é possível realizar diversas consultas com objetivo de receber informações a cerca de
determinados parâmetros de simulação, como exemplo:
- Vazão de um link (troughput);
- Índice de perdas de pacotes;
- Atraso médio na entrega dos pacotes (latência);
- Variação no atraso (jitter);
5.8.3. Simulando uma rede sem fio
A simulação de redes sem fio também segue os mesmos 5 passos para desenvolvimento do script
de simulação. A diferença está na criação dos parâmetros de topologia, que na rede wireless,
tem-se desde informações da camada física até a camada de enlace, definidas pelo usuário.
Abaixo segue um script de simulação, adaptado de [Rodolfo 2009] com dois nós sem fio (nó n(0)
e nó n(1)) que se movem, além de haver transmissão de dados FTP, por meio do agente de
roteamento TCP, entre eles (do nó n(0) ao nó n(1)), em um ambiente com dimensão 500x500m
(eixo z é definido como z=0). A figura 5.18, retirada de [Rodolfo 2009], mostra o modelo de
simulação utilizado.
95
Figura 5.18 Modelo pretendido para simulação [Rodolfo 2009].
Segue script .tcl abaixo:
# Define opções
set val(chan)
Channel/WirelessChannel;
# tipo do canal
set val(prop)
Propagation/TwoRayGround;
# modelo de radio-propagação
set val(netif)
Phy/WirelessPhy;
# tipo de interface de rede
set val(mac)
Mac/802_11;
# tipo MAC
set val(ifq)
Queue/DropTail/PriQueue;
# tipo de interface de fila
set val(ll)
LL;
# tipo de camada de enlace
set val(ant)
Antenna/OmniAntenna;
# modelo da antena
set val(ifqlen)
50;
# num máx de pacotes em ifq
set val(nn)
2;
# numero de nós móveis
set val(rp)
DSDV;
# protocolo de roteamento
# Inicializa variáveis globais
set ns_
set tracefd
[new Simulator]
[open simple.tr w]
96
$ns_ trace-all $tracefd
# Seta topografia da simulação
set topo
[new Topography]
$topo load_flatgrid 500 500
# Cria objeto GOD (Guarda informações sobre a conectividade da topologia)
create-god $val(nn
# Configuração dos nós
$ns_ node-config -adhocRouting $val(rp) \
-llType $val(ll) \
-macType $val(mac) \
-ifqType $val(ifq) \
-ifqLen $val(ifqlen) \
-antType $val(ant) \
-propType $val(prop) \
-phyType $val(netif) \
-channelType $val(chan) \
-topoInstance $topo \
-agentTrace ON \
-routerTrace ON \
-macTrace OFF \
-movementTrace OFF
#Criação dos nós
for {set i 0} {$i < $val(nn) } {incr i} {
97
set node_($i) [$ns_ node]
$node_($i) random-motion 0
; #Desabilita movimento randômico dos nós
}
# Define coordenadas iniciais para os nós (X,Y, Z=0)
$node_(0) set X_ 5.0
$node_(0) set Y_ 2.0
$node_(0) set Z_ 0.0
$node_(1) set X_ 390.0
$node_(1) set Y_ 385.0
$node_(1) set Z_ 0.0
# Criação de movimentos dos nós
# Nó n(1) vai para posição x=25m y=20m com uma velocidade de 15m/s, no instante de tempo
50s.
$ns_ at 50.0 "$node_(1) setdest 25.0 20.0 15.0"
# Criando a geração de tráfego
set tcp [new Agent/TCP]
$tcp set class_ 2
set sink [new Agent/TCPSink]
$ns_ attach-agent $node_(0) $tcp
$ns_ attach-agent $node_(1) $sink
$ns_ connect $tcp $sink
98
set ftp [new Application/FTP]
$ftp attach-agent $tcp
$ns_ at 10.0 "$ftp start"
# Reseta as configurações dos nós para encerramento da simulação
for {set i 0} {$i < $val(nn) } {incr i} {
$ns_ at 150.0 "$node_($i) reset";
}
$ns_ at 150.0 "stop"
$ns_ at 150.01 "puts \"NS EXITING...\" ; $ns_ halt"
proc stop {} {
global ns_ tracefd
$ns_ flush-trace
close $tracefd
}
# Inicia simulação
puts "Starting Simulation..."
$ns_ run
Após a execução do script de simulação acima é gerado o arquivo simple.tr, que é um
arquivo de trace completo da simulação, com informações a cerca de cada evento disparado na
mesma. A figura 5.19 mostra um exemplo de uma linha de código do arquivo trace de uma
simulação, e logo abaixo têm-se a caracterização de todos os campos.
Figura 5.18. Exemplo de parte do arquivo trace de uma simulação de redes wireless.
Abaixo segue a descrição de todos os campos referentes à figura acima.
- s: envio de pacote (também pode ser r - recepção, D - descarte, f - encaminhamento, c colisão);
99
- 0.029365548: instante de tempo em que ocorreu a operação;
- _1_: nó onde foi executado a operação;
- MAC/RTR/AGT: indica a camada que gerou a operação;
- ---: flags;
- 0: identicador do pacote;
- message/tcp: nome do pacote;
- 90 (bytes): tamanho do pacote;
- 0: tempo de duração do pacote contido no cabeçalho MAC;
- ffffffff: endereço de MAC de destino;
- 1: endereço MAC de quem enviou o pacote;
- 800: tipo de cabeçalho MAC do pacote (800 = ARP);
- -------: flags;
- [1:255 – 1:255 32 0]: cabeçalho IP;
- 1: endereço IP de quem originou o pacote;
- 255: porta de origem;
- 1: endereço IP do nó destino;
- 255: porta do nó destino;
- 32: campo TTL (time to live);
- 0: indica o endereço do próximo salto (hop);
5.9. Considerações finais
Este trabalho teve por objetivo teorizar sobre o tema de redes de computadores, abordando suas
características que vão desde os primeiros estudos de conexão entre sistemas até os modelos OSI
e TCP, além de conceituar as formas de análise de desempenho de sistemas, e mostrando o
porque da escolha da simulação computacional como foco deste trabalho. Foram relatadas
simulações com redes cabeadas e sem fio, a partir do programa NS-2, com um exemplo prático
de todo o desenvolvimento da simulação, que vai desde o planejamento da topologia de rede até
a análise dos arquivos trace, que contém as informações sobre todos os eventos ocorridos na
simulação, seja recebimento, envio, enfileiramento ou descarte de pacotes. O ambiente
operacional necessário para a iniciação de pesquisas que têm como foco a simulação
computacional na área de redes também foi discutido e focado no projeto Liowsn, um sistema
operativo proposto pelo autor desse artigo, e que visa prover um ambiente com várias
ferramentas mais utilizadas na literatura já instaladas e pré-configuradas para uso. Portanto, o
trabalho foi concluído, seguindo como base de ensino os métodos descritos acima, visando
sempre a adequação desse conteúdo de forma a torná-lo o mais claro possível, tanto para
100
docentes, que desejam repassar seus conhecimentos em sala de aula, como para pesquisadores
em geral, que necessitam desse conteúdo para o desenvolvimento de projetos na área.
Referências
Surman, G. (2002) "Understand security using the OSI model", SANS Institute - The Information Security
Reading, March 20.
Danzig, P., Jamin, S. (1991) "tcplib: A Library of TCP/IP Traffic characteristics". Technical
Report CS-SYS-91-01, University of Southern California.
Lima, S. H. (2006) "Comunicação de Dados - Arquitetura TCP em rede de dados", Engenharia
de Telecomunicações, Universidade de Santa Cecília - UNISANTA.
Marcari, E., Manacero, A. (2002) "Classificação de Técnicas para Análise de Desempenho de
Sistemas Paralelos e Distribuídos", FAPESP - Fundação de Amparo à Pesquisa do Estado de
São Paulo.
Freitas, P. J. F. (2008) "Introdução à Modelagem e Simulação de Sistemas: com Aplicações em
Arena", 2. ed. Florianópolis: Visual Books Ltda. 372p. ISBN 978-85-7502-228-3.
Chwif, L., Medina, A. C. (2006) "Modelagem e Simulação de Eventos Discretos: Teoria e Aplicações", 1
ed. São Paulo: Bravarte. 254 p. ISBN 85905978-1-4.
Jain, R. (1991) "The Art of Computer Systems Performance Analysis: Techniques for
Experimental Design, Measurement, Simulation, and Modeling", John Wiley & Sons, 2nd
edition.
Longman Dictionary of Contemporary English (2003), 3a Edição, Pearson Education do Brasil
LTDA.
Law, M. A., Mccomas, M. G. (1999) "Simulation of Manufacturing Systems", Proceedings of
the Winter Simulation Conference. Tucson.
Banks, J., (1999) "Introduction to Simulation", Proceeding of the Winter conference, Atlanta.
Duarte, R. N. (2003) "Simulação computacional: Análise de uma célula de manufatura em lotes
do setor de auto-peças", Dissertação (Mestrado em Engenharia de Produção) Programa de
Pós-Graduação em Engenharia de Produção, Itajubá, MG, UNIFEI.
Filho, C. P. (1995) "Introdução à simulação de sistemas", 159f. Campinas, SP: Editora da
UNICAMP.
Barr, R., Haas, Z. J.
http://jist.ece.cornell.edu/.
(2004)
"JiST/SWANS
Sinalgo
(2007)
"Sinalgo
Simulator
http://disco.ethz.ch/projects/sinalgo/index.html.
Fall, K., Varadhan, K. (2007)
documentation.html, August.
"The
ns
-
Java
for
manual",
in
Simulation
Network
Time",
Algorithms",
http://www.isi.edu/nsnam/ns/ns-
György, P. (1993), "OMNeT: Objective Modular Network Testbed", MASCOTS '93:
Proceedings of the International Workshop on Modeling, Analysis, and Simulation On
Computer and Telecommunication Systems: 323--326.
101
Levis, P., Lee N., Welsh M., Culler, D. (2003) "TOSSIM: Accurate and Scalable Simulation of
Entire TinyOS Applications", In: Proceedings of the First ACM Conference on Embedded
Networked Sensor Systems.
Issariyakul, T., Hossain, E. (2012) "Introduction to Network Simulator NS2",
DOI
10.1007/978-1-4614-1406-3
3, © Springer Science+Business Media, LLC.
Anton, R. E. (2003) "Análise de desempenho de protocolos para estabelecimento de chave de grupo em
redes ad hoc", X, 53 p. 29,7 cm (COPPE/UFRJ, M.Sc., Engenharia Elétrica), Tese - Universidade Federal
do Rio de Janeiro, COPPE.
Coutinho, M. M. (2007) "Network Simulator - Guia básico para iniciantes", http://gredes.ifto.edu.br/wpcontent/uploads/livroNS.pdf.
Nabble. (2012) "Network Simulator ns-2 - The Official Discussion List", Research on errors in
the
installation
of
the
ns2.
http://old.nabble.com/forum/Search.jtp?query=installation+error+ns&local=y&forum=15582
&daterange=0&star tdate=&enddate=/.
The Linux Questions. (2012) "Forum of the linux users", Research on errors in the installation of
the module Mannasim in Ns-2.
http://www.linuxquestions.org/questions/search.php?searchid=5438840.
Gname. 2012 "Forum of discussion on the NS-2", Research on errors in the installation of the
module Mannasim in
Ns-2.
http://search.gmane.org/?query=mannasim+error+installation&author=&group=gmane.netwo
rk.simulator.isi&sort=relevance&DEFAULTOP=and&xP=Zmannasim%09Ze
rror&xFILTERS=Gnetwork.simulator.isi---A
The Mail Archive. (2012) "Discussion list of the ns-users" Research on errors in the installation
of modules on the ns-2. http://www.mail-archive.com/search?l=nsusers%40isi.edu&q=error+installation+module.
Lustosa, M., Singh S. (2012) "Liowsn Project: An Operating System Remastered for Works with
Simulation of Wireless Sensor Networks", In: International Journal of Computer Applications
52(12):32-37, August 2012. Published by Foundation of Computer Science, New York, USA.
Greiss,
M.
(2012)
"Tutorial
for
http://www.isi.edu/nsnam/ns/tutorial/index.html.
the
network
simulator
“ns”,
Chung, J., Claypool, M. (2012) "NS by Example", Worcester Polytechnic Institute (WPI),
http://nile.wpu.edu/NS/purpose.
102
Desenvolvimento de Aplicações para Plataforma
Google Android
Fábio de Jesus Lima Gomes, Manoel Taenan Ferreira de Souza, Rafael Madureira
Lins de Araújo
Abstract
With the evolution of mobile technology, mobile devices have become an important source of
transmission and reception of information, creating the need for more robust operating systems
and a considerable demand for the development of services and applications. The Google
Android platform was created in order to fill this gap. Thus, this mini-course aims disseminate
concepts about developing services and applications for the Google Android platform. Also we
will describe how mobile applications can consume web services via REST architecture.
Resumo
Com a evolução da tecnologia móvel, os dispositivos móveis tornaram-se uma importante fonte
de transmissão e recepção de informações, gerando a necessidade de sistemas operacionais
mais robustos e uma considerável demanda para o desenvolvimento de serviços e aplicações. A
plataforma Google Android surgiu para preencher esta lacuna. Dessa forma, este mini-curso
pretende disseminar conceitos envolvidos no desenvolvimento de serviços e aplicações para a
plataforma Google Android. Também será abordado como aplicações para dispositivos móveis
podem consumir serviços web através da arquitetura REST.
6.1. Introdução
O Google Android OS, também chamado apenas de Android, é um sistema operacional de código aberto
para dispositivos móveis e utiliza uma versão modificada do Sistema Operacional Linux. Permite a
desenvolvedores criarem aplicações Java que controlam o dispositivo através de bibliotecas
desenvolvidas pela Google. O Android também provê uma infra-estrutura robusta de execução de
aplicações Java. Apesar de ser recente (seu lançamento foi em 2008), o Android foi adotado rapidamente
por diversos fabricantes de dispositivos móveis e atualmente é a plataforma que mais cresce no mundo.
Atualmente, a plataforma Google Android é mantida pela OHA (Open Handset Alliance), um
grupo formado por mais de 40 empresas que se uniram para inovar e acelerar o desenvolvimento de
aplicações e serviços para dispositivos móveis, trazendo aos consumidores uma experiência mais rica em
termos de recursos e menos onerosa financeiramente para o mercado. Pode-se dizer que a plataforma
Google Android é a primeira plataforma completa, aberta e livre para dispositivos móveis. O Android
SDK é o kit de desenvolvimento que disponibiliza as ferramentas e APIs necessárias para desenvolver
aplicações para a plataforma Google Android, utilizando a linguagem Java.
103
Este mini-curso visa abordar conceitos envolvidos sobre desenvolvimento de aplicações para a
plataforma Google Android, apresentando os principais aspectos do desenvolvimento de aplicações para
dispositivos móveis, com enfoque para o desenvolvimento de aplicações que consomem serviços web
utilizando a linguagem Java. Pretende-se capacitar os participantes no desenvolvimento de aplicações
Java para plataforma Google Android com base no Android SDK e demonstrar a arquitetura REST
(Representational State Transfer) de desenvolvimento de aplicações web. O curso procura explorar as
funcionalidades dessas tecnologias através do desenvolvimento passo a passo de aplicações-exemplos.
6.2. Arquitetura do Google Android
Android é uma pilha de software para dispositivos móveis que inclui sistema operacional, middleware e
aplicações-chave. Esta pilha possui 4 níveis (Google, 2011):
Figura 6.1. Arquitetura da Plataforma Google Android (Google, 2011)
1.
LINUX KERNEL: a base da pilha é o kernel. O Google usou a versão 2.6 do Linux para construir o
kernel do Android, que inclui serviços essenciais do sistema, tais como, gerenciamento de memória,
gerenciamento de processos, gerenciamento de energia, configurações de segurança, configurações
de rede e drivers. O kernel também atua como uma camada de abstração entre o hardware do
dispositivo e os outros níveis da pilha de software.
2.
RUNTIME ANDROID e LIBRARIES: acima do kernel estão as bibliotecas do Android e o android
runtime. Android runtime consiste de um conjunto de bibliotecas que fornece a maioria das
funcionalidades disponíveis nas principais bibliotecas da linguagem de programação Java e de uma
Máquina Virtual Dalvik (DVM). Uma aplicação Android roda em seu próprio processo, com a sua
104
própria instância da máquina virtual Dalvik. Dessa forma, nenhuma aplicação é dependente de outra;
se uma aplicação pára, ela não afeta quaisquer outras aplicações executando no dispositivo e isso
simplifica o gerenciamento de memória. Dalvik foi escrito de modo que um dispositivo possa
executar várias VMs eficientemente. Android possui um conjunto de bibliotecas C/C ++ usado por
diversos componentes da plataforma. As principais bibliotecas são listadas abaixo:

System C library – uma implementação da biblioteca padrão C (libc), derivada do sistema
operacional BSD, alterada para dispositivos embarcados baseados no Linux;

Media Libraries – baseada no OpenCORE da PacketVideo; estas bibliotecas suportam
reprodução e gravação de muitos formatos populares de áudio, vídeo e imagem, tais como,
MPEG4, H.264, MP3, AAC, AMR, JPG, e PNG.

Surface Manager – gerencia acesso ao sub-sistema de exibição e compõe as camadas gráficas 2D
e 3D para as aplicações.

LibWebCore – um moderno engine para um navegador web que alimenta o navegador do
Android.

SGL – engine de gráficos 2D.

3D libraries – uma implementação baseada nas APIs OpenGL ES 1.0; estas bibliotecas usam
aceleração de hardware 3D (quando disponível) ou o software embutido no sistema.

FreeType – renderizador de bitmap e fontes vetorizadas.

SQLite – engine leve e poderoso de banco de dados relacional para as aplicações.
3.
APPLICATION FRAMEWORK: O próximo nível é o framework de aplicação que consiste nos
programas que gerenciam as funções básicas do telefone, tais como, alocação de recursos,
aplicações de telefone, mudança entre processos ou programas e informações sobre a localização
física do aparelho. Os desenvolvedores de aplicações têm acesso total ao framework de aplicação do
Android. Isso possibilita tirar vantagem das capacidades de processamento e do suporte de recursos
do Android.
4.
APPLICATIONS: No topo da pilha estão as aplicações em si. Aqui se encontram as funções
básicas do dispositivo, como fazer chamadas telefônicas, acessar o navegador web ou
acessar sua lista de contatos. Esta é a camada do usuário comum, que utiliza a interface de
usuário. Apenas os programadores do Google, os desenvolvedores de aplicação e os
fabricantes de hardware acessam as camadas inferiores da pilha. O Android contém um
conjunto de aplicativos, implementados em Java, como um cliente de e-mail, programa para
SMS (Short Message Service), calendário, mapas, navegador e gerenciador de contatos.
6.3. Componentes de uma aplicação Android
As aplicações Android podem ser divididas em quatro tipos de componentes básicos que são definidos
pela própria arquitetura (ABLESON,2007), são eles:
6.3.1. Activities
Funcionam como mediadores que definem como as informações serão apresentadas ao usuário, além de
controlar o fluxo da aplicação. Elas podem interagir com o usuário e trocar informações com outras
activities ou services (MEIER,2009).
105
A maioria do código que escreveremos para uma aplicação Android irá executar no contexto de
uma activity. Activities normalmente correspondem a telas: cada activity mostra uma tela para o usuário.
Quando esta não está em execução, o sistema operacional pode eliminá-la para liberar memória.
6.3.1.1. Ciclo de vida de uma Activity
Ao longo de sua criação até o momento de sua eliminação da memória, uma activity atravessará seis
estados, podemos referenciar cada estado pelos métodos:
OnCreate
É chamado quando a activity é criada. Ela é obrigatória e chamada apenas uma vez, deve referenciar a tela
que será apresentada ao usuário.
OnStart
É chamado quando a activity está ficando visível e já tem uma tela definida.
OnResume
É chamado quando a activity foi parada temporariamente e está retornando à execução.
OnPause
É chamado quando a activity está sendo tirada do topo da execução. Geralmente é utilizado para salvar o
estado da aplicação.
OnStop
É chamado quando a activity não está mais visível e está em segundo plano.
OnDestroy
Executa os últimos processamentos antes da activity ser literalmente encerrada.
106
Figura 6.2. Ciclo de vida de uma Activity.
6.3.2. Services
São programas que executam em segundo plano. Não interagem diretamente com o usuário e podem ficar
executando por tempo indefinido.
6.3.3. Broadcast e Intent Receivers
São componentes que ficam aguardando a ocorrência de um determinado evento, pode-se entender como
evento a inicialização do sistema operacional, uma chamada de voz, a chegada de um SMS, um evento
disparado por uma aplicação (MEIER,2009).
Intents são elementos chave no Android, porque facilitam a criação de novas aplicações a partir
de aplicações já existentes. Precisaremos utilizar Intents para interagir com outras aplicações e serviços
que proporcionarão informações necessárias para nossa aplicação.
6.3.4. Content Providers
107
São os compartilhadores de conteúdo entre as aplicações, uma aplicação pode requisitar informações de
outra, por exemplo, uma aplicação pode receber dados da lista de contatos que é nativa do Android, e com
base nesses dados, realizar algum processamento (LECHETA,2010).
6.4. Android SDK e seus pacotes para implementação de aplicações
O SDK é um conjunto de ferramentas utilizadas para desenvolver aplicações para a plataforma Android.
Possui um emulador para simular o dispositivo móvel e uma API completa para a linguagem Java, com
todas as classes necessárias para desenvolver as aplicações (BURNETTE, 2008).
Existem atualmente três versões do SDK para atender a maior parte dos desenvolvedores: versão
para Windows, Linux e Mac OS.
O ambiente de desenvolvimento que nos utilizaremos nos exemplos seguintes é composto, além
do JDK e Android SDK, pelo Eclipse IDE versão Galileo e o Android Development Plugin (ADT), um
plugin que ajudará na integração da IDE com o emulador.
Os componentes do ambiente de desenvolvimento podem ser encontrados nos links a seguir:

JDK: http://www.oracle.com/technetwork/java/javase/downloads/index.html

Android SDK: http://developer.android.com/sdk/

Eclipse IDE: http://www.eclipse.org/downloads/

ADT: http://developer.android.com/sdk/eclipse-adt.html
6.4.1. Conceitos básicos do Android
6.4.1.1 Criando uma Activity
A classe android.app.activity é utilizada para criar uma tela na aplicação. Essa tela é composta de vários
elementos visuais, os quais no Android são representados pela classe android.view.View (LECHETA,
2010).
A classe android.view.View pode representar algo simples como um botão, um checkbox ou
imagem, como também pode representar algo complexo como um gerenciador de layout, a qual pode
conter várias views aninhadas para organizar na tela.
108
Figura 6.3. Exemplo de uma Activity.
O método setContentView(view) é o que faz a ligação entre a activity e a view e recebe como
parâmetro a view que será exibida na tela.
6.4.1.2 A classe R
A classe R é criada automaticamente pelo ADT e não pode ser alterada manualmente. Nela existem
constantes para os recursos do projeto. Cada constante é nomeada com o nome do recurso, que deve ser
escrito com letra minúscula e sem espaço, e recebe um valor inteiro.
6.4.1.3 O arquivo AndroidManifest.xml
Toda aplicação Android deve ter um arquivo AndroidManifest.xml em seu diretório raiz. Esse arquivo
apresenta informações essenciais sobre a aplicação para o sistema operacional, que deve possuir
informações do sistema antes que possa executar qualquer solicitação do código do aplicativo
(MEDNIEKS,2009).
Ele armazena informações como o nome do pacote da aplicação, descreve os componentes da
aplicação, determina qual processo da aplicação vai armazenar os componentes, declara de que formas as
solicitações devem ter permissões para acessar partes protegidas da API e interagir com outras aplicações.
Declara também as permissões que os outros processos serão obrigados a ter, fim de interagir com os
componentes da aplicação, enumera classes e perfis e fornece outras informações sobre como a aplicação
será executada, declara qual o nível mínimo da API que o aplicativo exige e enumera bibliotecas que
estarão relacionadas com a aplicação.
109
Figura 6.4. Exemplo de arquivo AndroidManifest.xml
6.4.1.4 Criação de uma interface visual
O Android fornece um sofisticado e poderoso modelo, baseado em componentes, para construir sua
interface, baseado no esquema de classes fundamentais: android.view.View e android.view.ViewGroup, e
inclui também as suas classes filhas chamadas de widgets e layouts respectivamente(LECHETA, 2010).
Podemos citar alguns exemplos de widgets como Button, TextView, EditText, ListView,
CheckBox, RadioButton, Gallery, Spinner, e outros.
Podemos citar, também, exemplos de layouts como LinearLayout, FrameLayout, RelativeLayout
entre outros.
Para exemplificar a criação da interface visual criaremos uma tela de login, a qual conterá os
campos de nome de usuário e senha, e um botão para submetê-los.
110
Figura 6.5. Representação gráfica da tela de login.
Figura 6.6. Código da tela de login
Podemos observar que foram utilizados três tipos de widgets e um layout. Dois TextView que são
utilizados para renderizar strings na tela e dois EditText que são caixas para receber texto. Foi utilizado,
também, um “Button” para enviar os dados e um LinearLayout para organizá-los na tela.
Podemos observar, também, alguns atributos como o “id” que serve como identificador de cada
componente, o text que tem o funcionamento semelhante ao value do HTML e o atributo password que
esconde os caracteres digitados no nosso EditText.
6.4.1.5 O método findViewById()
111
Ao construir uma tela usando um arquivo XML de layout, surge a necessidade de recuperar os objetos
definidos no arquivo dentro do código-fonte da aplicação para obter seus valores ou definir atributos
(LECHETA, 2010).
Podemos recuperar um objeto de visão através do seu identificador único (android:id), passando-o
como parâmetro no método findViewById(id). Esse método recebe o id do componente desejado e
retorna uma subclasse de android.view.View, como as classes Button, TextView e EditText.
Na figura a seguir é mostrado como recuperar a senha inserida pelo usuário através do método
findViewById(id) e uma pequena ajuda da classe R.
Figura 6.7. Exemplo da utilização do método findViewById()
6.4.2 Intent
Uma intent representa uma intenção da aplicação em realizar alguma ação. Ela envia uma mensagem ao
sistema operacional chamada de broadcast. Ao receber essa mensagem, o sistema operacional tomará as
decisões necessárias (LECHETA, 2010).
Uma intent é representada pela classe android.content.Intent e pode ser utilizada para enviar
uma mensagem ao sistema operacional, abrir uma nova tela da aplicação, utilizando o método
startActivity(intent), solicitar ao sistema operacional que ligue para determinado número de celular, abrir
o browser em um determinado endereço da internet, exibir algum endereço, localização ou rota no Google
Maps dentre outros.
6.4.2.1 Navegação entre telas com passagem de parâmetros
112
Existem dois métodos de se iniciar uma nova tela (activity), através dos métodos startActivity(intent) e
startActivityForResult(intent,codigo) que apenas inicia uma nova activity ou inicia uma nova activity e
cria um vínculo para ser utilizado ao retornar respectivamente (PEREIRA, 2009).
Para que o sistema operacional possa reconhecer nossa nova activity, é necessário adicionar seu
endereço no arquivo AndroidManifest.xml.
Figura 6.8. Trecho do arquivo AndroidManifest.xml que contém a nova activity.
Podemos enviar informações para outras telas através de uma intent.
6.9. Exemplo de passagem de parâmetro e troca de tela através de uma intent
Figura
Podemos observar na figura 6.9, que é criada uma intent com a activity da tela-alvo, é passado
como parâmetro através do método putExtra() o texto contido no EditText referente ao usuário para a
próxima tela, e finalmente, a nova activity é iniciada através do método startActivity(intent).
113
Figura 6.10. Código da classe SegundaTela.
Observando essa classe, vemos que a intent é capturada através do método getIntent() e
recebemos o parâmetro do login através do método getStringExtra(string). O conteúdo da tela é apenas
um TextView com uma mensagem de boas vindas.
6.4.2.2 Intents Nativas do Android
Vimos no exemplo anterior que é possível iniciar uma nova activity através das intents. O Android possui
alguns tipos de intents pré-definidas que podemos utilizar para enviar mensagens ao SO, porém, algumas
delas necessitam de permissões para executar, tais permissões precisam ser registradas no arquivo
AndroidManifest.xml (PEREIRA,2009).
Várias intents como a ACTION_VIEW, que serve para iniciar o navegador, a ACTION_CALL,
que é utilizada para realizar chamadas, a ACTION_PICK, que serve para visualizar todos os contatos,
dentre outras, são utilizadas em aplicações Android.
A seguir veremos um exemplo de como chamar o navegador através de uma intent pré-definida
no Android.
Figura 6.11. Exemplo da iniciação do navegador através de uma Intent.
O exemplo demonstra a utilização da intent ACTION_VIEW, mas, para usar essa intent é
necessária a permissão INTERNET que deve ter sido registrada previamente.
114
Figura 6.12. Inserindo a permissão INTERNET no arquivo AndroidManifest.xml
6.4.3 Intent Filter
Podemos utilizar intents para enviar mensagens ao sistema operacional, definindo uma ação que
identifique essa intent. Então quando a mensagem for enviada ao sistema operacional ela seja identificada
por essa ação, e somente uma activity que esteja mapeada para aquela ação será executada (MEDNIEKS,
2009).
Esse tipo de rotina é bem prática quando queremos que mais de um programa esteja configurado
para receber uma ação (LECHETA, 2010).
Para definir essa ação, basta criar uma Intent usando seu construtor, que recebe uma string que
identifica a ação, como, por exemplo:
Figura 6.13. Exemplo de uma chamada de ação por uma Intent.
Logicamente, alguém tem que responder por essa ação. Para isto, precisamos mapear um Intent
Filter no arquivo AndroidManifest.xml, para escutar esse chamado e delegar a execução à uma activity.
Figura 6.14. Código fonte da classe SegundaTela.
115
Figura 6.15. Exemplo de mapeamento de uma Intent Filter.
6.4.4 BroadcastReceiver
A classe BroadcastReceiver é utilizada para responder a determinados eventos enviados por uma intent.
Ela sempre é executada em segundo plano durante pouco tempo, normalmente dez segundos. Não deve
ter interface gráfica ou interação com o usuário (LECHETA, 2010).
É utilizada normalmente para executar algum processamento sem que o usuário perceba, em
segundo plano.
Assim como uma activity, devemos declará-lo no arquivo AndroidManifest.xml através da tag
<receiver>, deve ser declarada, também, um Intent Filter para o broadcast, ou podemos registrá-lo
dinâmicamente, utilizando o método registerReceiver(receiver,filtro), que tem como parâmetros uma
classe-filha de IntentReceiver e uma instância da classe IntentFilter que possui a configuração da ação e a
categoria (LECHETA, 2010).
O método para enviar uma mensagem para um broadcast é diferente do utilizado para uma intent
que chama uma activity. O método utilizado é o sendBroadcast(intent) que envia uma mensagem para
todas as aplicações instaladas no celular.
Para implementar um BroadcastReceiver deve-se extender a classe BroadcastReceiver e
implementar o método onReceive() que será executado assim que o IntentFilter receber a mensagem.
116
Figura 6.16. Utilizando o método sendBroadcast(intent).
Figura
6.17.
Exemplo de um BroadcastReceiver.
Apenas por motivos didáticos foi utilizado a classe Toast para verificar o funcionamento do
BroadcastReceiver. Recomenda-se que não tenha nenhum tipo de interação com o usuário.
117
Figura 6.18. Exemplo do mapeamento de um BroadcastReceiver.
6.4.5 Notification
A classe Notification é utilizada para exibir informações ao usuário sem que este seja interrompido se
estiver executando alguma atividade. O usuário pode escolher visualizar as informações neste momento,
ou depois (LECHETA, 2010).
A notificação é exibida na barra de status do celular para chamar a atenção do usuário. Ao ser
visualizada, a intent configurada pode uma abrir uma nova activity ou pode ser usada para iniciar um
serviço por exemplo (MEIER, 2009).
Um exemplo de notificação é a recepção de uma nova SMS, onde usuário pode decidir visualizála ou não.
Para criar uma notificação é necessário capturar um serviço do Android chamado de
NOTIFICATION_SERVICE, será necessário, também utilizar a classe PendingIntent que criará uma
intent que ficará pendente até o usuário decidir visualizar a notificação:
Figura 6.19. Exemplo da criação de uma notificação.
118
Podemos observar, que o construtor da classe Notification recebe três parâmetros: o ícone que
deverá ser exibido, o título da notificação e a hora que aparecerá do lado da notificação.
Observamos, também, que deve-se informar através do método setLatestEventInfo, a mensagem
que aparecerá na barra de status assim que a notificação for reconhecida pelo serviço de notificações do
android, o título da notificação e a intent que deverá ser chamada quando o usuário visualizar a
notificação.
Figura 6.20. Classe que será instanciada quando a notificação for visualizada.
A figura anterior mostra a classe que será instanciada quando o usuário visualizar a notificação.
Capturamos o serviço de notificações do android, e pedimos para que a notificação não apareça mais na
barra de status através do método cancel(int) que recebe como parâmetro o id da notificação.
6.4.6 Service
Têm as mesmas características dos serviços dos sistemas operacionais de computador.
São utilizados quando queremos executar algo por tempo indeterminado em segundo plano e que
exija um alto consumo de recursos, memória e CPU (LECHETA, 2010).
Geralmente são iniciados por um BroadcastReceiver para executar algum processamento
demorado, pois um BroadcasReceiver tem um tempo determinado para executar (PEREIRA, 2009).
É interessante que os serviços tenham suas próprias threads para que fiquem independentes do
programa hospedeiro. Eles também possuem um ciclo de vida próprio, semelhante ao de uma Activity,
mas possuem apenas três estágios: o onCreate, onStart e onDestroy, que desempenham o mesmo papel
que o de uma Activity.
119
Para iniciar um serviço é necessário criar uma activity que chame o método startService(intent).
Para parar um serviço existem duas maneiras: a primeira é chamar o método stopService(intent), a mesma
intent utilizada para iniciar o serviço deve ser usada para pará-lo, e a segunda forma é o próprio serviço
chamar o método stopSelf().
Figura 6.21. Chamando um serviço.
Para implementar um serviço é necessário estender a classe android.
120
Figura 6.22. Exemplo de um serviço.
Para exemplificar o funcionamento de um serviço, utilizamos esta classe, que quando iniciada,
cria uma série de logs. Podemos observar que mesmo fechando a aplicação que iniciou o serviço, ele
continua criando logs até chamar o método stopSelf().
121
É necessário mapear o serviço no arquivo AndroidManifest.xml e configurar um IntentFilter com
a ação que iremos passar como parâmetro pela nossa Intent.
Figura 6.23. Exemplo do mapeamento de um serviço.
6.4.7 AlarmManager
São eventos agendados no sistema operacional para serem executados no futuro (LECHETA, 2010).
É utilizado quando é necessário executar algo uma vez em determinado horário ou ficar repetindo
de tempos em tempos.
Quando agendados, ficam ativos no sistema até que sejam explicitamente cancelados, ou o
sistema for reiniciado.
Para agendar um alarme, primeiro temos que definir uma intent com o BroadcastReceiver que irá
responder pelo nosso alarme. Depois temos que capturar o serviço do Android responsável pelo
gerenciamento dos alarmes, o AlarmManager.
122
Figura 6.24. Agendando um alarme.
Figura 6.25. BroadcastReceiver que será chamado pelo nosso alarme.
6.5. Arquitetura REST de desenvolvimento de aplicações Web
Vivemos hoje uma febre de Apps – pequenos aplicativos auto-contidos que tem uma única função e
comumente são interfaces para sistemas Web. A maioria desses aplicativos é extremamente dependente
de dados para serem úteis e esses dados podem vir dos mais variados lugares – por exemplo, a plataforma
123
Android disponibiliza ao desenvolvedor uma pequena base dados SQLite onde ele pode criar suas tabelas,
armazenar e buscar dados, mas cada vez mais esses dados vêm de serviços web.
A Web é uma plataforma “orientada a recursos”. Um Recurso pode ser definido como qualquer
coisa que é exposta a Web através de um identificador e que possamos manipular (ler e/ou escrever)
(WEBBER; PARASTATIDIS, 2010)..
Desde sua formalização REST2 vem sendo um termo e, mais adequadamente, uma arquitetura de
software de sistemas Web cada vez mais utilizado, estudado e discutido. Esta arquitetura foi proposta pelo
Dr. Roy T. Fielding em 2000 e desde então vem sendo adotada em vários sistemas de grande porte como
Twitter, Facebook, Flickr e todas as APIs de serviços públicos do Google como Google Agenda, Google
Health, Google Data e Google Maps.
Veremos a seguir o que é REST e, em seguida, formas de se trabalhar com REST em Java.
6.5.1 Definição
O protocolo HTTP, e consequentemente servidores HTTP, é um protocolo simples e sem muitos recursos.
Em sua primeira versão ele apresentou endereçamento e statelessness: duas características de seu projeto
que o tornou um avanço perante seus rivais e que ainda o mantém escalável mesmo nos mega-sites de
hoje (RICHARDSON; RUBY, 2007).
Sistemas com esta arquitetura são sistemas Clientes-Servidores comuns, entretanto suas
requisições e respostas são construídas ao redor da transferência da representação de recursos. Recursos
são os blocos fundamentais de sistemas baseados na web, ao ponto que a Web é considerada como
“orientada a recursos” (WEBBER; PARASTATIDIS, 2010). A abstração chave de informação do REST
são os recursos. Qualquer informação que pode ser nomeada pode ser um recurso: documentos, imagens,
informações sobre o tempo, uma pessoa, e assim sucessivamente (FIELDING, 2000). Um dos recursos
mais comuns da Web são páginas HTML, que em sistemas são comumente a representação de um recurso
interno do sistema, por exemplo, uma página de exibição de um vídeo do YouTube é a representação do
recurso “vídeo” do sistema.
Um mesmo recurso pode ter várias representações diferentes. Utilizando o exemplo do vídeo do
YouTube, uma representação é a página HTML onde é mostrado o vídeo, comentários, etc. outra
representação é vista quando o vídeo é incorporado em outra página. Nessa representação vemos apenas
um player que carrega o vídeo em questão. Outra representação, um pouco menos conhecida, é a
representação em XML3 ou mais recentemente JSON4, ambas tecnologias de transição de dados
hierárquicos.
Devido a essas características REST também requer que as aplicações façam total distinção entre
cliente e servidor através da implementação das seguintes características:
2
Representational State Transfer – Transferência de Estado Representacional
3
XML – eXtensible Markup Language – Linguagem de marcação extensível.
4
JavaScript Object Notation – Notação de Objetos JavaScript.
124
1.
Cliente-Servidor: Clientes são separados dos Servidores por uma interface uniforme. Essa divisão
faz com que o cliente não se preocupe com, por exemplo, armazenamento de dados ao passo que o
servidor não se preocupa com interface com o usuário;
2.
Stateless (Sem Estado): A comunicação cliente-servidor ocorre sem que nenhum contexto relativo
ao cliente seja armazenado no servidor entre as requisições. Cada requisição de cada cliente contém
toda informação necessária para atender aquela requisição e a reposta deve conter toda a
informação para satisfazer a requisição;
3.
Cache: Como é comum na Web, o cliente pode manter um cache das respostas do servidor,
portanto é recomendado que as respostas contenham informações sobre se podem e como deve ser
feito o cache a fim de evitar que clientes requisitem um mesmo recurso repetidamente. Um bom
cache elimina várias interações cliente-servidor desnecessárias o que proporciona escalabilidade e
performance;
4.
Camadas: Um cliente não pode normalmente distinguir se ele está ou não conectado ao servidor
final ou apenas a um intermediário. Um sistema com vários servidores permite o balanceamento de
carga, caches compartilhados e ajudam a manter uma boa segurança;
5.
Código sob demanda (opcional): Servidores podem ser capazes de estender a funcionalidade de
um cliente transferindo lógica para que ele execute. Exemplos disso são componentes compilados
como Applets Java ou scripts no lado cliente como JavaScript;
6.
Interface uniforme: Todo cliente obedece ao mesmo formato de requisição e recebe o mesmo
formato de resposta.
A arquitetura REST está fundamentada sob o protocolo HTTP e seus métodos. Clientes que
acessam recursos informando sua intenção através do método que executam sob o recurso. A maioria dos
sistemas hoje em dia segue a seguinte convenção de métodos HTTP, concebidos para simular operações
de CRUD:

GET: Leitura;

POST: Escrita;

PUT: Alteração ou Atualização;

DELETE: Remoção.
Muitas aplicações novas estão utilizando os princípios REST a fim de obterem um bom nível de
escalabilidade. Normalmente essas aplicações disponibilizam a seus usuários uma API dos métodos
REST disponíveis, suas entradas e suas saídas.
Para compreender melhor, vejamos a API de um sistema referência em tecnologia REST: o
Twitter.
O Twitter disponibiliza em seu website uma extensa e detalhada documentação da API de seu
sistema . uma plataforma de apoio aos desenvolvedores que desejam criar clientes para o Twitter com
5
5
Disponível em http://dev.twitter.com/ - Acesso em 12 outubro 2011
125
páginas de ajuda onde são descritos os métodos da API, um guia ao desenvolvedor e ferramentas para
ajudá-lo.
Chamadas a alguns métodos da API podem ser feitas, para testes, através de um navegador web
qualquer.
Durante a escrita deste texto, a API do Twitter aceita a seguinte chamada:
http://api.twitter.com/1/users/show.xml?screen_name=fat. Para chamar este
método da API basta abrir esta URL em qualquer navegador web.
Ao abrir esta URL em um navegador, o que é feito é uma chamada a API através do método
HTTP GET. Chamadas a qualquer API REST na Web são compostas de 3 partes:
1.
A URL correspondente ao método da API
 http://api.twitter.com/1/users/show
2.
Os parâmetros da chamada ao método
 screen_name = fat
3.
O método HTTP utilizado para chamada aquela URL
 Por padrão, toda transação HTTP dos navegadores atuais utiliza o método GET.
A URL é uma chamada ao método “1/users/show” da API do Twitter. Uma particularidade dessa
API é a possibilidade de escolha do formato de representação do recurso: XML ou JSON, representado
pela “extensão do arquivo” na URL.
6.5.2. REST em Java
Em Java chamadas a APIs REST são feitas utilizando chamadas HTTP simples, normalmente com
objetos java.net.URL e java.net.HttpURLConnection. Nos exemplos a seguir utilizaremos a
API do Twitter como exemplo.
A forma mais simples de se executar uma chamada é a seguinte:
String apiCall = "<url de chamada a API>";
URL url = new URL(apiCall);
HttpURLConnection conn;
conn = (HttpURLConnection) url.openConnection();
Ao invocar o método openConnection() uma requisição HTTP GET é feita a URL
especificada em apiCall. Após essa chamada, é importante verificar o código de resposta dado pelo
126
servidor. Normalmente um código de resposta 200 significa que tudo ocorreu como esperado. Outros
códigos de resposta podem ser especificados pela API.
if (conn.getResponseCode() == 200) {
// Tudo ocorreu como esperado.
}
Dessa forma podemos tomar alguma providência caso ocorra algum erro, e garantir um bom
funcionamento da aplicação.
Após a confirmação do sucesso da chamada o próximo passo é ler os dados da resposta do
servidor. É necessário um cuidado especial com o tipo de dado esperado pois a resposta da API pode ser
uma imagem, ou um documento, ou até mesmo um Stream de dados. Vamos considerar que a resposta a
nossa chamada está em formato textual, caso qual podemos utilizar a seguinte técnica para captar o
resultado num formato mais cômodo para manipulação:
BufferedReader reader = new BufferedReader(new
InputStreamReader(conn.getInputStream()));
StringBuilder str = new StringBuilder();
String line;
while ((line = reader.readLine()) != null) {
str.append(line);
}
reader.close();
Após o recebimento da resposta, é uma boa prática sempre fechar a conexão junto ao servidor
invocando o método disconnect():
conn.disconnect();
Dessa forma podemos fazer chamadas a quaisquer API REST utilizando Java.
6.5.2.1 Interpretando Respostas
Em Java podemos quase sempre considerar um recurso disponibilizado pelo servidor com um Objeto.
Comumente recebemos respostas em XML o qual é uma serialização de um objeto que está no servidor.
Devido a isso um ponto que requer especial atenção é a interpretação das respostas. APIs REST
utilizam representações do estado de um recurso (um Objeto) do sistema. Nestes casos a forma mais
comum de representação é textual, segundo um padrão determinado pela API, XML ou JSON.
127
Existem várias bibliotecas disponíveis para se trabalhar com os formatos XML e JSON, algumas
bastante sofisticadas e simples de usar. Para XML temos, por exemplo, uma biblioteca chamada jDOM6
que interpreta XML e dá ao desenvolvedor uma representação do documento XML na forma de um grafo
de objetos com uma interface nativa Java que podem ser facilmente percorridos e manipulados. Para
JSON há uma biblioteca chamada Gson7 disponibilizada pelo Google que pode transformar Objetos Java
em sua representação JSON e vice-versa:
Gson gson = new Gson();
String json = gson.toJson(meuObjeto);
MeuObjeto obj = gson.fromJson(json, MeuObjeto.class);
Através do uso de bibliotecas auxiliares é possível criar objetos concretos Java a partir de
representações textuais dos mesmos.
A utilização de JSON é recomendada nestes casos pois grande parte dos sistemas REST atuais
são voltados para a interatividade entre sistemas de Websites, os quais são em sua maioria feitos
utilizando JavaScript, linguagem-mãe da notação JSON e que dá suporte nativo a interpretação e
construção de objetos a partir de sua representação textual e vice-versa.
Referências
ABLESON, W. Frank; Unlocking Android - A Developer’s Guide. Ed. Manning, 2007.
BURNETTE, Ed.Hello, Android:Introducing Google`s Mobile Development Plataform. Pragmatic
Bookshelf, 2008.
Google Android. Disponível em <http://developer.android.com/guide/basics/what-is-android.html>.
Acesso em 12 outubro 2011.
LECHETA, Ricardo R. Google Android. São Paulo: Novatec, 2010, 2 ª ed.
MEDNIEKS, Zigurd; MEIKE, Blake. Desenvolvimento de Aplicações Android. São Paulo: Novatec,
2009, 1ª ed.
MEIER, Reto. Professional Android Application Development. Indianapolis: Wiley Publishing, 2009, 1ª.
ed.
PEREIRA, Lúcio C. Oliva. Android para Desenvolvedores. São Paulo: Brasport, 2009, 1ª ed.
WEBBER, Jim; PARASTATIDIS, Savas; ROBINSON Ian. REST in Practice: Hypermidia and Systems
Architecture. O’Reilly Media, 2010.
6
http://www.jdom.org/ - Acesso em 12 outubro 2011
7
http://code.google.com/p/google-gson/ - Acesso em 12 outubro 2011
128
RICHARDSON, Leonard; RUBY Sam. RESTful web services. O’Reilly Media, 2007.
FIELDING, Roy; Architectural Styles and the Design of Network-based Software Architectures.
Dissertação de Doutorado, University of California, 2000.
129
Desenvolvimento de um Museu Virtual 3D
Utilizando Agentes Inteligentes
Í. Moura, F. Mendes Neto, P. Sousa e J. Lima
Resumo— Ambientes virtuais de aprendizagem em 3D
proporcionam uma experiência educacional com grande riqueza
de detalhes, sensação de imersão e interação com diversos
recursos educacionais. Um museu virtual, a partir de sua
plataforma virtual em 3D e dos recursos que esta plataforma
pode oferecer, funciona como uma ferramenta educacional
eficiente, pois disponibiliza informação aos seus visitantes de
forma simples e de fácil compreensão. No entanto, uma limitação
do uso de museus virtuais para a aprendizagem é que estes
ambientes não levam em consideração as características
individuais e contextuais dos visitantes, limitando sua
aprendizagem. Assim, este artigo apresenta um museu virtual em
3D denominado Musert, que tem como diferencial a
recomendação personalizada de conteúdo. Para isso, utiliza
ontologias juntamente com agentes inteligentes para realizar a
recomendação personalizada de conteúdo de forma satisfatória. 
Palavras-chave— Museu 3D, padrão X3D, browser Xj3D e
recomendação personalizada de conteúdo.
Abstract— virtual learning environments provide an
educational experience with great detail, sense of immersion and
interaction with various educational resources. A virtual
museum, from its 3D virtual platform and resources that can
offer this platform, works as an effective educational tool as it
provides information to its visitors in a simple and easy to
understand. However, a limitation of the use of virtual museums
to learn is that these environments do not take into account the
individual and contextual characteristics of visitors, limiting their
learning. Thus, this paper presents a 3D virtual museum named
Musert,
whose
differential
is
personalized
content
recommendation. It uses ontologies along with intelligent agents
to perform personalized content recommendation satisfactorily.
Keywords— 3D museum, X3D standard, Xj3D browser and
content personalized recommendation.
I. INTRODUÇÃO.
A
grande disponibilidade de computadores, tanto em
escolas como nas residências e a facilidade de acesso a
internet tem influenciado a utilização de recursos tecnológicos
com o propósito de promover educação. Nos últimos anos,
devido à facilidade de acesso a esses recursos, museus virtuais
tem sido cada vez mais utilizados para fins educacionais. Um
Í. Moura, Programa de Pós-Graduação em Cinência da Computação –
PPgCC, Universidade do Estado do Rio Grande do Norte e Universidade
Federal Rural do Semi-Árido, Mossoró-RN, Brasil, [email protected]
F. Mendes Neto, Universidade Federal Rural do Semi-Árido, MossoróRN, Brasil, [email protected]
P. Sousa, Universidade Federal Rural do Semi-Árido, Mossoró-RN,
Brasil, [email protected]
J. Lima, Universidade do Estado do Rio Grande do Norte, Mossoró-RN,
museu virtual é um sistema complexo, com uma gama de
possibilidades para os usuários e por isso, tem mostrado ser
eficaz em uma série de projetos de ensino e estão sendo
usados para facilitar o processo educacional de maneira
diferente da convencional.
A busca por alternativas para suprir a necessidade de
preservação do patrimônio histórico e cultural de uma região
são cada vez maiores, visto que este patrimônio é fundamental
para a educação e contribui significativamente na definição da
identidade cultural. Entretanto, apesar de sua relevância, uma
série de artefatos e documentos de valor histórico imensurável
têm sido perdidos ao longo do tempo devido à deficiência de
recursos e técnicas de preservação que não conseguem evoluir
com uma rapidez que evite tais perdas. Isto ocasiona prejuízos
imensuráveis, provocados por diversos fatores, como tempo,
manuseio e armazenamento inadequados [1]. Uma dessas
alternativas é a utilização de técnicas de digitalização em três
dimensões (3D) em projetos com grande apelo visual. A
digitalização em 3D pode ser utilizada para preservar bens do
patrimônio histórico e cultural em seus mínimos detalhes de
forma segura, permitindo a construção de réplicas, mesmo
quando o original não existe mais, bem como a criação de
coleções virtuais acessíveis através da Internet [2].
Diante disso, é cada vez mais comum a utilização de
conteúdo em 3D em Ambientes Virtuais de Aprendizagem
(AVA), devido ao seu poder de promoção de sensação de
imersão e disponibilidade de recursos visuais e educacionais.
Mas, devido à riqueza de detalhes que as técnicas de
digitalização em 3D proporcionam e da grande carga
informacional que ambientes virtuais podem oferecer, em
muitas situações os usuários são incapazes de identificar as
suas reais necessidades de aquisição de informação na
presença de uma grande quantidade de dados que lhes são
disponibilizados [3]. Na tentativa de resolver este problema,
uma das formas encontradas é o armazenamento do perfil dos
usuários e das atividades realizadas nos ambientes virtuais,
que pode ser realizado com o uso de ontologias, e atualização
dinâmica destas informações, que pode ser feita por agentes
inteligentes. A utilização de ontologias como meio de
armazenamento de informações se torna interessante pelo fato
de permitir uma melhor compreensão dos dados por parte de
computadores, oferecendo uma maior precisão dos resultados
que são retornados. Além disso, devido à sua forma de
representação do conhecimento, a utilização de ontologias
permite a comunicação eficiente entre pessoas, agentes de
software e sistemas e promove muitas outras vantagens em
relação aos mecanismos convencionais de armazenamento de
dados [4] [5].
Com o propósito de superar estes desafios, este artigo
130
apresenta um AVA na forma de um museu virtual,
denominado Musert, que utiliza tecnologias como o padrão
X3D, o browser Xj3D e técnicas de modelagem específicas
para o desenvolvimento do museu e das peças que o compõe.
Além disso, mostra como a utilização de agentes de software e
ontologias pode promover a recomendação personalizada de
conteúdos do acervo levando em consideração as
características do perfil de cada visitante, além de monitorar as
atividades do visitante no ambiente virtual.
Assim, este trabalho está dividido em seis seções. A Seção
2 mostra os trabalhos relacionados e apresenta uma breve
comparação entre estes trabalhos e o proposta descrita neste
artigo. A Seção 3 traz conceitos relacionados a ambientes
virtuais de aprendizagem e a utilização de técnicas de
realidade virtual e aumentada neste tipo de ambiente. A Seção
4 aborda os conceitos e benefícios da utilização de ontologias
juntamente com a utilização de agentes inteligentes na
recomendação personalizada de conteúdos. A Seção 5
descreve a abordagem proposta neste artigo, que é o
desenvolvimento de um museu virtual 3D com recomendação
personalizada de conteúdo, e também apresenta as
características e as etapas de modelagem e implementação do
museu. Já a última seção apresenta as considerações finas e
uma breve discussão sobre trabalhos futuros.
II. TRABALHOS RELACIONADOS.
No trabalho descrito em [6], é relatado o desenvolvimento
de um framework para a modularização de um sistema de
gerenciamento de conteúdo em museus virtuais no ambiente
Second Life [7]. A principal questão é como gerenciar grandes
quantidades de informações de um museu e disponibilizar de
forma personalizada a informação apropriada para cada
visitante deste museu. Com este propósito foi desenvolvido
este framework que consiste em dois subsistemas e seis
módulos, que são relacionados com o conteúdo a ser
apresentado pelo museu e os perfis dos visitantes. As visitas e
interação com o museu são o foco do framework, e
proporciona a personalização do conteúdo disponibilizado aos
usuários durante as visitas pelo museu. Para que o framework
desenvolvido obtivesse o sucesso desejado foram adotadas
técnicas já existentes e já utilizadas em sistemas baseados na
Web e sistemas de recomendação. No entanto, estas técnicas
ainda precisam ser devidamente ajustadas, e esta tarefa foi
deixada como trabalho futuro.
No trabalho apresentado em [8], é descrito um museu
virtual imersivo, interativo e itinerante, denominado Museu 3I.
Este museu tem como principal característica a possibilidade
do visitante escolher quais obras deseja visitar. Outro fator
importante é a possibilidade de que qualquer pessoa possa ser
um curador do museu, sendo necessário apenas o envio de
uma peça, modelada tridimensionalmente e que esteja no
formato X3D, para o acervo do museu através do browser
Xj3D, que já é nativo da aplicação. Além disto, o museu
oferece uma interface gráfica em 3D e paralelamente são
apresentados menus no qual o visitante poderá selecionar as
funcionalidades que mais lhe interessam.
Outro trabalho tem como abordagem principal o
desenvolvimento de AVAs que utilizam recursos em 3D e que
tem como objetivo principal acrescentar riqueza de detalhes na
apresentação de conteúdo aos usuários. Desta forma, o
trabalho apresentado por [9] mostra os aspectos de um museu
virtual que tem como proposta a preservação de artefatos
históricos através da utilização de recursos multimídia. Para
isto, utiliza a narração digital do conteúdo apresentado, além
de utilizar técnicas de realidade virtual e levar em
considerações informações dos usuários e curadores para
melhorar visualização das peças.
Desta forma, em comparação aos trabalhos descritos acima,
este trabalho apresentará nas seções seguintes as
características de um museu virtual 3D com recomendação
personalizada de conteúdo. Para alcançar este objetivo foram
utilizadas diversas tecnologias, dentre elas o padrão X3D, o
browser Xj3D e a linguagem de programação Java no módulo
referente à visualização em três dimensões do museu. Já no
módulo de recomendação personalizada de conteúdo, foram
utilizados agentes inteligentes, ontologias e técnicas de
recomendação de conteúdo. Com base nisso, a utilização do
padrão X3D e do browser Xj3D em relação à utilização de
mundos virtuais como Second Life, se deve ao fato da fácil
interação entre estas tecnologias juntamente com ontologias e
agentes inteligentes para se alcançar o objetivo deste trabalho
que é a recomendação personalizada de conteúdo em
ambientes virtuais em 3D. Assim, os detalhes, desafios e
resultados alcançados são apresentados nas próximas seções.
III. AMBIENTES VIRTUAIS DE APRENDIZAGEM.
AVAs podem ser conceituados como sistemas de software
que facilitam os processos de aprendizado individual ou
coletivo, utilizando para isso meios eletrônicos [10]. Eles
precisam basicamente da internet e fornecem muitas funções
gerenciais, como, por exemplo, gestão do material
educacional, além do acompanhamento e avaliação da
aprendizagem dos alunos [10]. Desta forma, um ambiente
virtual pode ser entendido como um espaço virtual que tem o
poder de representar uma metáfora do mundo real [11].
Além disso, as simulações interativas disponibilizadas por
ambientes virtuais podem desempenhar um papel significativo
na facilitação da aprendizagem através do envolvimento dos
alunos, pois fornecem contextos do mundo real [12].
A. AVAs com Recursos de Realidade Virtual e Aumentada
A criação de ambientes virtuais 3D, para a representação de
AVAs, permite fantasiar sobre infinitas possibilidades para a
criação de ambientes que não podem existir fisicamente, ou
que, por algum impedimento, não podem disponibilizar todos
os recursos desejáveis fisicamente. Com isso, os AVAs 3D
permitem o surgimento de muitas ideias inovadoras para a
construção de personagens (avatares) e desenho arquitetônico
de edifícios com fins educacionais. Além disso, a ausência de
restrições físicas no desenvolvimento deste tipo de ambiente é
bastante significativa em relação às dificuldades encontradas
na construção de ambientes reais. Em AVAs 3D não existem
as restrições da vida real, como restrições orçamentárias,
testes de solo, limitações dos materiais, requisitos de
infraestrutura, som ou até mesmo a gravidade. Assim, um
simples procedimento 3D pode, por exemplo, transformar e
131
enriquecer cores de paredes envelhecidas e melhorar tristes
estilos arquitetônicos [13].
B. Museus Virtuais
A popularidade dos ambientes virtuais na web permite o
uso deste tipo de sistema para muitas aplicações, dentre elas a
educação. Seguindo esta evolução, o desenvolvimento de
museus virtuais tem avançado muito nos últimos anos e isso
tem facilitado a disponibilização das peças aos visitantes.
Além disso, outro fator de destaque é o poder de
representatividade que este tipo de ambiente possui, podendo
ocorrer através de diferentes tipos de mídias, tais como texto,
imagem, áudio, vídeo, e outros tipos de dados mais
complexos, como, por exemplo, objetos que usam técnicas de
modelagem em 3D [11].
Um museu virtual pode ser caracterizado como uma
coleção de artefatos eletrônicos e recursos informativos
disponibilizados de forma digital. Uma das vantagens que um
museu virtual pode apresentar, em relação aos tradicionais, é a
reprodução digital de objetos reais, que ainda existem ou não,
oferecendo a possibilidade de observar e interagir com as
obras de arte, pertencentes ao museu virtual, que estão
localizadas em outro lugar físico [14]. Outra vantagem é a
possibilidade de disponibilizar diversos recursos multimídia,
como textos, dados, gráficos e recursos de animação,
enriquecendo ainda mais uma visita ao ambiente virtual [15].
Um museu virtual, a partir da utilização de tecnologias de
realidade virtual juntamente com todos os outros recursos,
funciona como uma ferramenta educacional eficiente, pois
disponibiliza informação aos usuários de forma simples e de
fácil compreensão [16].
Mas, mesmo diante de tantos recursos, pesquisadores
concluem que um AVA não pode substituir a interação entre
aluno e professor. Um problema que ocorre na maioria dos
AVAs é que o conteúdo é passado para todos os alunos da
mesma forma e não muda de acordo com as necessidades de
cada um [1].
Assim, nos últimos anos, pesquisadores têm tentado
modificar este comportamento passivo e têm apresentado uma
série de práticas e tecnologias inovadoras para se chegar a
uma nova geração de AVAs, onde é possível ter habilidades
de interatividade reais e participação no processo de
aprendizagem [17] [18]. Desta forma, este trabalho apresenta
uma alternativa para que recomendação de conteúdo seja
realizada de forma satisfatória.
IV. RECOMENDAÇÃO DE CONTEÚDO COM UTILIZAÇÃO DE
AGENTES INTELIGENTES E ONTOLOGIAS.
Atualmente, há um crescimento exponencial das fontes de
dados e este fato torna a aquisição de conhecimento cada vez
mais complicada devido à dificuldade que os usuários têm no
momento de identificar as suas reais necessidades de
informação [3] [19].
A. Agentes Inteligentes
Agentes inteligentes podem realizar diversas tarefas em um
AVA, tais como monitorar as atividades do usuário, capturar
de forma automática suas informações contextuais, como, por
exemplo, a preferência por um determinado tipo de conteúdo e
frequência de utilização dos recursos, além de realizar a
recomendação personalizada de conteúdo educacional [20].
Seguindo esta linha, agentes inteligentes com características
pedagógicas (AICPs), além das características de um agente
convencional, têm como foco o alcance de objetivos que
melhorem o aprendizado dos usuários de AVAs. Devido à esta
característica, eles têm sido utilizados como tutores, utilizando
modelos cognitivos dos usuários, além de proporcionarem um
suporte para a aprendizagem personalizada [21]. Atualmente,
há um esforço considerável no emprego de AICPs em
ambientes tradicionais de aprendizagem. Isto se deve,
principalmente, ao potencial destes agentes para proporcionar
um aprendizado com uma maior riqueza de recursos e à
exploração das habilidades sociais dos agentes, que podem
proporcionar vários cenários de aprendizagem úteis para a
colaboração no AVA [22].
Com base nisto, um sistema computacional em que dois ou
mais agentes interagem ou trabalham em conjunto de forma a
desempenhar determinadas tarefas ou satisfazer um conjunto
de objetivos é considerado um sistema multiagente. A
investigação científica e a implementação prática de sistemas
multiagente está focada na construção de padrões, princípios e
modelos que permitam a criação de pequenas ou grandes
sociedades de agentes capazes de interagir convenientemente
de forma a atingirem os seus objetivos. Estes agentes exibem
duas características fundamentais, a primeira é a capacidade
de agirem de forma autônoma tomando decisões que levem à
satisfação dos seus objetivos, a segunda apresenta a
capacidade de interagirem com outros agentes utilizando
protocolos de interação social inspirados nos humanos e
incluindo pelo menos uma das funcionalidades como
coordenação, cooperação, competição e negociação [23].
Cada agente trabalha como um elemento capaz de resolver
problemas de forma autônoma e que coopera com outros
agentes. Para que um agente possa operar como parte do
sistema, é necessária a existência de uma infra-estrutura que
permita a comunicação ou interação entre os agentes que
compõem o sistema [24].
Juntamente com agentes de software, ontologias podem ser
utilizadas com diversas finalidades em AVAs, sendo uma das
suas principais aplicações é a personalização, utilizando para
isso as características específicas do perfil de cada usuário
[25].
B. Ontologias
Ontologias têm sido amplamente utilizadas em áreas como
Engenharia do Conhecimento, Engenharia de Software, Web
Semântica e muitas outras áreas da indústria da informação
[25].
Neste trabalho, foi utilizada a OWL (Web Ontology
Language), que tem sido pesquisada e desenvolvida pela W3C
(World Wide Web Consortium). Esta linguagem é baseada no
esquema XML, e é amplamente utilizado para descrever a
ontologias. Os desenvolvedores e os pesquisadores criaram
três tipos de sub-linguagens para atender diferentes tipos de
necessidades. Elas são OWL Lite, OWL DL e OWL Full, e a
capacidade de expressão dessas três sub-línguagens é
crescente. Neste trabalho está sendo utilizada a sub-linguagem
OWL DL (Description Logic), que visa atender aos usuários
que necessitam de forte capacidade descritiva para a realização
132
de inferência pela ontologia. Esta sub-linguagem contém todos
os elementos da OWL [26].
Ao longo das últimas décadas, as organizações têm aplicado
grandes esforços na criação e manutenção de modelos de
dados para suportar aplicações de negócios. Embora diferentes
tipos de modelos de dados existentes hoje como, por exemplo,
relacional, objeto-relacional, orientado a objetos e hierárquico,
o seu principal princípio permanece o mesmo: um modelo de
dados captura ambos os principais elementos de dados em
uma área de assunto e as características desses elementos de
dados.
Sabendo que tanto os modelos de dados como ontologias
podem capturar informações semelhantes, o que os difere é a
forma como esta informação é codificada e a extensão a qual é
expressa. Atualmente, vários métodos têm sido desenvolvidos
para gerar ontologias a partir de modelos de dados já
existentes. Além disso, existem outras características que as
diferem bastante [27].
O objetivo da utilização de ontologias é a modelagem de
domínios levando em consideração as relações e conceitos
semânticos com uma alta expressividade. Já a utilização de
banco de dados é determinada pela modelagem de dados
levando em consideração apenas a sua estrutura, ou seja,
tabelas. Adicionado a estes fatores, tem-se que as ontologias
podem ser utilizadas independentemente de aplicação e em
contextos variáveis [28].
Atualmente AVAs armazenam, através da utilização de
banco de dados, uma grande quantidade de materiais de
ensino. Mas devido a este caráter de armazenamento, estes
materiais possuem pouca expressividade semântica. Desta
forma, um repositório de materiais didáticos baseado na
utilização de ontologias fornece uma partilha global através de
um vocabulário dos conceitos no domínio de ensino. Além
disso, a utilização de uma grande quantidade de materiais de
ensino pode tornar difícil a busca e compartilhamento de
conhecimento a partir das demandas de ensino e aprendizagem
em AVAs.
A utilização de AVAs pode não só apoiar o ensino e a
aprendizagem pela web, mas também consegue partilhar de
forma efetiva conhecimento e oferece uma gestão
personalizada para cada usuário [29].
Desta forma, pode-se destacar que uma das principais
características de uma ontologia é a possibilidade de
comunicação entre pessoas, agentes e sistemas, já que a
ontologia permite o reuso, a representação formal de conceitos
e o compartilhamento de conhecimentos [30].
Devido aos avanços da web semântica e a utilização de
ontologias, problemas como armazenamento, organização,
compartilhamento e reutilização de informações de forma
eficiente podem ser superados. O uso de ontologias para
descrever objetos de aprendizagem permite que diferentes
aplicações educacionais compartilhem e reutilizem os mesmos
conteúdos educacionais. Além disso, a capacidade de leitura
de uma ontologia pelos computadores aumenta a velocidade
de consulta às informações compartilhadas e a precisão dos
resultados que são retornados [4].
Com isso, diante das vantagens que as ontologias possuem,
neste trabalho foram utilizadas ontologias para armazenar
todas as informações dos perfis dos usuários, as descrições das
peças a serem recomendadas e as informações que
influenciam dinamicamente o comportamento da aplicação.
V. MUSERT.
Nesta seção são apresentadas as principais características do
museu virtual proposto neste artigo. A seguir são apresentados
os detalhes referentes à arquitetura da proposta juntamente
com as técnicas e tecnologias que juntas, viabilizam a
recomendação personalizada de conteúdo.
A. Arquitetura do Museu Virtual
Este trabalho tem como diferencial a personalização de
conteúdo em um museu virtual denominado Musert, tendo
como base para isso, ontologias e AICPs. A ideia principal
desta abordagem é identificar os requisitos do usuário, ou seja,
suas preferências e suas características, e criar um modelo
deste usuário. Nesse modelo deve constar o seu conhecimento
expresso por meio de um conjunto de termos pertencentes a
uma ontologia comum, possibilitando adaptar o conteúdo de
forma individual. A arquitetura desta proposta pode ser
visualizada na Figura 1, onde são representados os AIPCs,
ontologias e a interação dos usuários com o museu.
133
Figura 1. Arquitetura do museu virtual e utilização de agentes de software e ontologias na disponibilização personalizada de conteúdo.
Como pode ser visto na Figura 1, é possível perceber que
inicialmente há a autenticação do visitante junto ao museu.
Após esta autenticação, a visualização das descrições das
peças é acionada a partir da aproximação do visitante aos
sensores das peças, que ficam localizados em locais prédeterminados do museu. Antes disto, no entanto, o visitante
precisa realizar um cadastro para que suas características
pessoais sejam armazenadas na ontologia de contexto estático,
que contém informações como, por exemplo, nome, idade e
escolaridade. Além desta ontologia, há a ontologia de contexto
dinâmico, que é responsável por armazenar informações como
quantidade de visitas, peças visitadas, dentre outras
informações de caráter dinâmico que representam a interação
do visitante com o ambiente virtual.
B. Agentes de Software com Características Pedagógicas
Na abordagem proposta foram implementados quatro
agentes: Agente de Navegação (BAg - Browsing Agent),
Agente Usuário (UAg - User Agent), Agente Recomendador
(RAg - Recommender Agent) e o agente DF (Diretory
Facilitator). Cada agente tem um objetivo específico, mas se
relacionam com os demais para alcançar o objetivo principal,
que é a recomendação personalizada de conteúdo.
O UAg é responsável por monitorar as atividades dos
visitantes e recuperar, das ontologias de contexto estático e
dinâmico, as preferências de conteúdo que compõem os perﬁs
dos visitantes e os seus respectivos históricos de peças
visitadas. Com base no histórico de visitas, o UAg pode
verificar o perfil de outros visitantes que possuem, em seus
históricos, preferências similares. Os UAgs também capturam
as informações do contexto dinâmico do estudante. Para isso,
o UAg realiza sua ação no momento em que o estudante se
autentica na aplicação. Em seguida, todas essas informações
são cadastradas no agente DF.
O RAg tem como propósito detectar a descrição das peças
que são adequadas ao perfil do estudante, de acordo com as
informações providas pelo Agente DF e as informações acerca
do acervo do museu, obtidas da ontologia de descrições das
peças. Assim, o RAg encontra, inicialmente, a descrição que
seria mais adequada de acordo com perfil do visitante. Em
seguida, com base nessas informações, o RAg verifica a
quantidade de visitas que o usuário fez àquela peça,
juntamente com a quantidade de visitas que ele fez ao museu,
e cadastra estas informações no agente DF que serão
consultadas pelo BAg.
O BAg possui sensores de proximidade presentes por todo o
museu, principalmente nas peças. A partir da aproximação de
um visitante a uma peça, o sensor percebe a intenção do
visitante em obter informações sobre a peça. Após isso, o
BAg gerencia a disponibilização do conteúdo juntamente com
os outros agentes.
O agente DF provê, para outros agentes, o serviço de
páginas amarelas. Esse serviço consiste em uma lista de todos
os agentes e os respectivos serviços oferecidos por cada
agente. Todo agente que desejar publicar seus serviços para
outros agentes devem encontrar um agente DF apropriado e
requisitar o registro da sua descrição de serviço. Além disso,
os agentes podem retirar e modificar o seu próprio registro de
um DF e buscar neste, de acordo com um critério de busca,
por um registro de serviço fornecido por outro agente. Esse
componente é de extrema importância para o Sistema
Multiagente (SMA) proposto. Outro fator a ser observado é
que o bom desempenho do RAg depende diretamente de um
mecanismo eficiente para a representação do conhecimento.
Assim, o mecanismo de recomendação desenvolvido
considera as informações do perfil do visitante, como, por
exemplo, idade, escolaridade, conhecimento sobre o tema do
museu, dentre outras, contidas na ontologia de contexto
estático, além da quantidade de visitas e as últimas peças
visitadas, as quais estão contidas na ontologia de contexto
dinâmico. Estas informações são ponderadas de acordo com as
descrições disponíveis para cada peça e são utilizadas também
para sugerir a ordem da visita e que peças devem ser visitadas,
levando em consideração as atividades de usuários com perfis
semelhantes. Com base nisto, objetiva-se alcançar uma
recomendação eficiente do conteúdo descritivo das peças do
museu.
B.1 Comunicação, Gerenciamento e Modelagem dos
Agentes de Software
Com o surgimento do paradigma de Programação
Orientada a Agentes, várias metodologias para a modelagem
de SMAs foram propostas nos últimos anos. Analisando as
vantagens e desvantagens de cada metodologia, a metodologia
escolhida para modelagem dos agentes deste trabalho foi a
metodologia MAS-CommonKADS+, que consiste em uma
extensão à metodologia MAS-CommonKADS [31].
A metodologia MAS-CommonKADS+ mantém muitos dos
modelos já propostos na metodologia MAS-CommonKADS,
porém realiza algumas modificações e adiciona novos
conceitos. Foram adicionados à metodologia os modelos de
requisitos, de papéis e de recursos, enquanto que os modelos
de organização, de interação e de projeto foram alterados, com
o intuito de complementar a especificação dos diagramas da
AML [31].
Diante disso, a modelagem dos agentes foi realizada
utilizando, além da metodologia MAS-CommonKADS+, a
ferramenta StarUML [32] que tem o intuito de promover
mecanismos de modelagem de software e uma plataforma que
possa substituir ferramentas UML comerciais.
Assim, para que se tenha uma visão do comportamento
dinâmico do SMA, utilizou-se o Modelo de Interação. O
modelo de interação consiste na junção dos modelos de
coordenação e de comunicação da MAS-CommonKADS.
Nele são descritas, através da AML, todas as interações
entre agentes. Cada interação deve obedecer a um protocolo
de interação, o qual estabelece como os agentes podem se
comunicar. A Figura 2 mostra o modelo de interação entre os
agentes que compõem o SMA proposto.
134
Figura 2. Modelo de interação entre agentes de software e ontologias.
No modelo apresentado na Figura 2, é possível visualizar
toda a interação que ocorre entre os agentes e os recurso que
são consultados por cada um dos três agentes que compõem o
sistema. O diagrama mostra desde o comportamento do UAg
no momento em que o visitante se autentica no Musert até a
informação chegar ao BAg, que irá buscar pelo conteúdo que
mais se adéqua ao perfil do visitante.
Também é possível perceber que as informações de
contexto estático e dinâmico do estudante precisarão ser
armazenadas. Uma forma possível de se armazenar essa
informação seria com a utilização de um banco de dados.
Porém, o uso de uma ontologia para a representação desse
conhecimento mostra-se como uma alternativa mais útil, visto
que esse conhecimento pode ser utilizado por outras partes da
aplicação e, caso seja necessário modificar o comportamento
desta, pode-se criar uma nova forma de representar a
ontologia, sem modificar a codificação em si. Assim, é por
este motivo que estão sendo utilizadas duas ontologias, sendo
uma para representação do contexto estático e outra para
representação do contexto dinâmico do estudante.
Um dos componentes chaves de um SMA é a comunicação
entre os agentes. Na realidade, agentes precisam se comunicar
para que sejam capazes de cooperar, colaborar e negociar entre
si. De uma forma geral, os agentes interagem entre si através
de algumas linguagens de comunicação específicas, chamadas
linguagens de comunicação entre agentes. Atualmente, a
linguagem de comunicação entre agentes mais difundida e
utilizada é a FIPA ACL (Agent Communication Language).
As principais características da FIPA ACL são a possibilidade
de utilizar linguagens de conteúdos diferentes e o
gerenciamento de conversações através de protocolos de
interação predefinidos [33].
A FIPA (Foundation for Intelligent Physical Agents) é um
conjunto de padrões da IEEE Computer Society cujo objetivo
é promover (i) tecnologias baseadas em agentes, (ii) a
interoperabilidade desses padrões com outras tecnologias, (iii)
a interoperação de agentes heterogêneos e (iv) os serviços que
eles podem representar [34].
Outra tecnologia utilizada na comunicação e gerenciamento
dos agentes foi o framework JADE (Java Agent Development
Framework), que voltado para o desenvolvimento de sistemas
multiagente e tem como uma de suas características, a sua
total implementação em linguagem Java e fornece um
conjunto de recursos técnicos para o desenvolvimento de
sistemas multiagente. Além disso, provê uma plataforma de
agentes distribuídos, gestão facilitada dos agentes e
comunicação entre agentes com troca de mensagens [35]. A
principal vantagem em utilizar o JADE reside no fato de que é
possível utilizar todos os componentes da especificação FIPA,
visto que o JADE atende todas as especificações deste padrão
e ainda o estende, sendo que um desses componentes é o
agente DF. Outra vantagem dessa plataforma consiste na
possibilidade de consultar e utilizar, através do MTS (Message
Transport Service), os agentes DFs que estejam sendo
executados em outras plataformas de agentes. Assim, o DF
utilizado na plataforma JADE deste trabalho pode, por
exemplo, ser consultado, por meio da internet, por um agente
que esteja sendo executado em outro local, através do
protocolo MTP (Message Transport Protocol). Essa
característica permite a criação de uma rede de colaboração
entre os agentes, mesmo que estejam localizados, por
exemplo, em universidades distintas [34]. A Figura 3 mostra,
através da interface gráfica do JADE, como ocorre a
comunicação entre os agentes descrita através dos modelos
textuais dos agentes apresentados anteriormente.
135
Figura 3. Comunicação entre agentes através do JADE Sniffer Agent.
Como pode ser visto na Figura 3, inicialmente, o RAg
solicita por informações de serviço ao agente DF. Em seguida,
o DF responde com as informações de serviços disponíveis.
Desta forma, a comunicação entre os três agentes e o agente
DF é mantida durante toda a utilização do museu virtual.
B.2 Características e Utilização do Perfil do Usuário
O processo de personalização proposto pelo museu utiliza
ontologias para o gerenciamento do perfil do usuário, sugestão
de serviços e registro das interações com o intuito de garantir
um processo de aprendizagem automática.
A função principal que justifica a utilização da estrutura
perfil do usuário é captura de todas as informações necessárias
para promover a recomendação personalizada de conteúdo
pelo museu. Com base nisso, a utilização das ontologias de
contexto estático e dinâmico têm participação direta nesta
recomendação.
A ontologia de contexto estático provê informações mais
gerais do usuário como nome, escolaridade, login e senha.
Devida à natureza da utilização destes dados, é que esta
ontologia tem caráter estático, ou seja, a utilização do museu e
a disponibilização de conteúdo, não influenciam estes dados.
Já a ontologia de contexto dinâmico, contém dados como
quantidade de visitas e peças visitadas, e estes dados mudam
no decorrer da utilização do museu.
Com base nestas características, a recomendação de
conteúdo é realizada levando em consideração as informações
contidas nestas duas ontologias, ou seja, a recomendação é
realizada levando em consideração o conhecimento prévio do
usuário e a sua interação com o museu.
Existem basicamente três tipos de recomendação, a
recomendação de conteúdo descritivo das peças do museu,
recomendação de rotas de visitas e as recomendações para
conteúdos externos.
A recomendação do conteúdo disponibiliza para o visitante
as descrições das peças que, a partir de sua aproximação, ele
demonstra interesse. Além disso, o conteúdo recomendado
leva em consideração as informações de contexto estático e
dinâmico. Já a recomendação de rotas de visitas, sugere rotas
com base nas peças que ainda não foram visitadas e rotas que
possam maximizar o conteúdo, apresentado informações de
forma encadeada. As recomendações externas são realizadas
com base nas peças já visitadas e no perfil do usuário como
alternativa para complementar o aprendizado sobre
determinada peça ou temática envolvida.
Diante disto, as informações contidas no perfil do usuário,
ou seja, as informações de contexto estático e dinâmico
oferecendo uma recomendação de forma direcionada para
cada visitante, proporcionando um maior aproveitamento do
conteúdo abordado pelo museu.
C. Aspectos de Implementação do Museu Virtual
Para o desenvolvimento do AVA proposto foram estudadas
diversas ferramentas e tecnologias. O objetivo principal era
permitir a navegação no ambiente virtual, bem como permitir
a interação com seus diversos elementos de forma
personalizada, utilizando para isso ontologias e agentes de
software. Foram consideradas diversas tecnologias e mundos
virtuais, como o Second Life [7] e o OpenSim [36], pela
facilidade
de
tratamento gráfico, navegabilidade e
interatividade.
Entretanto, além da necessidade de
disponibilização do conteúdo na Web, a recomendação de
conteúdo de forma personalizada exige a utilização de
136
tecnologias específicas e, por esta razão, para este trabalho
foram escolhidos o padrão X3D e o browser Xj3D.
O X3D (Extensible 3D) é um padrão adotado
internacionalmente para 3D na Web. Ele é utilizado para
construir ambientes virtuais tridimensionais complexos. Tratase de um padrão aberto que permite descrever em um arquivo
formas e comportamentos de um ambiente virtual. As formas
são descritas por figuras geométricas e os comportamentos da
cena podem ser controlados internamente pelo arquivo X3D e
externamente por linguagens de programação ou script. A
escolha do X3D como ferramenta de implementação deveu-se
a facilidade de utilização com a linguagem de programação
Java juntamente com a facilidade de comunicação com o
browser Xj3D. Além do fato do X3D oferecer suporte a
diversas mídias e formas de interação, inclusive contendo
APIs que adicionam diversas funcionalidades às já existentes
[37].
Browsers X3D consistem em aplicações capazes de
interpretar e processar as cenas, que na verdade são arquivos
X3D, apresentando os modelos tridimensionais, animados ou
não, e permitindo interações do usuário com os objetos do
cenário. A escolha do browser deve ser feita de acordo com as
necessidades do AVA a ser construído. Com isso, foi
escolhido o browser Xj3D, que se trata de um software de
código aberto e que possibilita a integração do ambiente com
scripts na linguagem de programação Java, que é a linguagem
utilizada na implementação dos agentes e na comunicação
destes com as ontologias [8] [38].
C.1 Modelagem Tridimensional
Para o desenvolvimento do Musert foram definidas três
etapas: a modelagem tridimensional do museu, denominada de
etapa de modelagem, a etapa desenvolvimento da interface
gráfica a ser utilizada pelo visitante, denominada etapa de
interface e, por último, a etapa de implementação dos agentes
e ontologias, que são os reais responsáveis pela recomendação
personalizada de conteúdo, denominada etapa de inferência de
conteúdo.
A etapa de modelagem foi concebida como primeira
atividade a ser executada. Para isso foi utilizado o Blender,
que é um software livre e de código aberto para modelagem
3D, que possui exportador para o formato X3D e que é
amplamente utilizado pela comunidade de desenvolvedores de
aplicações 3D [1] [16]. O resultado da utilização desta
ferramenta pode ser visualizado na Figura 4, onde é
apresentada uma peça 3D em fase de modelagem.
Figura 4. Peça 3D do Musert em fase de modelagem com utilização da
ferramenta Blender.
Como o museu será disponibilizado na Internet, a
modelagem foi otimizada em um nível que a qualidade gráfica
do ambiente virtual não inviabilizasse o uso devido à
quantidade de informações trocadas entre o servidor onde a
aplicação se encontra e seus visitantes. Deste modo, foram
utilizadas texturas otimizadas em relação à quantidade de
dados, mas que ao mesmo tempo promovem uma aparência
realista ao ambiente. Adicionalmente foram utilizadas técnicas
de implementação peculiares do X3D, que evitam a replicação
desnecessária de código e que, consequentemente, aumentam
a velocidade de transmissão das informações oferecidas pelo
ambiente [16].
No projeto da interface foi utilizada a linguagem de
programação Java juntamente com o browser Xj3D. O Xj3D
é um browser em conformidade com as especificações do
X3D, implementando, inclusive, funcionalidades não
especificadas pelo padrão, o que facilita o desenvolvimento de
ambientes virtuais 3D com interatividade complexa e alta
qualidade gráfica. No Musert, o visitante terá acesso ao museu
e poderá navegar por todas as salas do museu e visitar as peças
contidas em cada sala. A utilização de sensores e o
monitoramento dos agentes permite a interação com as peças
de forma inteligente, ou seja, fornecendo uma descrição das
peças de forma personalizada. O resultado da modelagem do
museu pode ser visualizado na Figura 5, onde é mostrada a
tela inicial apresentada aos visitantes.
Figura 5. Visualização externa do Musert.
No Musert, a inferência é provida pela interação entre os
agentes e as ontologias com as descrições das peças e com as
informações dos visitantes. A ontologia de contexto estático
contém informações cadastrais básicas de cada visitante,
enquanto que a ontologia de contexto dinâmico contém as
informações referentes à interação do visitante com o museu,
ou seja, nesta ontologia são armazenadas informações como as
peças que já foram visitadas, a quantidade de visitas ao museu,
a quantidade de visitas a cada peça e as salas visitadas.
Com isto, por meio da inferência realizada pelos agentes
nestas duas ontologias, é possível recomendar uma rota de
visita e uma descrição mais apropriada de cada peça para cada
perfil de usuário. Esta recomendação proporciona uma
experiência educacional ímpar e, ao mesmo tempo, eficaz para
a necessidade de cada visitante.
C.2 Sensores
A utilização de sensores foi adotada com o objetivo de
permitir a geração de eventos de acordo com a ação do
visitante no museu. Um exemplo de sensor utilizado é o
ProximitySensor. Este sensor gera eventos ao chegar próximo
de um determinado objeto, neste caso, peças do museu e
pontos específicos que acionam mecanismos para maximizar a
137
experiência educacional do visitante do museu.
Esses
sensores estão sendo utilizados para que o visitante possa
visualizar as informações a respeito das peças de forma
interativa. Assim, eles estão sendo empregados para ativar a
exibição das descrições das peças, para recomendar salas a
serem visitadas e rotas a serem adotadas, além de informações
sobre o próprio museu [38]. Na Figura 4 é possível observar a
interação do visitante com o museu a partir da aproximação de
uma região específica do museu.
REFERENCIAS
[1]
[2]
[3]
[4]
[5]
[6]
[7]
Figura 6. Interação entre visitante e o museu a partir da atuação de agentes de
software.
[8]
Como pode ser visto na Figura 6, além da existência de
sensores de proximidade nas peças do museu, existem sensores
de proximidade em pontos específicos do museu com o
propósito de promoverem uma experiência educacional
diferente por meio de sugestão de salas a serem visitadas e a
ordem em que elas são visitadas.
[9]
[10]
[11]
VI. CONCLUSÕES
Neste artigo, foi descrita a implementação de um museu
virtual 3D que utilizou tecnologias como a ferramenta de
modelagem Blender para a modelagem do museu e das peças
que o compõe, além do padrão X3D e do browser Xj3D para
disponibilizar o conteúdo do museu na web. Além disso,
também utilizou a linguagem de programação Java, agentes
inteligentes e ontologias para a realização da recomendação
inteligente de conteúdos do acervo. Desta forma, a solução
proposta objetiva tornar a aprendizagem, a partir das visitas ao
museu, adequada às necessidades de cada visitante.
Desta forma, como trabalhos futuros, pretende-se submeter
o ambiente desenvolvido à avaliação de um museólogo, para
que a aplicação tenha uma melhor abordagem no que tange o
aspecto do conteúdo descritivo das peças recomendadas. Temse também como proposta futura a integração do sistema com
redes sociais ou outros mecanismos de identificação para
ajudar no levantamento do perfil do usuário e ajudar a
melhorar a formar como os dados de cada usuário são obtidos,
evitando o preenchimento de formulários antes de utilizar o
ambiente. Além disso, objetiva-se mensurar o quanto a
abordagem é eficaz na realização da recomendação sob a ótica
educacional, tendo em vista que testes preliminares mostram
que o ambiente realiza a recomendação de forma satisfatória
obedecendo todos os critérios apresentados anteriormente.
Com base nisso, objetiva-se realizar um estudo de caso com
uma turma de um curso de ensino a distância para verificar o
impacto da abordagem proposta na adequação do conteúdo.
[12]
[13]
[14]
[15]
[16]
[17]
[18]
[19]
[20]
138
Í. B. G. Moura, J. D. Lima, P. S. M. Sousa, e F. M. Medes Neto,
“Musert: Um Museu Virtual em 3D com Recomendação Personalizada
de Conteúdo”, In Anais do XXIII Simpósio Brasileiro de Informática na
Educação, SBIE, Rio de Janeiro, RJ, 2012.
I. J. A. Soares, L. Silva, O. R. P. Bellon e A. Vrubel, “3D Virtual
Museum for Digital TV”, In WebMedia ’09, Fortaleza, CE, 2009.
M. A. Zeb and M. Fasli, “Adaptive user profiling for devianting user
interests” In: 3rd Computer Science and Electronic Engineering
Conference (CEEC), p. 65-70, 2011.
P. Q. Dung and A. M. Florea, “An Architecture and a Domain Ontology
for Personalized Multi-agent e-Learning Systems”, In Third
International Conference on Knowledge and Systems Engineering
(KSE), p. 181-185, 2011.
C. S. Bhatia and S. Jain, “Semantic Web Mining: Using Ontology
Learning and Grammatical Rule Inference Technique”, In: International
Conference on Process Automation, Control and Computing (PACC), p.
1-6., 2011.
K. Sookhanaphibarn and R. Thawonmas, “A Conten Management
System for User-Driven Museums in Second Life”, In: International
Conference on CyberWords (CW), p. 185-189., 2009.
C. J. Liu and G. Wang, “Using Second Life in ESL/EFL Teaching and
Reacher-Training in the Web2.0 Environment”, In IEEE Symposium on
Eletrical & Eletronics Engineering (EEESYM), p. 717-720, 2012.
E. L. Falcão e L. S. Machado, “Museu 3I: Publicação e Visitação Online
de Acervos Tridimensionais”, In Anais do VII Workshop de Realidade
Virtual e Aumentada (WRVA),São Paulo, SP, 2010.
S. Rivic e A. Sadak, “Multimedia Techniques in Virtual Museum
Applications in Bosnia and Herzegovina”, In International Conference
on Systems, Signals and Image Processing (IWSSIP), p. 1-4, 2011.
M. H. Bahiraey, “Quality of collaborative and individual learning in
virtual learning environments”, In Second International Conference on
E-Learning and E-Teaching (ICELET), p. 33-39, 2010.
R. R. Dantas, J. C. P. Melo, J. Lessa, C. Schneider, H. Teodósio e L. M.
G. Gonçalves, “A Path Editor for Virtual Museum Guides”, In IEEE
International Conference on Virtual Environments Human-Computer
Interfaces and Measurement Systems (VECIMS), 2010.
Z. O. Kostic, A. D. Jevremovic, D. S. Markovic e R. M Popovic,
“Virtual Educational System and Communication” In 10th International
Conference on Telecommunicatio in Modern Satellite Cabble and
Broadcasting Servies (TELSIKS), p. 373-376, 2011.
N. Saleeb e G. Dafoulas, “Pedagogical immigration to 3D virtual
worlds: A critical review of underlying themes and their concepts”, In
International Conference on Information Society (i-Society), p. 401-409,
2010
G. Guidi, R. Trocchianesi, G. Pils, G. Morlando, e A. Seassaro, “A
Virtual Museum for Design: New forms of interactive fruition”, In 16th
International Conference on Virtual Systems and Multimedia (VSMM),
p. 242-249, 2010.
Y. Chengwei, Y. Chengle, L. Shijun, M. Xiangxu e W. Rui, “An
Approach of Personalized 3D Scene Customization Based on
Multimedia Resources” In International Conference on Multimedia and
Signal Processing (CMSP), p. 131-135, 2011.
Í. B. G. Moura, J. D Lima, F. M. Mendes Neto, P. S. M. Sousa,
“MUSERT: Um Museu Virtual em 3D para a Preservação do Patrimônio
Histórico e Cultural do Semiárido Brasileiro”, In Anais da V Escola
Regional de Computação dos Estados do Ceará, Maranhão e Piauí
(ERCEMAPI), 2012.
M. H. Bahiraey, “Quality of collaborative and individual learning in
virtual learning environments”, In Second International Conference on
E-Learning and E-Teaching (ICELET), p. 33-39, 2010.
J. Z. Jun e W. Z. Bin, “Ideas transforming in the public arts education of
virtual museum”, In 6th International Conference on Computer Science
& Education (ICCSE), p. 649-653, 2011.
T. T. Primo, R. M. Vicari, J. M. C. Silva, “Rumo ao Uso de Metadados
Educacionais em Sistemas de Recomendação”, In Anais do XXI
Simpósio Brasileiro de Informática na Educação, SBIE, João Pessoa,
PB, 2010.
L. C. N. Silva, F. M. Mendes Neto e L. Jácome Júnior, “MobiLE: Um
ambiente Multiagente de Aprendizagem Móvel para Apoiar a
Recomendação Sensível ao Contexto de Objetos de Aprendizagem”,
[21]
[22]
[23]
[24]
[25]
[26]
[27]
[28]
[29]
[30]
[31]
[32]
[33]
[34]
[35]
[36]
[37]
[38]
Artigo Completo, In Anais do XXII Simpósio Brasileiro de Informática
na Educação, SBIE, Aracaju, SE, 2011.
L. Qu, N.Wang e W. L. Johnson, “Choosing When to Interact with
Learners”, In Proceedings of the 9th international Conference on
Intelligent User Interfaces, 2004.
E. Soliman e C. Guetl,“Intelligent Pedagogical Agents in immersive
virtual learning environments: A review”, In Proceedings of the 33rd
International Convention, MIPRO, p. 827-832, 2010.
V. R. Lesser, “Cooperative multiagent systems: a personal view of the
state of the art”, In IEEE Transactions on Knowledge and Data
Engineering, v. 11, n. 1, p. 133-142, 1999.
L. P. Reis, “Coordenação em Sistemas Multi-Agente: Aplicações na
Gestão Universitária e Futebol Robótico”, In PhD Thesis, FEUP, Julho
2003.
H. Zhao, S. Zhang e J. Zhao, “Research of Using Protégé to Build
Ontology”, In 11th International Conference on Computer and
Information Science (ICIS), p 697-700, 2012.
N. Prat, J. Akoka e I. Comyn-Wattiau, “Transforming multidimensional
models into OWL-DL ontologies”, In 6th International Conference on
Research Challenges in Information Science (RCIS), p 1-12, 2012.
K. M. Albarrak, E. H. Sibley, “A Survey of Methods that Transform
Data Models into Ontology Models”, In International Conference on
Information Reuse and Integration (IRI), p 58-65, 2011.
“Ontological Foundations for Structural Conceptual Models”, In PhD
Thesis, Centre for Telematics and Information Technology CTIT,
Enschede, The Netherlands, 2005.
R. Zhao e C. Zhang, “An Ontology–Based Knowledge Management
Approach for E-Learning System”, In International Conference on
Management and Service Science (MASS ‘09), p 1-4, 2009.
W.Min, C.Wei, e C. Lei, “Research of ontology-based adaptive learning
system”, In International Symposium on Computational Intelligence and
Design, ISCID ’08, v. 2 , p. 366 –370., 2008.
M. J. D. O. MORAIS II, “MAS-CommonKADS+: Uma Extensão à
Metodologia Mas-CommonKADS para Suporte ao Processo Detalhado
de Sitemas Multiagentes Racionais”,Dissertação de Mestrado.
Universidade Estadual do Ceará - UECE. Fortaleza, CE. 2010.
STARUML. StarUML - The Open Source UML/MDA Platform. Página
Sourcefourge
do
STARUML,
2011.
Disponivel
em:
<http://staruml.sourceforge.net/en/>. Acesso em: outubro de 2012.
L. C. M. Silva, “MobiLE – Um Ambiente Multiagente de Aprendizagem
Móvel para Apoiar a Recomendação Ubíqua de Objetos de
Aprendizagem.”,Dissertação de Mestrado. Universidade do Estadual do
Rio Grande do Norte – UERN e Universidade Federal Rural do SemiÁrido - UFERSA. Mossoró, RN. 2012.
FIPA. Welcome to the Foundation for Intelligent Physical Agents. Site
Oficial do Padrão FIPA, 2011. Disponivel em: <http://www.fipa.org/>.
Acesso em: outubro de 2012.
JADE, “Java development framework: an open-source platform for peerto-peer agent based applications”. Online: http://jade.tilab.com/. Acesso
em: setembro/2012.
W. Ridgewell, V. Kumar, O. Lin and Kinshuk, “OpenSim Virtual as
Platform for Enhanced Learning Concepts”, In IEEE International
Conference on Advanced Technologies (ICALT), p.623-624, 2011.
D. P. S. Medeiros e L.S. Machado, “X3D e Integração Multimídia para
Representação de um Sítio Arqueológico”, In Anais do VII Workshop
de Realidade Virtual e Aumentada (WRVA),São Paulo, SP, 2010.
Í. B. G. Moura, F. M. Medes Neto, P. S. M. Sousa e J. D. Lima,
“Utilização do Padrão X3D no Desenvolvimento de um Museu Virtual
Imersivo com Recomendação Personalizada de Conteúdo Através do
Uso de Agentes Inteligentes e Ontologias”, In Anais do IV Workshop
de Realidade Virtual e Aumentada (WRVA), Paranvaí, PR, 2012.
Francisco Milton Mendes Neto possui graduação em Ciência da
Computação pela Universidade Estadual do Ceará (1997),
mestrado em Informática pela Universidade Federal de
Campina Grande (2000) e doutorado em Engenharia pósgraduação em Ciência da Computação da Universidade
Federal Rural do Semi-Árido (UFERSA). Tem
experiência na área de Ciência da Computação, com
ênfase em Engenharia de Software, atuando
principalmente nos seguintes temas: ensino a distância,
aprendizagem colaborativa com suporte de computador, engenharia do
conhecimento, gestão do conhecimento e sistemas multiagentes.
Paulo Sérgio Maia de Sousa é Bacharelando em Ciência da Computação
pela Universidade Federal Rural do Semi-Árido
(UFERSA). Atualmente faz parte do Núcleo Tecnológico
de Engenharia de Software (NTES). Atua principalmente
na área de Engenharia de Software, principalmente nos
seguintes temas: ensino a distância, gestão do
conhecimento e sistemas multiagentes.
João de Deus Lima possui graduação em Licenciatura em Matemática pela
Universidade do Estado do Rio Grande do Norte (1983),
mestrado em Matemática pela Universidade Federal do
Ceará (1996) e doutorado em Engenharia Elétrica pela
Universidade Estadual de Campinas (2002). Atualmente é
professor adjunto 4 da Universidade do Estado do Rio
Grande do Norte, lotado no Departamento de Matemática e
Estatística e do quadro permanente de professores do
mestrado em Ciência da Computação UERN-UFERSA. A
área de interesses é Sistemas de Telecomunicações, com enfases em
modulações, códigos corretores de erros, canais e processamento digital de
imagens. Para tanto utiliza ferramentas matemáticas como a Topologia
Algébrica, Geometria Riemanniana e Teoria dos Grafos.
Íthalo Bruno Grigório de Moura é Tecnólogo em Análise Desenvolvimento
de Sistemas pelo Instituto Federal do Piauí (IFPI),
Teresina (2010). Atualmente faz parte do Núcleo
Tecnológico de Engenharia de Software (NTES) na
Universidade Federal Rural do Semi-Árido (UFERSA).
Ingressou em 2011 no Programa de Pós-Graduação em
Ciência da Computação ofertado pela Universidade do
Estado do Rio Grande do Norte - UERN e pela UFERSA.
139
Transmission of Images Captured in Real Time
through Wireless Network using the Python
Language: A possible way of Wireless
Transmission
M. Z. B. Araujo and F. M. A. Araujo
Abstract– 1In order to send images over the network from one
computer to another in a Telerobotic system more adequately, it
has developed a way to transmit images over the network adapting
it to the programming language chosen in this system. The work,
therefore, is to capture a frame of a camera through a library for
games, turn it into text and send over the network to another
computer using socket programming, in the target are made of
inverted steps, gets converted to text in image again to use on any
purpose. From the experimental research, several tests were
performed to reach the synthesis scheme presented in this paper.
Keywords—Wireless Networks, Python, Images, Wireless
Transmission.
I. INTRODUÇÃO
N
os dias atuais, o vídeo é considerado parte fundamental
na interação com o usuário quando se fala em sistemas
web, monitoração ou em projetos de Telerobótica. Assim que
a Internet surgiu, no final da década de 80, sua velocidade era
muito limitada, onde a conexão entre Brasil e Estados Unidos
oferecia uma banda que suportava, no máximo, 9 kbps [8].
Acreditava-se que a transmissão de imagens congestionaria
toda a rede entre os dois países. Esse é o motivo pelo qual
quando a interligação mundial das redes surgiu, a transmissão
de dados era limitada, afetando diretamente o layout dos sites
da época, onde estes eram compostos somente por texto [9],
mídia mais leve de ser transmitida.
Um site composto somente por texto, implica em um visual
extremamente rústico, tornando pouco o interesse dos usuários
ao navegar e permanecerem na página acessada. Diante deste
impasse, viu-se que realmente era crucial o envio de mídias
mais pesadas, como imagens com resolução cada vez mais
altas, ou até vídeos a longas distâncias. Esse problema foi
resolvido com o avanço da tecnologia, que passou a
disponibilizar bandas de transmissão de dados mais largas,
integradas a linguagens de programação que passaram a
disponibilizar bibliotecas específicas, também facilitadoras da
interatividade com o usuário. Em suma, capturar uma imagem
para depois convertê-la em texto foi uma das soluções
encontradas para a transmissão de imagens através da rede,
diminuindo até, o nível de congestionamento no tráfego dos
dados.
Com base nisto, objetiva-se enviar imagens entre
dispositivos pela rede usando Python. Para isto será
apresentada a seguinte metodologia: pode-se usar a linguagem
Python por ter um fácil entendimento [10] usando sua
biblioteca para jogos Pygame, pois dá suporte a captura de
frames da webcam, além de ter algumas funções para
manipulação de imagens, trabalhando junto a biblioteca
socket, que se responsabiliza pela comunicação entre
dispositivos através da rede, já inclusa na biblioteca padrão do
Python.
A partir desta metodologia, os resultados esperados irão
depender diretamente da taxa de transferência do equipamento
utilizado no meio de transmissão, seja wireless ou não.
Neste artigo serão abordados a metodologia usada, exemplo
e configuração de um código em Python, testes realizados com
um programa mais elaborado desenvolvido usando esta
mesma metodologia, seguidos dos resultados obtidos.
II. METODOLOGIA
Python, em um propósito geral, é uma linguagem de
programação de computador de código aberto. É otimizada
para qualidade de software, a produtividade do desenvolvedor,
a portabilidade do programa e integração de componentes [4].
O Python, ao ser instalado, leva consigo sua biblioteca
padrão, centenas de módulos que contêm ferramentas que
permitem ao programador uma interação com o sistema
operacional, interpretador e internet [1]. Seu conteúdo extenso,
escrito na linguagem C, permite um melhor uso de
funcionalidades do sistema, bem como dispositivos de entrada
e saída de dados. Partindo do ponto em que, funciona em
qualquer plataforma que tenha compilador de C, assim que o
Python é instalado, dá suporte para a programação de socket.
O socket é um meio para programação de redes com
funcionamento baseado na tecnologia Cliente/Servidor,
possibilitando a comunicação entre dispositivos conectados a
rede como: celulares, tablets, computadores entre outros.
Nesse sentido, percebe-se que o Python, desenvolvido
basicamente em C/C++, resulta em uma boa manipulação de
dispositivos de entrada/saída como, por exemplo, uma
M. Z. B. Araujo, Universidade Estadual do Piauí (UESPI), Parnaíba, Piauí, webcam. Pygame é uma biblioteca para desenvolvimento de
jogos usando Python que dá suporte também ao uso da
F. M. A. Araujo, Instituto Federal de Educação, Ciência e Tecnologia do
webcam, bem como, algumas funções para manipulação de
Piauí (IFPI), Parnaíba, Piauí, Brasil, [email protected]
140
imagens, sendo possível, até mesmo, transformar uma imagem
em texto ou vice versa.
Usa-se uma função tostring dessa biblioteca, capaz de
converter uma imagem em string. Já a função fromstring é
usada para realizar a tarefa inversa, transformando o texto em
imagem novamente. Em seguida, o socket é criado e
configurado com mesmo endereço IP, mais precisamente o IP
do servidor, em dois ou mais dispositivos, porta de
comunicação e protocolo para que a conexão seja estabelecida,
captura-se um frame da câmera e transformando-o em texto,
sendo assim, possível enviá-lo entre os hosts da rede com a
linguagem Python.
A Figura 1 mostra o trecho final de uma imagem convertida
em texto, composta por cabeçalho onde possui informações
sobre a imagem como largura, altura, entre outros, seguido por
uma sequência de caracteres que substitui os pixels. Cada
pixel é composto por três cores: vermelho, verde e azul
dependente do padrão de cores usado na configuração da
webcam. Cada cor recebe um valor que está compreendido
entre 0 e 255, representando sua intensidade que quando
misturadas, pode compor imagens de 24 bits de cores.
Figura 2. Arquitetura do Sistema.
A Figura 2 ilustra a funcionalidade do programa
desenvolvido neste trabalho, que consiste em transferir
imagens a partir de um computador. Esse esquema mostra o
caminho percorrido pelos dados transferidos, que inicia-se
com a captura da imagem através da função get_image da
biblioteca Pygame, onde retorna um objeto Surface, que é
convertido em texto pela mesma biblioteca. Com a classe
image são passados como parâmetros um objeto Surface e um
padrão de cores RGB, usado neste estudo. Com a classe
socket, que dá suporte a comunicação entre hosts usando texto
e/ou buffer, a imagem transformada em texto pode ser enviada
pela rede, tendo em vista que, ao ser criado, o socket precisa
de um endereço IP, porta de comunicação, especificação do
protocolo, entre outros.
A próxima seção do artigo, serão abordados a configuração
do socket, bem como um exemplo simples de como se pode
enviar uma imagem através da rede usando a metodologia
apresentada.
III. CONFIGURAÇÃO
Figura 1. Trecho final da string retornada pela função tostring, seguida de seu
tamanho mostrado pela função len.
Câmera
Objetivo
Pygame
Pygame
Figura 3. Programa em Python que captura um frame de uma Webcam e o
envia convertido em texto através de socket.
socket
socket
Ubuntu
Ubuntu
Rede
Rede
A Figura 3 exemplifica um código escrito em Python que
representa o Servidor. A partir da linha 9 até a linha 11,
destacadas em azul, é configurada a webcam, onde são
especificadas resolução e padrão de cores a ser usado. Da
linha 12 até a linha 17, no interior do retângulo verde, ilustra o
momento em que se instancia o objeto socket, são explicitados
a porta de comunicação, endereço de IP, protocolo de
comunicação e a quantidade de hosts que o servidor deve
ouvir. Para que a conexão seja estabelecida, devem-se criar os
sockets de maneira sincronizada, com a mesma porta de
141
comunicação e mesmo endereço de IP, mais especificamente o
IP do servidor.
Podem ser usadas no socket as faixas IPV4 e IPV6,
protocolos FTP e UDP paralelamente a porta de comunicação
que pode assumir valores de 0 a 65535, porém alguns serviços
já possuem portas específicas como requisições HTTP através
da porta 80 ou SSH pela porta 22, mas, portas com valores
inferiores a 1024 necessitam da permissão de super usuário,
caso contrário, o sistema operacional interrompe o processo de
criação do socket.
Um ponto muito importante e decisivo para o
funcionamento satisfatório de um sistema de vídeo é a
velocidade do meio em que é feita a transmissão dos dados,
uma vez que o desempenho está diretamente ligado à
qualidade das imagens capturadas, resolução, quantidade de
frames por segundo (fps) e o plugin usado na renderização e
compressão do arquivo. A largura de banda máxima é de 344
Mbps, o que corresponde a imagens estereoscópicas com 70
quadros por segundo e uma resolução de 640x480 pixels por
imagem [2].
Esta metodologia teve como norte os testes que buscavam
uma análise comportamental do programa desenvolvido. Tais
testes serão explanados mais detalhadamente no tópico que se
segue.
Logo abaixo, são exemplificados dois testes de
desempenho da rede ao se transmitir imagens pela rede usando
uma aplicação desenvolvida. Os equipamentos utilizados
foram um computador Desktop Intel® Core 2 Duo 2.8Ghz
com 2Gb de memória (Cliente), conectado a um roteador
Wireless TP-LINK de 150 Mbps por um cabo de ethernet,
conectado a um netbook CCE Intel® Atom® 1.33Ghz com
2Gb de memória (Servidor), ambos os computadores com o
Ubuntu 11.04 como sistema operacional.
IV. TESTES E RESULTADOS
Figura 4. Network History demonstra um grafíco do Cliente com a velocidade
constante necessária para transmissão de imagens com resolução de 320x240
pixels.
TABELA I
TABELA DE VELOCIDADE DA CONEXÃO POR RESOLUÇÃO DE VÍDEO
Tipos de sinais
TV vídeo
(PAL/NTSC)
TV vídeo
compactado
(Qualidade de
DVD)
Vídeo stereo
(Não
compactado)
Vídeo stereo
compactado
(Qualidade de
DVD)
Tamanho do
quadro
Frames por
segundo
720x480
25 – 30 fps
720x480
25 – 30 fps
5,2 Mbps
640x480
30 – 70 fps
147 – 344
Mbps
640x480
30 – 70 fps
6,3 – 14,6
Mbps
Na Figura 4, em Network History do gerenciador do
sistema do Ubuntu, é exibido um gráfico que representa uma
velocidade estável em 1,5 Mbps na transmissão de imagens
com resolução de 320x240 pixels usando a aplicação que
originou este artigo. A estabilidade da velocidade da rede
implica em um desempenho satisfatório, com uma taxa de fps
próxima ao ideal, que quanto maior esta taxa, maior será a
sensação de movimento que uma sequência de imagens pode
propor e maior a quantidade de dados que serão enviados.
Largura de
banda
165,9
Mbps
A Tabela 1 ilustra um comparativo entre qualidade das
imagens associada a velocidades da conexão no meio de
transmissão. Conforme os testes feitos, comprova-se que a
taxa de bits necessária para a transmissão de vídeo, utilizandose um codec de compressão DivX®, com a resolução de
320x240 pixels, mantém-se por volta de 1,5 Mbps, onde a
conversão de cada imagem retorna um texto com tamanho
exato de 230400 bytes. Contudo, se a resolução for estendida
para 640x480 pixels, o tamanho do arquivo é de 921600 bytes,
entretanto, para transmitir o vídeo com um desempenho
satisfatório, é necessário uma rede que proporcione no mínimo
10 Mbps de velocidade em transferência de dados.
Figura 5. Network History demonstra um grafíco do Cliente com a velocidade
irregular, resultando em perda de desempenho do vídeo.
142
[6]
Instabilidade na rede pode ocasionar em perda significativa
de desempenho na hora de se transmitir grandes volumes de
dados. A Figura 5 mostra, em Network History,
irregularidades no gráfico de velocidade da rede. Este teste foi
realizado usando as mesmas características do teste anterior:
aplicação, resolução da imagem e equipamento de transmissão
sem fio. Esta instabilidade foi propositalmente provocada ao
se remover a antena do roteador wireless, resultando na perda
do sinal, acarretando na demora na transmissão, e por fim, na
redução da qualidade do vídeo, com a quantidade de fps
podendo girar em torno de menos de 1 frame a cada segundo.
V. CONCLUSÕES
Convém ressaltar a funcionalidade dos sockets para
transmissão de dados e a simultaneidade entre os dispositivos
onde este é executado. Um host ao receber uma string através
do socket, transfere as informações para o módulo Pygame,
que por sua vez, converte o texto em imagem novamente,
possibilitando, assim, que haja interação entre usuários de
computadores remotos. Mas, observou-se um problema de
incompatibilidade entre a biblioteca Pygame e o sistema
operacional Windows no momento em que se tenta usar a
webcam [7]. Baseado neste pressuposto, a versão Servidor da
metodologia apresentada deve executar incondicionalmente no
sistema Ubuntu, mesmo porque o Windows passa por uma
transição de versão e não se tem resultados de execução do
Python em sua versão nova.
No desenvolvimento deste artigo, encontrou-se dificuldade
em obter-se embasamento teórico de artigos científicos com
trabalhos de mesmo princípio de funcionamento ou que
envolvesse a integração de Python, Pygame e Opencv com
objetivos similares.
Conclui-se então, que esta metodologia foi estabelecida
inicialmente com o objetivo de satisfazer uma necessidade
encontrada em um sistema Telerobótico, mas adaptações
tornam esta maneira de envio de imagens cabível a qualquer
situação que seja necessário monitoramento através de
câmeras com uso de sinais Wireless disponíveis, desde
exploração de outros planetas, monitoramento urbano,
residencial, industrial, militar até sistemas de TeleCirurgia ou
arquiteturas onde cliente e servidor podem estar a distâncias
continentais tendo redução de custo com equipamentos, cabos,
instalações no interior de paredes, entre outros, e até
aproveitamento de serviços disponíveis como a própria
Internet.
A. Anderson, R. Benedetti, Head First Networking. O’Reilly,
Sebastopol, 2009.
[7] http://www.pygame.org/news.html.
[8] http://www.olhardigital.com.br/produtos/central_de_videos/webcompleta-20-anos-veja-toda-a-historia.
[9] http://info.cern.ch/.
[10] T. A. Budd, Exploring Python. McGraw-Hill, Maidenhead, 2009.
Marlo Zeni Braga de Araujo é graduando em Bacharelado
em Ciências da Computação pela Universidade Estadual do
Piauí (UESPI), Parnaíba, Piauí, Brasil. Suas pesquisas se
concentram na área da Telerobótica, Computação, Eletrônica
e almeja mestrado e doutorado nessas áreas.
Francisco Marcelino Almeida de Araújo é Bacharel em
Engenharia Elétrica com ênfase em Eletrônica pela
Universidade Estadual do Piauí (UESPI) em Teresina, Piauí,
Brasil. Mestrando em Biotecnologia pela Universidade
Federal do Piauí em Parnaíba, Piauí, Brasil, trabalhando com
nanocompósitos para nanofilmes aplicados à Engenharia
Biomédica e materiais anticorrosivos. Suas principais áreas de pesquisas são:
Processamento Digital de Imagens, Hardware Livre, Robótica, Tecnologias
Assistivas à Deficientes e Portadores de Necessidades Especiais,
Nanotecnologia, Engenharia Biomédica e Engenharia de Materiais.
REFERÊNCIAS
[1]
[2]
[3]
[4]
[5]
D. Hellmann, The Python Standard Library by Example. Pearson
Education, Boston, 2011.
R. Aracil, M. Buss, S. Cobos, M. Ferre, S. Hirche, et al, The Human
Role in Telerobotics. Berlim, v.31, p.11-24, 2007.
B. Rhodes, J. Goerzen, Foundations od Python Network Programming:
The Comprehensive guide to building network applications with
Python. Apress, New York, 2010.
M. Lutz, Programming Python, Fourth Edition. O’Reilly, Sebastopol,
2011.
P. Barry, Head First Python. O’Reilly, Sebastopol, 2011.
143
Project OurDown: Collaborative System for
Download Management in Overlay Network
R. G. Sousa
Abstract— 1This paper brings a new model to solve the problem
of downloads in social networks. In particular the waste of
bandwidth by downloading one same file multiple times. The
Internet Architecture provides the best effort and it forward each
package individually, but it doesn’t provide a good performance,
neither deals with redundant downloads. In this case the problem is
known and there are some solutions, for instance Proxy Caching
and FTP servers, but those don’t work with colaboration between
users in a local network, and they are not built by the point of view
of groupware and distributed systems. The objective of the project
Ourdown is to remove redundant downloads and add
conscious/aware components, built on a Peer to Peer (P2P)
network. P2P has been involved on building experimental and
sophisticated components, and those components can talk to each
other and consequently avoid duplicated downloads. This paper
demonstrates the model, the specification and the development of
the project Ourdown.
Keywords — Peer to Peer, Download Manager, JXTA.
I INTRODUÇÃO
S
egundo projeções para 2015, realizado pela
instituição de consultoria IDC (Internacional Data
Corporation), o tráfego mensal médio de quem usa a Internet
será em torno de 24,8 gigabytes, para enviar esta quantidade
de informação por escrito, seria necessário 1 milhão de cartas
de uma página cada uma, ou 10 (dez) toneladas de papel [1].
Segundo pesquisas feita pela Internet World Stats [2] a
Internet possui cerca de 2 (dois) bilhões de usuários, cerca de
32% da população mundial tem acesso a Internet, o
crescimento de usuários de 2000 até 2011 foi de 528%
(quinhentos e vinte e oito). Com o crescimento da Internet
torna-se atraente o compartilhamento de arquivos via WWW
(Word Wide Web), atualmente é comum às organizações
disponibilizar seus arquivos digitais através de portais. Este
procedimento torna-se atrativo, pois economiza com
gravações de mídias e o interessado obtém o arquivo sob
demanda e com todas as vantagens que a Web pode
proporcionar.
Antes do ambiente WWW para compartilhamento de
arquivo o serviço FTP (File Transferer Protocol) foi o
principal meio de troca de arquivos, o FTP viabiliza o
compartilhamento de arquivos na Internet permitindo que um
usuário em um computador: transfira; mova; ou remova
arquivos remotos [3]. Em organizações onde o tráfego na rede
necessita de extremo controle o administrador da rede executa
uma conexão remota ao servidor FTP que disponibiliza o
1
R. G. Sousa, Universidade Federal do Piauí (UFPI), Piauí, Brasil,
[email protected]
arquivo desejado e deixa-o disponível para os usuários na rede
local. O procedimento é muito atrativo, pois limita a
quantidade de downloads entre a rede local e a externa.
O serviço FTP foi criado numa época em que o uso da
Internet era limitado e os usuários não realizavam downloads
constantemente [4]. Atualmente, controlar o tráfego em uma
rede torna-se muito difícil por vários aspectos: (i) nova
geração de usuários acostumados com acesso irrestrito; (ii)
liberdade dos usuários em utilizar a Internet; (iii) pouco
conhecimento sobre as características do “conjunto” que o
permitem o acesso à Internet. Com o passar do tempo a
transferência de arquivos através da Web supriu o serviço FTP.
Recentemente, vários downloads são via navegadores
acessíveis por meio de hyperlinks em páginas Web. Para obter
um arquivo o usuário encontra o que deseja e clica no
hyperlink, de forma simples e transparente. O comportamento
individual de cada internauta não leva em consideração o
comportamento do grupo de usuários na rede em comum.
Para facilitar a atividade de download, existem diversos
gerenciadores disponibilizados na Internet, sejam pagos, como
o Internet Download Manager [5], ou gratuitos, p.ex: Orbit [6]
e JDownloader [7]. Estes e outros aplicativos que se situam no
lado do cliente, ao contrário dos servidores FTP, ficam no
âmbito do computador do usuário e fogem da administração
centralizada. Ambos os tipos de gerenciadores de downloads,
servidor FTP ou aplicativos do lado do cliente não usufruem
do compartilhamento peer-to-peer para otimizar o link de
acesso à Internet.
Uma dificuldade muito grande para qualquer
administrador de rede é evitar downloads redundantes dentro
de uma rede local. Servidores FTP precisam de uma
administração rígida e centralizada e aplicativos gerenciadores
de downloads que são executados do lado do cliente
funcionam no escopo restrito da máquina dos usuários e não
são acessíveis para outros usuários dentro da mesma rede. A
redução de downloads paralelos do mesmo arquivo é de
grande importância para economia de banda de rede, uma vez
que as cópias transmitidas concorrem e consomem recursos
preciosos da rede, como: buffers de recepção, buffers de
transmissão, links de dados, processador e memória dos
roteadores e comutadores de rede.
Este trabalho propõe a criação de componentes de
softwares distribuídos [8,9,10] que são instanciados numa rede
local. O objetivo é trabalhar de forma cooperada e em
conjunto com o navegador do usuário para gerenciar os
downloads dentro da rede local. Os componentes comportamse de forma a monitorar e promover a comunicação entre eles
do início de eventuais downloads e alertando outros
144
componentes da existência do download. A vantagem deste
sistema é suprimir redundâncias de downloads, evitando-se
novas conexões entre a rede local e a externa. Toda a
interação segue o modelo de comunicação peer-to-peer [11],
ou seja, sem a necessidade de configurar um servidor central
para o controle, cuja característica é um dos pontos de
destaque do projeto Ourdown.
As próximas seções deste artigo estão organizadas da
seguinte maneira: na seção 2 apresentam-se os trabalhos
relacionados, a seção 3 aborda a fundamentação teórica do
projeto e o modelo conceitual do projeto Ourdown, figura-se
os diagramas de classe e sequencia para compreensão do
modelo concebido. Na seção 4 apresentam-se as tecnologias e
a infraestrutura de rede usada no projeto. Sequencialmente, a
seção 5 destaca dois pontos importantes na codificação do
modelo. A seção 6 descreve um resumo dos motivos de adoção
da plataforma JXTA. Por fim, na seção 7 estão as
considerações finais com vários pontos aprendidos durante o
desenvolvimento e a descrição de melhorias almejadas.
II. TRABALHOS RELACIONADOS
Com o intuito de posicionar o trabalho perante o assunto de
distribuição de arquivos, propõem a seguinte divisão para os
serviços de compartilhamento de arquivos:
a. Centralizados e não transparente: FTP;
b. Centralizados e transparentes: WEB Cache;
c. Distribuídos, transparentes, sem controle de
admissão: Squirrel;
d. Distribuídos, transparentes, com controle de
admissão: Ourdown.
2.1 FTP
O FTP (File Transfer Procolol) [12] é o protocolo destinado
a transferência de arquivos de um hospedeiro ao outro na
Internet. Projetado em 1971, tem como missão criar uma
ambiente de manipulação de arquivos remotos através de
primitivas parecidas com as utilizadas nos sistemas de
arquivos locais. Para tanto, é possível através do FTP um
cliente realizar as seguintes operações: listar, renomear,
remover, criar, transferir e outras.
deste serviço. O servidor proxy utiliza o ambiente WEB para
transmissão de dados. Em 1998 o tráfego WEB correspondia a
75% de todo o tráfego na Internet [14]. O servidor proxy é
utilizado por um cliente através de uma prévia configuração
no navegador, ou no sistema operacional, ou no gateway da
rede através de um recuso chamado de proxy transparente.
O tempo de armazenamento na cache depende de uma
prévia configuração realizada pelo administrador da rede [15].
Cabe ao administrador da rede: a) instalar o servidor proxy na
rede; b) decidir o que deve ser armazenado; c) quanto tempo
será armazenado as páginas e os objetos; e d) o tamanho da
cache que será reservado.
2.3 Squirrel
Squirrel [16] é um sistema de WEB cache distribuído que
usa o protocolo Pastry na busca de recursos e no roteamento
de mensagens. O Squirrel é um serviço executado no mesmo
host que o navegador WEB e ele compartilha o diretório de
cache do navegador.
Após o cliente solicitar uma URL a solicitação é
encaminhada ao proxy Squirrel. Inicialmente o Squirrel
verifica se o objeto está na cache local e caso o objeto não
exista localmente é feita uma busca na rede P2P formada por
outros nós. A URL é utilizada para gerar um identificador
através de uma função de hash, e com este identificador a
solicitação é encaminhada a um nó da rede P2P que tem o
identificador mais próximo do identificador do objeto. Este
principio é a base da DHT (Dynamic Hash Table). Squirrel é
um projeto maduro com resultados factíveis e implementa o
protocolo Pastry para realizar a identificação de objetos e o
roteamento para o encaminhamento de mensagens.
2.4 Ourdown
Ourdown é um projeto construído sobre uma arquitetura
Peer-to-Peer (P2P). Esta arquitetura é caracterizada pela
distribuição horizontal das entidades, assim, cada entidade é
um servente, assumindo funções de cliente e servidor, este
comportamento simétrico é desejado para sistemas sem a
presença de um servidor central.
Segundo Tanenbaum [4], as arquiteturas P2P são de dois
tipos: estruturadas ou não estruturadas. As arquiteturas
estruturadas utilizam de mecanismos complexos, p.ex:
variações da DHT (Dynamic Hash Table), para nomeação e
localização, muito estudo foi realizado neste assunto deste o
Napster 2007 [4]. Balakrishnan (2003) [17] em seu trabalho
“Looking up Data in P2P System” apresenta vários algoritmos
como: CAN, Pastry, Tapestry e Chord como evoluções do
percursor Napster para distribuição de arquivos sob
arquitetura P2P.
As arquiteturas não estruturadas são sistemas em que não se
utiliza de complexos sistemas de nomeação e localização para
construir uma rede de sobreposição. Quando um nó precisa
localizar um item, a única coisa que ele faz é inundar a rede
com uma consulta de busca. O projeto Ourdown é construído
sobre uma arquitetura não-estruturada.
A Tabela 1 apresenta as diferenças entre os sistemas FTP
(seção 2.1), WEB Cache (seção 2.2), Squirrel (seção 2.3) em
relação ao Ourdown. As respostas da primeira pergunta mostra
que o Squirrel e o Ourdown são sistemas descentralizado. A
2.2 WEB Cache
Servidor WEB Cache, também conhecido como servidor
proxy, é o servidor que realiza cache de objetos WEB da
Internet, assim além de armazenar páginas HTML (HyperText
Markup Language) também pode armazenar objetos (imagens,
áudio e vídeos) referenciados nas páginas requisitadas via o
protocolo HTTP (Hyper Text Transfer Protocol). É utilizado
para reduzir o tráfego na Internet, pois armazena
temporariamente os arquivos [13]. Geralmente é um serviço
dedicado e colocado entre a rede local e a externa.
A ideia do servidor proxy é trazer o conteúdo de um
servidor WEB para mais próximo do cliente e assim diminuir
o tempo de espera. A vantagem é alcançada na segunda
requisição HTTP emitida pelo cliente que inicialmente fez a
requisição HTTP ou por outro cliente que compartilha o
mesmo servidor proxy. O tamanho da cache versus páginas
estáticas e dinâmicas é um ponto de conflito nas configurações
145
resposta da segunda pergunta mostra que o Squirrel e o
Ourdown não necessitam de um administrador de rede para
sua execução. As respostas da terceira pergunta mostra que
somente o WEB Cache e o Ourdown fazem controle da
admissão de novas conexões para arquivos, o WEB Cache
utiliza da primitiva HEAD do HTTP para este controle. A
resposta da quarta questão mostra que somente o FTP não
esconde do usuário os parâmetros de rede como: endereço,
porta, usuário e senha, diretórios e nome dos arquivos
remotos. A resposta da quinta questão mostra que no FTP e na
WEB Cache o usuário para encontrar um recurso precisa
necessariamente saber sua localização. As respostas da sexta
questão apresentam que somente o Squirrel e o Ourdown, por
serem construídos sobre uma arquitetura distribuída, possuem
uma maior robustez por não possuir um ponto de
vulnerabilidade.
A resposta da última pergunta da Tabela 1 destaca o ponto
de divergência conceitual do projeto Squirrel e Ourdown. O
Ourdown evita que conexões a um mesmo objeto sejam feitas
em tempo real, o controle da banda é pró-ativa. No Squirrel os
arquivos são obtidos através de diretórios temporários dos
navegadores Web após o download ser completado, não há
intervenção do sistema durante o download, dois clientes
usando o Squirrel podem realizar o download de um mesmo
arquivo ao mesmo tempo, este comportamento é evitado pelo
Ourdown.
se preocupam em detectar nenhum download, e assim é
comum que um arquivo seja descarregado por vários usuários
ao mesmo tempo. Visualiza-se que o “Arquivo A” na Fig. 1 é
duplicado no espaço de armazenamento do Usuário 1 e
Usuário 2.O tempo de download de um arquivo (Fórmula 1) é
proporcional ao tamanho do mesmo e a Largura de Banda.
Calcula-se o tempo de download através da fórmula:
F (t )=
t
v
(1)
São variáveis da Fórmula 1:
 t denota o tamanho do arquivo;
 v denota a largura de banda.
Quanto maior a quantidade de downloads paralelos
menor será a largura de banda sensível disponível na rede.
Apesar da largura de banda corresponder a uma faixa de
frequência fixa, a taxa de transmissão é alterada de acordo
com diversas variáveis, entre elas a quantidade de downloads.
Enquanto as requisições de downloads gerarem um consumo
na rede menor que a largura de banda disponível nenhum
usuário irá competir e atrapalhar a atividade do outro. À
medida que o número de downloads aumente o tempo de
download de um arquivo irá aumentar.
n
S (t )= ∑ F (t )
TABELA 1
COMPARAÇÃO ENTRE VÁRIOS MEIOS DE COMPARTILHAMENTO DE ARQUIVOS
Questões
1. Necessita de um Servidor?
2. Necessita de um
administrador de rede:
3. Gerencia a admissão de
downloads duplicados?
4. Transparente para o
usuário?
5. Transparente quanto a
localização de rede?
6. Ponto único de falha?
7. Gerencia o download sobdemanda em tempo real?
FTP
Sim
Sim
Web Cache
Sim
Sim
Squirrel
Não
Não
Ourdown
Não
Não
Não
Não
Sim
Sim
Sim
Não
Parcialmen
te
Parcialmen
te
Não
Sim
Sim
Sim
Não
Sim
Não
Não
Não
Não
Sim
Não
(2)
0
III. SISTEMAS COLABORATIVOS E MODELAGEM
A Fig. 1 apresenta um modelo básico de uma rede local de
uso genérico.
Figura 1. Duplicação de Download.
Em uma extremidade da rede se encontram os usuários
que neste contexto são os responsáveis pelos downloads.
Entende-se neste modelo que os usuários utilizam de diversos
tipos de equipamentos (computador, notebook, smartphones e
outros) para realizar o download. As redes locais (LAN) não
A Fórmula 2 apresenta a somatória total de tempo gasto
na rede com todas as transmissões:
São variáveis da Fórmula 2:
 t denota o tamanho do arquivo;
 0 e n limites, 0 instante inicial e n tempo final;
 t denota o tamanho do arquivo.
Existem várias técnicas de suprir a demanda por banda
em uma rede de computadores. Uma visão mais simples e
estática é o aumento de recursos de rede, como p. ex.: enlaces
mais velozes. Porém esta medida gera um ciclo vicioso, uma
vez que o aumento de largura de banda provoca
proporcionalmente o aumento na demanda gerando um círculo
vicioso, mais banda mais consumo.
Neste campo de estudo, nas últimas décadas pesquisaramse várias maneiras de gerenciar os enlaces de rede. Dentre
diversas abordagens a Arquitetura DiffServ se destaca.
Arquitetura dos Serviços Diferenciados (DiffServ) [18,19,20]
posiciona entre o serviço padrão da Internet (BestEffort Serviço de Melhor Esforço) e a Arquitetura IntServ (Serviços
Integrados) [21]. DiffServ e IntServ são arquiteturas baseadas
no conceito de QoS (Quality of Service) e são abordagens
fundamentadas no controle do uso da rede baseadas na
sinalização do tráfego para prover garantias na rede, dentre ela
a largura de banda.
Merece destaque que a proposta deste trabalho
diferentemente das Arquiteturas IntServ e DiffServ está
baseada na colaboração invés da concorrência que as outras
146
arquiteturas promovem. Neste contexto o projeto adota o
paradigma da colaboração.
Existem várias teorias e modelos de colaboração, entre elas
Teorias dos Jogos, a Teoria da Atividade, o Modelo 3C de
colaboração, Padrões de Colaboração e o Modelo Tuckman.
Teorias e modelos são utilizadas para entender, comparar,
abstrair e generalizar o ambiente e os cenários nos quais
elementos colaborativos estão inseridos [22]. Dentre os vários
modelos, este projeto alinha-se a ideia do Modelo 3C. O
Modelo 3C é esquematizado na relação entre as ações de:
comunicar, cooperar e coordenar. A seguir, estas três ações
são identificadas no Modelo Conceitual do Projeto Ourdown.
Figura 2. Cooperação entre os componentes.
Segundo a Fig. 2, nota-se que a rede é adicionada com
novas funcionalidades incorporadas na máquina do usuário
para o gerenciamento de downloads. A dinâmica da rede é
alterada para que antes do início do download haja uma
interação entre os componentes distribuídos. Cada
componente é construído de várias funcionalidades sendo
realizadas em paralelo e em comum dentre todos.
Uma grande diferença entre as Fig. 1 e a Fig. 2 está na
quantidade de arquivos “Arquivo A” transmitida da rede
externa (Internet) para a rede local (LAN). Uma vez que o
novo ambiente proposto neste projeto comporta-se como
esperado as requisições duplicadas de um mesmo arquivo
serão canceladas e o requisitante aguardará o download de
quem iniciou primeiramente o arquivo. Importante ressaltar
que no mercado atual, a largura de banda comum entre o
Gateway e a rede externa é da grandeza dos kilobits por
segundo (Kbps) ou megabits por segundo (Mbps), enquanto as
redes locais (LAN) operam na grandeza dos gigabits (Gbps)
por segundo.
3.1 Objetos do Componente
Após uma visão geral do projeto, onde se focou na
vantagem desta abordagem em relação ao modelo tradicional
de download, além da demonstração simples da modelagem
matemática do sistema, esta seção apresenta a proposta
computacional de modelagem de objetos utilizados na
implementação dos componentes.
Figura 3. Objetos do Componente.
O componente (ver Fig. 3) atua como servente e assume os
papeis de cliente e servidor. O componente pode ser
decomposto em várias partes, são elas: WebServer,
WaitingFile, UDPServer e o Downloader. A Fig. 3 apresenta o
componente, seus principais objetos e sua localização no
ambiente. Na figura observa-se que o componente tem acesso
a LAN e a Internet ao mesmo tempo. Nos quatro parágrafos a
seguir são delineadas as funcionalidades de cada um.
WebServer é responsável pela captura do início de um
download, existem várias possibilidades tecnológicas para esta
detecção. Na seção 4 é desvendada a técnica adotada no
desenvolvimento do componente neste projeto. Uma vez
detectado o início de um download é necessário extrair o
nome do arquivo, sua localização e salvar as informações para
uso futuro.
O WaitingFile (ver Fig. 3) tem a função de entrar em
contato com os outros componentes para descobrir se outro
componente realiza o download do arquivo requisitado pelo
usuário. A taxa de requisição pode ser maior que a taxa de
download realizado pelo sistema, assim, há necessidade de
armazenar as requisições em um buffer e tratá-las
sequencialmente.
Caso nenhum componente na rede esteja realizado o
download do arquivo requisitado, o Downloader inicia o
download pela Internet. Esta tarefa implica em atualização de
variáveis locais para sinalizar esta ação.
A qualquer momento um componente pode receber uma
mensagem de outro componente questionando pela existência
do download de um arquivo. Se o componente que recebe a
mensagem realiza o download do arquivo desejado este deve
enviar uma mensagem ao componente que fez o
questionamento. O UDPServer é o responsável por esta tarefa,
de enviar um arquivo local a outro componente na rede.
Neste contexto, há um protocolo de alto nível e as
mensagens enviadas pelos componentes são: a) Mensagem de
Requisição e b) Mensagem de Resposta. A Mensagem de
Requisição é enviada para todos os componentes contendo o
nome e a localização do arquivo desejado, após o envio desta
mensagem o componente aguardará um timeout, quando este
timeout esgota o próprio componente inicia o download, ou
seja, não aguarda mais nenhum tempo por espera. A
Mensagem de Resposta é uma mensagem unicast enviada
diretamente para quem originou o pedido, o componente que
originou o pedido após receber a mensagem de resposta deve
aguardar o envio do arquivo.
Alguns objetos contidos no componente (ver Fig. 3) são
assíncronos e outros são síncronos.
O WEBServer é
assíncrono, ele intercepta uma requisição a qualquer momento,
147
uma vez interceptado ele armazena a requisição em um buffer,
as requisições são feitas diretamente pelo usuário e são
guardas para futuras requisições despachadas na rede local. O
WaitingFile responsável por enviar as mensagens de
requisições na rede é síncrono, ele aguarda um intervalo de
tempo e caso não receba uma reposta sinaliza ao Downloader
a realizar o download, que consequentemente também é
síncrono.
3.2 Diagrama de Classe
Segundo os requisitos do sistema e o modelo do
componente (seção 3.1), o sistema projetado é composto de
cinco classes principais e mais duas classes auxiliares. A Fig. 4
apresenta a relação entre elas.
Uma vez sinalizado o envio pelo outro componente na rede é
criado um objeto da classe ReceiveFile para receber o arquivo.
Portanto, observa-se a possibilidade e a preocupação de
recebimentos simultâneos na rede. A classe ReceiveFile
também é uma generalização da classe Thread.
Downloader é a classe responsável por realizar o download
de um arquivo da Internet. Seu método principal é uma rotina
circular de checagem do vetor FilaDownloads, quando o vetor
esta vazio o objeto desta classe é bloqueado (Thread.wait()).
Se o vetor contiver elementos, cada elemento representa uma
requisição dispara pelo Usuário que não foi atendida pelos
outros componentes, entretanto este elemento descreve o
arquivo a ser obtido da Internet.
UDPServer é a classe que modela o comportamento do
objeto responsável por escutar da rede local pedidos de
download. Seu método principal apenas abre uma porta de
comunicação UDP e aguarda a chegada de pacotes de
broadcast. Uma vez recebido um pacote a mensagem é
extraída e analisada. A análise consiste em procurar no vetor
FilaDownloads se o arquivo requisitado faz parte da lista de
arquivos obtidos pelo Downloader, se sim então é extraído do
pacote o endereço de comunicação do requerente e salvo no
vetor de FilaPedidos para futuro processamento.
3.3 Diagramas de Sequência
A seguir são apresentados dois diagramas de sequência
ilustrando a interação entre os objetos dos componentes.
Figura 4. Diagrama de classes.
A classe Componente é a classe principal que possui o
método para o início da execução da aplicação. Esta classe é
composta por quatro objetos, cada um da classe WebServer,
WaitingFile, Downloader e UDPServe. Todos os quatro
objetos associados são únicos e executados em paralelo,
portanto as classes são especializadas da classe Thread. Por
questão de clareza da Fig. 4 a não apresenta estas
generalizações.
A
classe
Componente
possui
dois
vetores:
FiladeDownloads e FiladePedido. O vetor FiladeDownloads
é utilizado para armazenar as requisições disparadas pelo
usuário. O vetor FilaPedidos é utilizado para armazenar as
requisições enviadas pelos componentes da LAN e que serão
atendidas. Os quatro parágrafos a seguir explicam a
responsabilidade de cada uma das classes (ver Fig. 4).
WebServer é a classe responsável pela implementação da
interação entre as interfaces de detecção do evento do
downnload e o componente. Sua outra função é de registrar as
requisições para futuro processamento, por fim, é de sua
responsabilidade enviar uma mensagem ao usuário avisando-o
do sucesso da operação. Como há possibilidade do disparo de
várias requisições de downloads pelos usuários a classe
WebServer cria um objeto da classe WebClientRequest .
WaitingFile é a classe responsável pela recepção de um
arquivo antes requisitado e prometido por outro componente.
Figura 5. Diagrama de sequência de um pedido de um Arquivo.
O diagrama de sequência (Fig. 5) apresenta a sequência de
mensagens entre os elementos. O Navegador e o WebServer se
encontram no mesmo host. O UDPServer é o objeto
pertencente a outro componente de outro host.
Entre o WebServer e o UDPServer está a LAN que neste
diagrama representa simplesmente uma rede local de
computadores. Esta figura representa a fase inicial de um
pedido e os passos até que o pedido seja enviado de um
componente para a rede e da rede para outro componente.
Após o recebimento de um pedido pelo UDPServer outra
sequência de mensagens é realizada, ver Fig. 6.
148
Figura 6. Diagrama de sequência do recebimento de um arquivo.
Após a recepção de um pedido, o UDPServer (ver Fig. 5)
verifica se faz o download do arquivo requisitado, se sim ele
armazena o pedido e envia uma mensagem avisando que está
fazendo o download. Neste caso, o outro componente não irá
iniciar o download e aguardará o envio pela rede local. Se
nenhum UDPServer espalhado na rede local responder o
Downloader entrará em ação.
O Downloader é responsável pelo download do arquivo
pela Internet. Após o fim do download ele deve pesquisar os
pedidos enfileirados e transmitir o arquivo para o WaitingFile
que se encontra em outro host. O WaitingFile fica aguardando
o envio e após a conexão ele cria o objeto ReceiveFile para
cada envio, uma vez que pode existir a transmissão de várias
fontes diferentes e de arquivos diferentes. Na Fig. 6 apresenta
o objeto Internet para ilustrar a Internet, na verdade não há um
componente de software Internet. Os diagramas de sequencia
Fig. 5 e Fig. 6 mostram a série de mensagens e o
envolvimento de vários objetos na rede.
Esta seção apresentou os principais aspectos funcionais do
modelo de classes e a interação entre elas, a seguir na seção 4
apresenta-se os aspectos tecnológicos para implementação
deste modelo.
IV. TECNOLOGIAS E INFRAESTRUTURA DE REDE
Após a modelagem do sistema, das classes e suas
respectivas funcionalidades, das relações e dependências, o
próximo passo do projeto consiste na implementação. Neste
ponto, várias tecnologias foram avaliadas e nesta seção
apresentam-se as tecnologias preteridas na fase inicial que se
encontra o trabalho. Na seção 5 é apresentada a JXTA como
outra tecnologia no, sua adição só foi possível através de
experimentos realizados com as ferramentas apresentadas
nesta seção.
4.1 Firefox
O navegador Web, ou browser, permite ao usuário acessar o
conteúdo presente em outras máquinas, o usuário requisita o
conteúdo através de um endereço e por meio deste é iniciada
uma conexão com a outra máquina, alem da visualização de
páginas utiliza-se o navegador para download de arquivos.
Existem várias técnicas para capturar o início do download,
uma alternativa é alterar o comportamento do Sistema
Operacional, esta alternativa envolve uma codificação
particular para cada Sistema Operacional. Afim de uma
independência do Sistema Operacional projetou-se um
componente para o Firefox[17]. O Firefox permite à adição de
complementos que alteram seu comportamento padrão, além
desta flexibilidade a vantagem dele ser gratuito foi
fundamental na escolha.
O Firefox é escrito com a linguagem de marcação XUL
desenvolvida pelo próprio Mozilla. Firefox é um software
livre de código aberto, todavia o usuário poderá alterar suas
características e funcionamento através de extensões.
De acordo com o Mozilla [15] as extensões do Firefox, são
pacotes contendo arquivos que podem modificar o
comportamento e a interface do Firefox. Podem ainda
monitorar eventos do browser, como por exemplo, o clique do
mouse sobre algum link. As extensões assim como o próprio
navegador são codificadas com a linguagem XUL.
A extensão é um arquivo composto por documentos que
descrevem seu funcionamento e contem um arquivo manifesto
o qual o Firefox sabe sobre uma extensão e o que deve ser
instalado. Também uma extensão possui a pasta chrome na
qual estão inseridos os conteúdos que personificam a
aparência, idioma e scripts em JavaScript que definem o
funcionamento.
Para que o WebServer (seção 3.1) identifique uma
requisição a partir do browser foi codificado um componente
para o Firefox. É utilizado o AJAX para prover a comunicação
entre o browser e o objeto WebServer.
4.2 Java e Sockets
A codificação do componente foi feita por meio da
plataforma de desenvolvimento Java. A linguagem Java foi
escolhida por apresentar facilidade na programação para
Internet, suporte a Threads, controle de concorrência e
paralelismo e suporte a Sockets TCP e UDP. Além destas
vantagens focadas no projeto a linguagem Java se destaca por
ser robusta, flexível, e suportar mobilidade e portabilidade.
A portabilidade é de suma importância para o projeto. A
possibilidade de construir o componente e o mesmo ser
executado em diferentes Sistemas Operacionais vai ao
encontro da natureza distribuída dos componentes.
Sockets em redes de computadores são abstrações de canais
de comunicação, todo servidor que deseja ser acessado deve
criar Socket Server.
Uma vez criado um Socket Server este pode ser acessado
por outro programa que inicie um Socket com o servidor. A
conexão é formada por uma dupla de sockets, o do cliente e do
servidor. A dupla de sockets é caracterizada por uma quádrupla
formada por endereço IP de origem e endereço IP de destino,
porta de origem e porta de destinos.
Neste projeto algumas portas foram pré-definidas para a
criação de sockets. A Fig. 7 é início do Arquivo Configure.java
retirado do projeto.
149
public class Configure{
static int portOurDownWebServer = 2121;
static int portOurDownWaitingFil = 2222;
static int portOurDownWaitingFil = 9000;
}
Figura 7. Arquivo Configure.java.
Nota-se que no arquivo é definido o identificador de três
portas de rede. A porta TCP 2121 é utilizada para o Navegador
enviar uma requisição ao WebServer. A porta TCP 2222 é
utilizada pelo WaitingFile para receber a sinalização do envio
de um arquivo. E por fim, a porta UDP 9000 é utilizada para
envio de datagramas multicast.
desconhecido o datagrama é enviado para o endereço de
broadcast da rede. O código a seguir mostra esta tarefa:
ds = new DatagramSocket();
byte[] bufout = new byte[1024];
DatagramPacket dp = new DatagramPacket(bufout, bufout.length);
bufout = ("PEDIDO:" + request).getBytes();
dp.setData(bufout);
dp.setAddress(
InetAddress.getByName("255.255.255.255"));
dp.setLength(bufout.length);
dp.setPort(Configure.portOurDownUDPServer);
ds.send(dp);
V. DESENVOLVIMENTO E CODIFICAÇÃO
5.1 Componente no Firefox
Todo o processo da construção do componente para o
Firefox é extenso. Abaixo é apresentado o código do arquivo
browser.xml responsável pela mudança visual do Firefox
quando se clica com o botão direito encima de um link.
<overlay id="ourdown"
xmlns="http://www.mozilla.org/keymaster/gatekeeper/there.is.only.xul">
<script src="ourdown.js" />
<popup id ="contentAreaContextMenu">
<menuitem label="OurDown" oncommand="linkTargetFinder.run()"/>
</popup>
</overlay>
A incorporação do código acima no componente faz que ao
clicar com o botão direito do mouse construa um “menu” com
a opção Ourdown como mostrado na Fig. 8.
O código acima mostra a construção de um datagrama
representado pelo objeto Java dp. O método setAddress é
utilizado para armazenar o endereço de destino
255.255.255.255. Este número representa o endereço de
broadcast numa rede local. O código elucida uma parte
importante do funcionamento do componente WebServer
responsável pelo envio do datagramas UDP em broadcast na
rede local. Esta solução implica que o código é dependente da
Arquitetura TCP/IP e seu escopo de atuação restringe a uma
rede local, uma vez que os datagramas UDP de broadcast são
descartados nos roteadores.
O artifício utilizado para enviar uma mensagem para todos
os componentes da rede é uma característica particular da
camada de rede da Arquitetura TCP/IP. Assim, este código
depende de como a camada de rede trata os datagramas com
endereço de broadcast. O uso do UDP também se fundamenta
por ser um protocolo com baixo overhead de rede e preferível
em relação ao TCP neste aspecto.
VI. NOVO CÓDIGO COM JXTA
Figura 8. Imagem da opção Ourdown no menu do Firefox.
O arquivo ourdown.js contido no complemento possui a
função do envio da requisição via AJAX. O trecho abaixo
mostra este processo.
...
try
{
// Firefox, Opera 8.0+, Safari
xmlHttp=new XMLHttpRequest();
}
catch (e)
...
xmlHttp.open("GET","http://localhost:2121?="+arquivo,true);
xmlHttp.send(null);
...
O método open do objeto xmlHttp faz uma conexão para a
porta 2121 cujo destino é a própria máquina. Antes do uso do
componente do Firefox é necessária a instalação da outra parte
do sistema responsável pela recepção destas conexões. A
conexão mostrada no código acima é um recurso do Javascript
muito utilizado em requisições AJAX.
5.2 Componente UDPServer
A mensagem
destinada a todos os componentes é
encapsulada por um datagrama UDP, como o destino a priori é
Toda codificação do componente, incluindo as classes
WebServer, WaitingFile, UDPServer e Downloader está em
processo de alteração para funcionar segundo a plataforma
JXTA. O objetivo é aprimorar o projeto com novos recursos
providos por esta plataforma [24].
JXTA cujo significado é juxtapose (unidos), é um conjunto
aberto de protocolos específicos para construção de redes
Peer-to-Peer que permite qualquer dispositivo de rede, tais
como: sensores, smartphones, notebooks e servidores,
comunicarem-se mutuamente como seus parceiros. O
protocolo JXTA é independente de linguagem de
programação, porém Java possui pacotes para suporte ao
JXTA.
A substituição da API Socket Java por JXTA foi orientada
ao desejo de tornar o projeto mais interoperável, independente
de plataforma, independe de arquitetura de rede e a
possibilidade de construir serviços mais ubíquos. Várias
funções implementadas neste projeto, tais como: descoberta de
componentes, organização em grupo, aviso e descoberta de
recursos (neste caso arquivos compartilhados), comunicação
entre eles, e monitoração da rede será suprida pelo JXTA,
resultando na diminuição da codificação.
VII. CONSIDERAÇÕES FINAIS E TRABALHOS FUTUROS
Ourdown é um sistema distribuído cuja função é exercida
cooperativamente por componentes constituídos de objetos
150
com funções bem definidas. Seu propósito geral torna a rede
local de computadores conscientes da dinâmica de download
de forma descentralizadas. A descentralização está em
consonância com o novo modo de utilização pelos os novos
usuários acostumados com o compartilhamento e a
descentralização de serviços.
Este artigo apresenta um novo modelo de gerência de
download cuja sua vantagem foi formalmente apresentada. O
projeto apresenta um paradigma que rompe com o modelo
tradicional de download. A forma tradicional de downloads
não tira aproveito da grande diferença entre a largura de banda
das redes LAN em relação às WANS e não preocupam com o
download enquanto estão ocorrendo.
Este artigo relata a fase inicial do projeto desenvolvido
sobre o aval do programa de Iniciação Científica da
Universidade
Federal
do
Piauí
(ICV 2012/2013
UFPI/CSNHB). Descreve várias etapas do projeto ressaltando
a concepção, a modelagem, e a codificação. Quanto à
codificação destacaram-se algumas partes cruciais do código
para execução do sistema, entre elas a componentização para o
Firefox, a interceptação de downloads e a comunicação em
broadcast via UDP.
Durante o desenvolvimento do código novos requisitos
surgiram e serão implementados no decorrer do período do
ICV 2012/2013. Dentre os principais requisitos levantados
são: a) adicionar aspectos de segurança na comunicação entre
os componentes; b) estabelecer o conceito de grupos para
restringir as mensagens na rede; c) permitir a busca de
downloads ativos através de coringas de pesquisa de nomes,
endereços e estados; d) implementar um sistema de cache
local nos componente para que os mesmos executassem o
papel de proxy de cache; d) adicionar a possibilidade de
cooperação para downloads simultâneos de um mesmo
arquivo, pois a atual codificação implica que um componente
deve aguardar o encerramento do download para que o mesmo
seja retransmitido na LAN; e) Atualmente existe apenas o
componente Ourdown para o Firefox, almeja-se desenvolver
para outros navegadores, especialmente o Google Chrome.
A plataforma JXTA foi escolhida em substituição de API
Socket do Java por permitir que as novas funcionalidades
segundo os requisitos levantados possam ser implementados
com maior agilidade, pois muitas das funcionalidades já estão
embutidas no JXTA, entre elas: agrupamento de componentes,
segurança e comunicação em grupo.
Assim que o sistema adquirir maior estabilidade, robustez e
interfaces mais amigáveis deseja-se sua distribuição
gratuitamente. O intuito é a divulgação do curso de Sistema de
Informação da Universidade Federal do Piauí como produtora
de softwares inovadores e assim fomentar o interesse na área
de pesquisa, desenvolvimento e empreendedorismo na região.
REFERÊNCIAS
[1]
[2]
[3]
VEJA. Abril, 2011, ISBN 2221, Ano 44, publicada em 15 jun.
2011.
IWS.
Internet
World
Stats,
Disponível
em:
http://www.internetworldstats.com, acessado em 10 ago 2012.
SOARES, Luiz Fernando G. Redes de Computadores: Das
[4]
[5]
[6]
[7]
[8]
[9]
[10]
[11]
[12]
[13]
[14]
[15]
[16]
[17]
[18]
[19]
[20]
[21]
[22]
[23]
[24]
LANs,MANs e WANs às Redes ATM. 2ª Edição. Rio de Janeiro:
Elsevier, 1995.
TANENBAUM, A. S. Sistemas Distribuídos: princípios e
paradigmas. 2ª Edição. São Paulo: Pearson Prentice Hall, 2007.
IDM, Disponível em http://www.internetdownloadmanager.com.
ORBIT,
Disponível
em
acessado
em
01/08/2012.
http://www.orbitdownloader.com/br/index.htm, aces. em 10 ago.
2011.
JDOWNLOAD, Disponível em http://jdownloader.org/ , acessado
em 10 ago. 2011.
DEITEL, H. M. Java TM: como programar. 6ª Edição. São Paulo,
Pearson Prentice Hall, 2005.
FUNDAÇÃO MOZILLA. Disponível em: http://www.mozilla.org
Acesso em: 10 out. 2011.
OAKS SCOTT, Travaset Bernard, Gong Li, JXTA in a Nutshell,
O'Reilly, 2002.
TANENBAUM, A. S. Redes de Computadores. 4ª Edição. Rio de
Janeiro: Elsevier, 2003
POSTEL. J e REYNOLDS J. File Transfer Protocol (FTP), RFC
977, fev. 1986. http://www.rfc-editor.org/rfc/rfc977.txt.
KUROSE J. F. e Ross K. W. Redes de Computadores e a Internet,
Pearson: São Paulo: 2004.
CLAFFY K., MILLER G. E THOMPSON K. The Nature of the
Beast: Recent Traffic Meassurement from an Internet Backbone.
Proceedings
of
Inet`98.
Geneva,
jul.
1998.
http://www.caida.org/outreach/resources/papers/Inet98/.
Squid Web Proxy. Disponível em: http://www.squid-cache.org.
Acessado em: 04 nov 2012.
Sitaram Iyer, Antony Rowstron, and Peter Druschel. 2002.
Squirrel: a decentralized peer-to-peer web cache. In Proceedings of
the twenty-first annual symposium on Principles of distributed
computing (PODC '02). ACM, New York, NY, USA, 213-222.
DOI=10.1145/571825.571861
http://doi.acm.org/10.1145/571825.571861
Hari Balakrishnan, M. Frans Kaashoek, David Karger, Robert
Morris, and Ion Stoica. 2003. Looking up data in P2P systems.
Commun.
ACM
46,
2
(February
2003),
43-48.
DOI=10.1145/606272.606299
http://doi.acm.org/10.1145/606272.606299
Almesberger, W., Salim, J., Kuznetsov, A., and Knuth, D. (1999).
“Differentiated Services on Linux”. Tecnical Report ietf internet
draft,
Internet
Enginnering
Task
Force.
URL
at
http://www.almesberger.net/cv/papers/18270721.pdf.
Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z., and Weiss,
W. (1998). “An architecture for Differentiated Services ”.
Tecnhinal Report RFC 2475, Internet Engineering Task Force.
URL at http://www.ietf.org.
Nichols, K., Blanke, S., Baker, F., and Black, D. (1998).
”Definition of the Differentiated Services Field (DS Fiel d) in the
IPv4 and IPv6 Headers”. Tecnhinal Report RFC 2474, Internet
Engineering Task Force. URL at http://www.ietf.org.
Braden, R., Clack, D., and Shenker, S. (1994). “Integrated Services
in the Internet Architecture: an Overview”. Tecnhinal Report RFC
1633, Internet Engineering Task Force. URL at http://www.ietf.org.
Pimental M, Fuks H, et al, Sistemas Colaborativos, Rio de Janeiro:
Elsevier, 2011.
MDN. Disponível em: <https://developer.mozilla.org/pt-BR/>
Acesso em: 10 out. 2011
http://www.jxta.org
Rayner Gomes Sousa possui graduação em Ciência da
Computação pela Fundação Integrada Municipal de Ensino
Superior (1998) e mestrado em Ciência da Computação pela
Universidade Federal de Uberlândia (2005). Atualmente é
Professor Titular da Universidade Federal do Piauí e
Professor Contratado da Universidade Aberta do Piauí. Tem
experiência na área de Ciência da Computação. Atuando
principalmente nos seguintes temas: Internet, Qualidade de Serviço, CORBA,
DiffServ, JXTA e Android.
151
SenseRDF: Towards a Linked Data Conversion
Tool
B. Communications Modeling
A. Silva, N. França, B. Paulino, D. Souza and W. Travassos, Member, Instituto Federal de
Educação, Ciências e Teconologia da Paraíba - IFPB
leitura dos dados conectados semanticamente, de forma
automática, por agentes de software.
Para aplicar essas práticas e alcançar a visão da Web de
Dados, é necessário trabalhar com algumas etapas
básicas: (i) conversão de dados disponíveis em formatos
diversos, como, por exemplo, PDF, XML e HTML, em
modelo de representação padrão RDF; (ii) associação dos
objetos presentes nos diversos conjuntos de dados por
meio de links; (iii) publicação dos conjuntos de dados na
nuvem (Linked Data Cloud) [4] e o (iv) consumo dos
dados publicados por meio de aplicações construídas para
este fim.
Este trabalho abrange a primeira etapa do processo.
Para viabilizar a publicação de dados no padrão Linked
Data, a ferramenta SenseRDF vem sendo desenvolvida
com o objetivo de converter dados atualmente em
formatos PDF e XML em modelos RDF, seguindo os
princípios propostos [4]. Para escolher os formatos a
serem contemplados na primeira versão da ferramenta,
fizemos um estudo dos dados atualmente disponibilizados
no portal do governo brasileiro1. Constatamos que boa
parte deles se encontra em XML e PDF e que existem
ainda poucas ferramentas que contemplam os mesmos [5].
Diante disso, a SenseRDF vem sendo implementada e,
neste artigo, apresentamos a versão que converte arquivos
PDF (seus metadados) em RDF. A ferramenta oferece um
ambiente simples de ser utilizado e permite atualização
dos metadados PDF, caso seja de interesse do usuário. Os
dados (metadados) convertidos atendem aos princípios
formulados no projeto Linked Data: (i) usa URIs para
nomear recursos; (ii) utiliza vocabulários recomendados
para identificar os recursos e (iii) permite que as URIs
sejam acessadas através do protocolo HTTP.
Este trabalho está organizado da seguinte forma: a
Seção 2 introduz a abordagem SenseRDF; a Seção 3
apresenta a ferramenta na prática por meio de exemplos; a
Seção 4 descreve os trabalhos relacionados, e a Seção 5
tece algumas considerações e indica trabalhos futuros.
Abstract— Underlying the development of the Semantic
Web, the project Linked Data aims to define a set of best
practices for publishing and connecting structured data on
the Web with the purpose of creating a Web of Data. To this
end, at first, existing data should be converted to a standard
model in such a way that they can be understood by software
agents and be used by diverse applications. In this light, the
tool named SenseRDF has been developed to allow the
conversion of data in formats such as PDF and XML to a
representation model in RDF. The generated data (in RDF)
follow the Linked Data principles and adhere to commonly
accepted vocabularies.
Keywords — data conversion, Linked Data, vocabularies,
RDF.
I.
INTRODUÇÃO
A
Internet contemporânea, nos moldes da World Wide
Web (ou simplesmente Web), vive um constante
processo de evolução e tem revolucionado a forma como
criamos conteúdo e trocamos informações. A Web
organizou as informações na Internet por meio de
hipertexto e tornou a interação do usuário com a rede
mundial mais amigável. Entretanto, esses conteúdos
publicados normalmente seguem regras apenas sintáticas,
com objetivos de apresentação, não permitindo que se
consiga extrair semântica dos mesmos, nem ligá-los, sem
que para isso seja feito um grande esforço de
implementação. Considerando isso, a Web atual pode ser
classificada ainda como sintática e o processo de
interpretação dos conteúdos disponibilizados fica a cargo
dos usuários [1]. Diante dessa constatação, uma nova
visão da Web vem sendo buscada e tem sido denominada
de Web Semântica (Semantic Web) [2]. Os documentos na
Web Semântica possuiriam, além das informações que
descrevem a estrutura sintática do seu conteúdo, outras
informações que dariam o entendimento semântico a esse
conteúdo.
Como base ao desenvolvimento da Web Semântica,
surgiu o projeto Linked Data que delimita um conjunto de
práticas para publicar e conectar dados estruturados na
Web, com o intuito de criar um espaço global de dados ou
uma “Web de Dados” [3]. Estas práticas são
fundamentadas em tecnologias Web, como HTTP
(Hypertext Transfer Protocol) e URI (Uniform Resource
Identiﬁer), e no uso do modelo RDF (Resource
Description Framework), com o objetivo de permitir a
II.
A ABORDAGEM SENSERDF
A sistemática para disponibilizar dados na Web, segundo o
padrão Linked Data, envolve um processo no qual os dados de
diferentes fontes são selecionados e depois convertidos
1
152
http://dados.gov.br/
para representações em um modelo padrão. Esta
conversão segue o conjunto de princípios estabelecidos,
descritos resumidamente a seguir [4]: (i) o uso de URIs
para identificação dos objetos/recursos; (ii) a utilização de
tecnologias, como RDF2 e SPARQL3, para descrição e
consulta a estes recursos, respectivamente e (iii) o
reaproveitamento de URIs, de forma que seja possível
estabelecer ligações entre os dados disponíveis, com a
finalidade de possibilitar a navegação por meio destas
ligações.
Um desses princípios defende o uso de RDF como
modelo de representação de dados estruturados na Web
[6]. O RDF é um modelo de dados que descreve recursos
ou objetos, ou seja, entidades que possuem uma
identidade na web [6, 7]. Os recursos são descritos como
uma tripla (S, P, O), interpretada como “S possui P com
valor O”, onde S é o sujeito da tripla, designado por um
recurso, P é o predicado da afirmação, designado por um
recurso e O é o objeto da afirmação, designado também
por um recurso ou por um literal [7, 8]. Com o RDF, o
uso de links e de vocabulários recomendados, é possível
descrever significado sobre os objetos ou recursos. Mais
especificamente, um link RDF pode ser uma tripla RDF
em que o sujeito da tripla é uma referência URI no
namespace de um conjunto de dados, enquanto o
predicado e/ou objeto da tripla são referências URI
apontando para o namespace de outro conjunto de dados.
“Derreferenciando” essas URIs, produzimos uma
descrição do recurso vinculado fornecido pelo servidor
remoto. Essa descrição irá geralmente conter um link
RDF adicional que aponta para outra URI que, por sua
vez, pode ser também “derreferenciada”. Isto é como a
descrição de recursos individuais é tecida dentro da Web
de Dados. Isto é também como a Web de Dados pode ser
navegada usando um navegador Linked Data ou rastreado
por um robô de um engenho de busca.
Dentro desse panorama, o objetivo da SenseRDF é
permitir converter dados, a princípio PDF e XML, em
modelo RDF, fazendo uso de informações do domínio dos
dados e referenciando os termos dos vocabulários
pertinentes a este domínio. A Figura 1 apresenta uma
visão geral da arquitetura da ferramenta SenseRDF.
2
http://www.w3.org/RDF/
3
http://www.w3.org/TR/rdf-sparql-query/
Extraçãode
Metadados
Extraçãode
PDF
Instâncias
RDF
GeradorRDF
XML
Identificaçãode
Termos
Identificaçãode
Correspondências
FOAF
Arquivo de
Correspondências
SKOS
Ontologia
Res
DC
Repositório de Vocabulários
Figura 1. Arquitetura da Ferramenta SenseRDF
A ferramenta SenseRDF permite a conversão de dados
em formato PDF e XML. Como forma de prover a
semântica do domínio a partir de terminologias
recomendadas (vocabulários), a ferramenta mantém um
repositório de vocabulários, como, por exemplo, o FOAF 4
e o DC5, além de ontologias de domínio que possam ser
usadas como referência de termos.
Para a conversão, inicialmente a ferramenta identifica
os metadados existentes na fonte de dados de entrada,
metadados estes que podem ser de arquivos PDF ou
XML. Um arquivo PDF contém metadados como Author
e Title, já o XML pode conter diversos tipos que
dependem do criador da fonte. Em seguida, a ferramenta
gera um alinhamento de correspondências entre estes
metadados e os termos (conceitos) existentes nos
vocabulários recomendados. O objetivo do alinhamento é
explicitar relações de similaridade entre os metadados da
fonte de dados e os termos dos vocabulários existentes.
Para os objetivos da ferramenta, estamos buscando
relações de igualdade entre esses termos, para identificar
o que pode ser referenciado dos vocabulários existentes.
O alinhamento é persistido e, a cada novo arquivo a ser
convertido, é verificado se a correspondência entre o
metadado e o termo do vocabulário já existe. Caso não
exista, ela é inserida neste arquivo de correspondências.
Considerando arquivos PDF como fontes de dados,
exemplos de correspondências de igualdade presentes no
alinhamento são:
 Criador  dc:creator
 Autor  res:author
Onde Criador e Autor são metadados de um arquivo
PDF, o prefixo dc é referente ao vocabulário DC (Dublin
Core) e o prefixo res é referente a uma ontologia de
domínio sobre autores de publicações.
Caso não haja nenhum termo de vocabulário
equivalente a um metadado, este poderá ser adicionado a
4
5
153
http://www.foaf-project.org/
http://dublincore.org/documents/dcmi-terms/
uma ontologia existente no repositório. Caso esta
ontologia não exista, ela será criada e armazenada no
repositório para ser utilizada na geração/atualização de
futuros alinhamentos e nas conversões subsequentes.
Depois de extraídos os metadados, as instâncias
(indivíduos), no caso de arquivos XML, são também
extraídas. A ferramenta, então, gera um arquivo RDF que
contém os metadados referenciados por meio dos termos
dos vocabulários e os objetos identificados provenientes
das instâncias extraídas.
Um resumo dos componentes que fazem parte da
arquitetura do SenseRDF é apresentado a seguir:
 Repositório de Vocabulários: repositório onde se
encontram armazenados os vocabulários e
ontologias de domínio que são utilizados pela
ferramenta. Caso seja necessário, o usuário pode
adicionar uma ontologia ou vocabulário
específico de seu domínio.

Arquivo de Correspondências: armazena o
alinhamento obtido no processo de matching
entre os metadados da fonte de dados e os termos
dos vocabulários existentes.

Extração de Metadados: extrai os metadados da
fonte de dados escolhida pelo usuário.

Extração de Instâncias: é usado no caso do
usuário escolher uma fonte de dados XML. Este
módulo extrai os dados (instâncias ou
indivíduos) existentes na fonte de dados.

Identificação de Correspondências: gera ou
atualiza um alinhamento de correspondências
entre os metadados da fonte de dados e os termos
existentes nos vocabulários recomendados.

Identificação de Termo do Vocabulário: usando
as correspondências identificadas, este módulo
referencia um metadado da fonte quanto ao seu
termo correspondente no momento da geração do
RDF.

Geração RDF: módulo principal que recebe os
termos identificados nas correspondências, os
metadados e as instâncias da fonte de dados,
gerando assim um RDF final.
III.
A FERRAMENTA SENSERDF NA PRÁTICA
SenseRDF contempla todo o processo de conversão para
arquivos PDF. A conversão é realizada sobre seus
metadados e um link para o arquivo é mantido. Como
nem sempre um arquivo PDF é criado definindo os seus
metadados (isso não é uma prática comum), a ferramenta
permite que o usuário defina um conjunto mínimo de
metadados para o arquivo em questão. O usuário pode
atualizar os mesmos também. Nesta seção, apresentamos
a ferramenta, de forma prática, por meio de exemplos,
considerando arquivos PDF.
A Figura 2 apresenta a interface da SenseRDF que
mostra algumas de suas opções: (I) campo para
identificação do arquivo (pode ser um arquivo em disco
ou uma URL indicando o mesmo); (II) área de exibição
dos metadados do arquivo, que podem ser alterados no
caso de arquivos PDF (como mencionado, nem sempre os
arquivos PDF originais possuem metadados); (III) opção
de geração de RDF - o usuário pode escolher entre gerar o
RDF em sintaxe XML ou em N3 e (IV) área onde será
exibido o RDF gerado.
A ferramenta SenseRDF foi implementada em
linguagem Java, utilizando as APIs Jena6, JDOM7, Itext8,
Alignment API9 e OWL API10. A primeira versão da
6
http://jena.apache.org/
http://www.jdom.org/
8
http://api.itextpdf.com/
9
http://alignapi.gforge.inria.fr/align.html
10
http://owlapi.sourceforge.net/
7
154
Figura 2. Interface da SenseRDF com algumas Opções
Dessa forma, quando um alinhamento é gerado ou
atualizado, obtemos correspondências com diferentes
níveis de similaridade. Isso é reportado através de uma
medida de confiança. Neste exemplo, temos uma
correspondência com medida igual a 1.0 que indica, com
precisão, uma equivalência entre o metadado e o termo. A
medida 0.86 indica um grau de similaridade muito alto.
Realizando testes, percebemos que asjk correspondências
com medida acima de 0.8 indicam equivalência entre os
termos. Utilizamos então este threshold, para limiar a
identificação das correspondências de equivalência.
Assim, nesta versão, aquelas correspondências com
Como a ferramenta precisa das correspondências entre
os metadados e os termos dos vocabulários, antes de gerar
o RDF, ela cria ou atualiza o alinhamento existente.
Para isso, ela usa um processo de matching que faz
uma análise linguística [9] e verifica a proximidade dos
nomes dos metadados do arquivo PDF e os nomes dos
termos dos vocabulários (diferença de apenas alguns
caracteres, análise de possíveis radicais, etc). O
alinhamento gerado é 1:1 e indica um grau de
similaridade (medida de confiança) entre os elementos
associados. Um fragmento do alinhamento de
correspondências é mostrado como exemplo na Figura 3.
Figura 3. Fragmento do Alinhamento obtido entre os Metadados e os Construtores dos Vocabulários.
155
threshold acima de 0.8 são definidas como equivalência
entre o metadado e o termo.
Caso algum metadado não possua termo equivalente, a
ferramenta solicita do usuário que selecione nos
vocabulários existentes algum termo que possa ser usado
(Figura 4). Se não existir um compatível, a ferramenta
gera este novo termo adicionando o mesmo a uma
ontologia no repositório. Para isso, o usuário marca que
não encontrou nenhum termo correspondente ao
metadado exibido. Este novo termo será adicionado a uma
ontologia “othersTerms”, que incorpora os termos que
não pertencem aos vocabulários existentes. O usuário
indica a que superclasse deve ser vinculada este novo
termo ou conceito (subclasse).
Figura 5. Exemplo de RDF gerado em Sintaxe XML.
Figura 4. Seleção de Termos de Vocabulários para Correspondência com
Metadados.
Para geração do RDF, a ferramenta lê o alinhamento
de correspondências, para que sejam identificados os
termos dos metadados da fonte. Com os metadados e
termos de referência em mãos, de acordo com a opção de
sintaxe RDF escolhida pelo usuário (RDF/XML ou N3), a
ferramenta gera o RDF final, como mostrado na Figura 5
(em XML) e na Figura 6 (em N3).
Figura 6. Exemplo de RDF Gerado em sintaxe N3.
IV.
TRABALHOS RELACIONADOS
Para a publicação de dados RDF, podem ser usadas
ferramentas específicas de conversão. Atualmente,
existem ferramentas para conversão de planilhas, arquivos
CSV, dados relacionais e outros documentos [10]. Um
exemplo é a ferramenta ConvertToRDF [11],
desenvolvida pela MINDSWAP (Maryland Information
and Network Dynamics Lab Semantic Web Agents
Project) que tem como principal objetivo converter
arquivos em formato XLS para RDF. A aplicação permite
ao usuário executar o mapeamento através de uma
ontologia própria da ferramenta, mas também permite o
uso de outras ontologias para utilização nos
mapeamentos. A ferramenta demonstra ser limitada na
156
automação, uma vez que exige que o usuário faça todo o
mapeamento manualmente, sem possuir um repositório
que armazene estes mapeamentos manuais, para que
possa reutilizá-los mais tarde. Outro exemplo de
ferramenta é A TopBraid Composer [5] que oferece
editores gráficos visuais para RDF e diagramas de classe,
incluindo a capacidade de gerar consultas SPARQL. Ela
também permite a conversão automática de XML, XSD,
Excel, UML e outras fontes de dados.
Há também o DBpedia [12], um projeto colaborativo
que extrai dados do Wikipedia e os converte em dados
estruturados usando o padrão RDF. O DBpedia está
disponível, permitindo aos usuários utilizar e colaborar
com o enriquecimento de seu repositório de datasets. A
TripFS [13] é uma ferramenta que representa os diretórios
e arquivos como recursos RDF. TripFS extrai metadados
e cria links para outros conjuntos de dados e fornece um
end-point SPARQL que permite aos clientes executar
consultas sobre o sistema de arquivo inteiro. A Bio2RDF
por outro lado converte documentos da área de
biomedicina [14]. Visa também criar uma nuvem de
dados sobre medicina. Lebo e Williams [15] apresentam
uma abordagem para converter os dados CSV em Padrão
Linked Data, de forma que permita melhoramentos
incrementais. Aplicando esta abordagem, eles foram
responsáveis por converter uma grande quantidade de
dados governamentais dos EUA em RDF.
Apesar dos esforços e das ferramentas existentes, ainda
existe uma demanda não atendida por serviços que
facilitem o processo de conversão de dados,
especialmente aqueles em formato PDF e XML. Em
geral, as ferramentas se concentram no aspecto sintático
da geração RDF, enquanto que a questão semântica,
referente ao uso de anotações ou referências a
mecanismos de controle terminológico (vocabulários), se
torna incompleta. Diante disso, como forma de facilitar a
conversão de dados no contexto brasileiro e buscando
desenvolver uma solução que faça uso da semântica do
domínio dos dados e dos padrões existentes, a ferramenta
SenseRDF foi especificada e vem sendo desenvolvida.
Analisando nosso trabalho e comparando com os
demais, destacamos que, ao converter os metadados PDF
para RDF, nossa ferramenta, com o auxílio do usuário,
identifica termos dos vocabulários existentes no
repositório ou pode também criar novos termos, caso faça
sentido ao domínio dos dados e não exista uma ontologia
ainda para este domínio. Esta nova ontologia é persistida
no repositório e será reutilizada em futuras conversões de
arquivos que pertençam àquele domínio. O conjunto de
ontologias e vocabulários existentes no repositório,
juntamente com as correspondências já identificadas,
automatiza futuras conversões e evita que o usuário tenha
que fazer as correspondências entre metadados e termos
de vocabulários manualmente. Assim, novas conversões
serão mais rápidas e precisas. Nossa ferramenta também
se diferencia por estar sendo desenvolvida de modo a
permitir a conversão de dados disponibilizados pelo
governo brasileiro em seu portal.
V.
CONSIDERAÇÕES E TRABALHOS
FUTUROS
Este trabalho apresentou a ferramenta de conversão de
dados denominada SenseRDF. A SenseRDF provê um
ambiente intuitivo e transparente onde o usuário escolhe
formatos de fontes de dados que deseja converter para o
modelo RDF segundo o padrão Linked Data. Para isso, a
ferramenta utiliza um processo de matching que gera um
alinhamento de correspondências entre os metadados da
fonte e os termos existentes nos vocabulários do domínio
dos dados. Utilizando estas correspondências, a
SenseRDF gera o RDF, referenciando os termos
identificados. O resultado pode ser obtido tanto em
RDF/XML quanto no formato N3.
Nesta primeira versão, a ferramenta trabalha com
dados no formato PDF, gerando o modelo RDF apenas
com seus metadados. Encontra-se em andamento a
implementação da opção de arquivos XML, que irá gerar
o modelo RDF tanto para os metadados identificados
quanto para as instâncias (indivíduos). Como trabalho
futuro, a ferramenta será estendida para permitir a
identificação de links entre dois conjuntos de dados RDF
diferentes.
REFERÊNCIAS
[1] Costa A., Yamate F. 2009. Semantic Lattes: uma ferramenta de
consulta baseada em ontologias. Trabalho de Graduação em
Engenharia de Computação - Escola Politécnica. IME/USP.
[2] Berners-Lee T., Hendler J., Lassilia O. 2001. The semantic web.
Scientific American. 284(5):34–44, Mai 2001.
[3] Bizer C., Heath T., Berners-Lee T. 2009. Linked data - the story so
far. Int. J. Semantic Web Inf. Syst. 5(3):1–22, 2009.
[4] Heath, T., Bizer, C. 2011. Linked Data: Evolving the Web into a
Global Data Space (1st edition). Synthesis Lectures on the
Semantic Web: Theory and Technology, 1:1, 1-136. Morgan &
Claypool, 2011.
[5] TopBraid Documentation. Available at
http://www.topquadrant.com/products/TB_Composer.html.
[6] Klyne, G., Carroll, J. J., McBride, B. 2004. Resource description
framework (RDF): Concepts and abstract syntax. DOI=
http://www.w3.org/TR/rdf-concepts/
[7] Lóscio, B., Cunha, D.; Souza, D. 2011. Linked Data: da Web de
Documentos para a Web de Dados. Escola Regional Ceará,
Maranhão e Piauí 2011. Teresina: ERCEMAPI. 2011, v. 1, p. 7999.
[8] Travassos W., Silva A., França N., Dantas R., Souza D. 2011.
RDF, RDF(S) e OWL: Uma Análise Comparativa Visando Atingir
o Padrão Linked Data. In: Anais Ciências Exatas e da Terra do VI
Congresso de Pesquisa e Inovação da Rede Norte e Nordeste de
Educação Tecnológica – CONNEPI. Pg. 413-423. Natal, RN.
157
[9] Euzenat J., 2004. An API for ontology alignment. Proceedings of
of some research projects at UFPE and at the Federal Institute of
Education, Science and Technology of Paraíba (IFPB), Brazil.
His main research interests are concerned with Semantic Web,
Data Quality and Data Conversion.
the International Semantic Web Conference (ISWC), pages 698–
712, 2004.
[10] Auer, S., Dietzold, S., Lehmann, J., Hellmann, S., and Aumueller,
D. 2009 Triplify: Light-weight linked data publication from
relational databases. In Quemada, J., León, G., Maarek, Y. S., and
Nejdl, W., editors, Proceedings of the 18th international
Conference on World Wide Web, WWW 2009, Madrid, Spain,
April 20-24, 2009, pages 621–630. ACM.
[11] ConvertertoRDF Documentation. Available at
http://www.w3.org/wiki/ConverterToRdf.
[12] Kobilarov G., Bizer C., Auer S., Lehmann J. 2009. DBpedia - A
Linked Data Hub and Data Source for Web and Enterprise
Applications. Web Semantics Science Services and Agents on the
World Wide Web. Volume: 7, Issue: 3, Publisher: Elsevier, Pages:
154-165.
[13] Schandl, B., & Popitsch, N. 2010. Lifting File Systems into the
Linked Data Cloud with TripFS. 3º International Workshop on
Linked Data on the Web, Raleigh, North Carolina, USA. DOI=
http://eprints.cs.univie.ac.at/69/
[14] Bio2RDF Documentation. Available at http://bio2rdf.org/
[15] Ding, L., Lebo, T., Erickson, J. S., DiFranzo, D., Williams, G. T.,
Li, X., Michaelis, J., Graves, A., Zheng, J. G., Shangguan, Z.,
Flores, J., McGuinness, D. L., and Hendler, J. 2010. TWC LOGD:
A Portal for Linked Open Government Data Ecosystems. In JWS
special issue on semantic web challenge’10.
Ayrton Nádgel is an undergraduate student at
the Federal Institute of Education, Science and
Technology of Paraíba (IFPB), Brazil. He is
also a member of a research project at IFPB.
His main research interests regard Semantic
Web and Linked Data.
Naftali França is an undergraduate student at
Bruno Paulino is an undergraduate student at
Damires Souza obtained her PhD (doctorate)
in Computer Science from the Federal
University of Pernambuco (UFPE), Brazil. She
is currently an Associate Professor at the
Federal Institute of Education, Science and
Technology of Paraiba (IFPB), Brazil. She is
also the coordinator of some research projects
at IFPB. Her main research interests are concerned with the
areas of databases and semantic web.
Walter Travassos is a master student in
Computer Science at the Federal University of
Pernambuco (UFPE), Brazil. He is a member
158
Utilização de Realidade Aumentada e Dispositivos
Móveis para Auxiliar na Manutenção de Instrumentos
de Medição de Barragens
T.A.Nardi; F. F. F. Peres
Abstract— This paper presents a prototype for a solution using
Augmented Reality (AR) and mobile devices technologies to resolve
a problem occurred in Itaipu, where new employers has no
knowledge about how to do maintenance in old measuring
instruments. The goal is present the system that was proposed, and
show the reported difficulties found in development by the tests in
laboratory,and defining a proposal of how to resolve this
difficulties with the help of knowhow from the technical engineers
ifItaipu.
formas de realizar a identificação de objetos reais (tracker) por
meio desta ferramenta. Por fim a seção VI e VII apresentam
respectivamente as informações sobre o sistema proposto
através da identificação das principais considerações da
construção do mesmo e dos principais aspectos de arquitetura
definidos para construção do mesmo e os resultados obtidos
até o momento. A seçãoVIII apresenta as conclusões obtidas.
II. REALIDADE AUMENTADA
Keywords—Augmented Reality, Mobile Devices, Measuring
Instruments.
I. INTRODUÇÃO
E
M canteiros de obras e construções de barragens de
concreto e enrocamento existe uma preocupação constante
com o estado do solo, de sua fundação principalmente por
questões de segurança. Para isto a engenharia utiliza de
diversos recursos para realizar monitoramento constante do
solo através de instrumentos que medem vibrações,
deslocamentos, densidade, etc[1]. Em Itaipu, funcionários
necessitam realizar manutenções em diversos instrumentos de
mediçãonecessitando de conhecimento para tal. Estas
manutenções são, muitas vezes, com periodicidade longa e
podem envolver a troca de peças caras, sendo que seu
manuseio correto é muito importante para não danificar a peça
e encarecer a manutenção. Para diminuir tal problema Itaipu,
através da gestão de conhecimento, procura formas para
disseminaro conhecimento aos novos funcionários.
Este artigo apresenta estudos realizados sobre a tecnologia
de realidade aumentada e dispositivos móveispara elaboração
de sistemas para auxiliar a manutenção de extensômetros de
haste múltipla, um dos instrumentos utilizados para medição
em barragens.
Sendo assim este artigo apresenta na seção II, informações
sobre a tecnologia de realidade aumentada, informando seus
principais elementos e aplicações. A seção III apresenta
informações de uso dos extensômetros de haste múltipla, em
Itaipu, alvo do estudo de casos deste artigo. A seguinte (seção
IV) diz a respeito da construção de sistemas de realidade
aumentada em dispositivos móveis, trazendo informações
sobreo Android e sobre sua arquitetura em camadas para
construção de aplicativos. A seção V apresenta informações
sobre o núcleo da SDK QualcommVuforia, ferramenta
escolhida para implementar este sistema, e sobre as possíveis
T. A.Nardi, Acadêmico da Universidade Estadual do Oeste do Paraná
(Unioeste), Foz do Iguaçu, Paraná.
F. F. F. Peres, Docente da Universidade Estadual do Oeste do Paraná
(Unioeste), Foz do Iguaçu, Paraná.
A realidade aumentadapode ser entendida como uma
tecnologia que realiza o meio campo entre a realidade virtual e
a telepresença (totalmente real). Para considerarmos um
sistema como sendo de realidade aumentada o mesmo deve
conter três elementos chave: combinar real e virtual, ser
interativo em tempo real e deve ser registrado em 3D [2].
As principais áreas potenciais para criação de aplicações
usando esta tecnologia segundo Azuma são [2]:
 Medicina:suporte para visualização médica em geral na
sala de cirurgia. Realidade aumentada pode ser usada para
reduzir o tamanho das incisões médicas geradas em
pequenas cirurgias, através do mapeamento 3D dos
órgãos e partes afetadas do paciente;
 Manufatura e reparo:úteis em atividades de fabricação
de peças e materiais, além de reparo nos mesmos através
da criação de tutoriais interativos.Esta é a área onde
aplica-se a realidade aumentada neste artigo;
 Anotações e Visualização: compartilha informações em
ambientes públicos, por exemplo,um sistema de realidade
aumentada pode apresentar informações sobre livros de
uma biblioteca;
 Planejamento de trajetória de Robôs: existem casos no
qual existem atrasos consideráveis de tempos e consumo
de recursos no controle de robôs a distância. Neste caso
utiliza-se a realidade aumentada para realizar simulações
e analisar o ambiente antes de se efetuar o comando. Por
exemplo: robôs em expedições espaciais no planeta
Marte;
 Entretenimento: exemplo clássico de aplicação da
realidade aumentada. Como grande ponto de estimulo
para o seu uso tem-se o fato de que a indústria de cinema
considera em determinados casos mais barato construir
objetos de cenário em 3D e mistura-los a uma cena real do
que construir de fato o objeto;
 Aviação Militar: arealidade aumentada auxilia o piloto
em cálculos de trajetórias de mísseis e colisões.
159
A. Principais elementos de um sistema de RA
A construção de sistemas de realidade aumentada requer três
principais subsistemas. O primeiro subsistema é o gerador de
cenas, responsável por misturar elementos reais e virtuais e
gerar a cena de realidade aumentada. O segundo subsistema é
o display, estes por sua vez é dividido em display ótico e
display de vídeo. A diferença destes displays está no fato de
que através do display ótico o usuário pode ver o mundo real
diretamente e no display de vídeo o usuário vê o mundo
através de um monitor. E por fim, o rastreamento e detecção,
também denominados trackers, são utilizados pelos sistemas
de realidade aumentada paramapear posições no mundo real,
definindo informações como ângulo, campo de visão, etc [3].
III. EXTENSÔMETRO DE HASTE MÚLTIPLA
Extensômetros de haste são instrumentos utilizados pela
engenharia para auxiliar de forma geral em medições do solo
em fundação de barragens. São compostos por uma cabeça que
é fixada sob a superfície e hastes metálicas de diversos
comprimentos chumbadas na rocha. Através da cabeça medese a tensão aplicada pelo solo à haste, possibilitando a
medição de deslocamentos. Extensômetros podem ser
demedição manual ou automática. Quando automática, sua
cabeça é composta por um conjunto de transdutores (um para
cada haste), que são dispositivos que convertem os sinais da
tensão para o formato digital, permitindo o armazenamento em
intervalos de tempos.
Em Itaipu, existem 146extensômetros instalados em sua
fundação, barragens de concreto e enrocamento, auxiliando no
monitoramento de deslocamentos verticais (medição de
recalques do solo) e deslocamentos horizontais (cisalhantes).
O sistema proposto pelo artigo pretende ser usado por
profissionais
para
auxiliar
na
manutenção
destesextensômetros, ajudando no processo de substituição
detransdutores.
Segundo levantado por Moreira [7], para realização da
manutenção nos extensômetros de Itaipu, os técnicos realizam
os seguintes passos:
1. Remover a tampa protetora;
2. Realizar leitura manual e automática do extensômetro para
servir como base para comparação com a leitura realizada
no final da troca do transdutor;
3. Retirar circulo protetor;
4. Retirar o parafuso lateral que regula a altura utilizando uma
chave Allen de 5,5mm (7/32”);
5. Retirar a porta de suporte do Transdutor, utilizando uma
chave de boca;
6. Rotacionar o transdutor para ambos os lados
simultaneamente até encontrar o ponto de encaixe. Obs.: o
transdutor deve estar travado neste momento e caso o
mesmo não esteja travado, pode romper a corda vibrante
que realiza as medições no extensômetro;
7. Remover o cabo que contecta o transdutor;
8. Remover o transdutor;
9. Inserir novo transdutor no local do antigo.Obs:deve-se
remover o lacre do novo Transdutor antes da instalação;
10. Travar transdutor na base, rotacionando em sentido
horário;
11. Passar o cabo pelo anel protetor da base;
12. Travar a porca de suporte;
13. Regular a altura;
14. Realocar parte protetora;
15. Realizar nova leitura e comparar com a anterior para
verificar a calibragem do equipamento.
IV. DESENVOLVIMENTO DE SISTEMAS DE RAEMDISPOSITIVOS
MÓVEIS
Para que sistemas de realidade aumentada possam ser
construídos é necessário hardware capaz de capturar: vídeo,
realizar processamento de dados e que possua alguma forma
de exibir informações, como um display. Azuma[2] apresenta
sistemas de realidade aumentada concebidos sob Head
mounted Displays (HMDs), por serem na época os
dispositivos que preenchiam estes requisitos e permitiam a
mobilidade requerida pelos tecnologia. Atualmente os
celulares evoluíram de forma que se tornou possível a
construção de sistemas de realidade aumentada nos mesmos.
Atualmente existem basicamente quatro plataformas que
dominam o mercado de dispositivos móveis: Android, Black
Barry, Symbian OS e IOS. O artigo foca na construção de
aplicativos para Android, que está entre as plataformas mais
populares atuais e possui desenvolvimento livre de custo com
licenças[3].
Visão geral da Arquitetura Android
Android é um Sistema Operacional (SO) desenvolvido pelo
Google. É organizado em camadas (figura 1). Cada camada
agrupa um conjunto de programas com objetivos e
funcionalidades em comum. Estas camadas são organizadas
como uma pilha e sua base é o Kernel. Para construção deste
Kernel baseou-se na versão 2.6 do Kernel do Linux. O
conjunto de programas do próximo nível contém as bibliotecas
básicas do SO (exemplo: gravação e reprodução de áudio,
aceleração tridimensional, vídeo, etc.). A próxima camada
contém frameworks de aplicações.Inclui programas que
gerenciam funções básicas do telefone e dão suporte à
aplicações de forma geral. E por fim, está a camada de
aplicativos, onde estão todos os aplicativos que o usuário final
pode acessar [6].
Estrutura básica de aplicativos
Os aplicativos construídos para Android devem levar em
consideração quatro tipos básicos de estruturas: Atividades,
toda tela que a aplicação exibe ao usuário; Objetivos, eventos
disparados dentro da aplicação para troca de Ativiades; caso o
programa tenha tenha alguma estrutura de Serviço associada, o
mesmo pode continuar sendo executado mesmo tendo sua
Atividade fechada pelo usuário; por fim, temos o Provedor de
Conteúdo, responsável por compartilhamento de conteúdo
entre as aplicações.
160
ImageTracker: Cada novo marcador deste tipo é ranqueado
de zero a cinco pontos pela ferramenta, dependendo da
complexidade dos elementos contidos na imagem. O website
de ferramenta destaca uma nota de instrução informando que
não é aconselhável o uso de imagens que apresentam
ranqueamento inferior a três. Para uma imagem ser
considerada boa ela deve possuir: alto número de elementos ao
longo de toda a imagem e bem distribuídos (sem espaços em
branco), forte contraste entre os mesmos e os padrões contidos
na imagem devem ser variados. A figura 2 apresenta uma
imagem em sua versão original e sua versão após o
mapeamento da ferramenta, apresentando um ranking cinco.
Figura1. Organização da pilha de programas do SO Android.
V. QUALCOMMVUFORIA
A Qualcomm é um instituto de pesquisa que atua
desenvolvendo soluções paradiversos tipos de tecnologias
voltadas a informação. [4]. Dentre suas áreas de atuação está
a RA, através do projeto denominado Vuforia. Esta sessão
dedica-se em apresentar os principais aspectos desta SDK
disponibilizada pela Qualcomm.
A. Elementos do núcleo Vuforia
Este tópico apresenta todos os elementos que caracterizam o
núcleo de elementos da Vuforia [4]:
Câmera: Comunica com hardware de câmera e assegura
que as imagens capturadas foram transferidas eficientemente
ao tracker. O desenvolvedor apenas tem controle de informar
quando iniciar e quando pausar a captura de vídeo.
Image Converter: Converte a imagem obtida pela câmera
em um formato padronizado que seja compatível com o render
utilizado.
Tracker: Algoritmos de visão computacional que detectam
objetos do mundo real analisando os frames da câmera. Podem
ser dos tipos Target, Markers ou Buttons.
Vídeo Background Render:Renderiza a imagem da
câmera.
Código da Aplicação: Deve instanciar e inicializar todos os
elementos básicos do núcleo (descritos nesta sessão) além de
manipular os marcadores, a lógica da aplicação e atualizar o
render da camada gráfica (virtual) do sistema.
Target Resources: Criados utilizando uma plataforma
online disponível no site da Qualcomm. São estruturas
utilizadas para representar os marcadores dentro do sistema.
Trackables: Classe base que representa todo objeto do
mundo real que a Vuforia pode rastrear. Todo marcador
suportado pela SDK origina desta classe.
B. Tipos de Trackers
A SDK Vuforia permite desenvolver sistemas de realidade
aumentada utilizando três tipos de marcadores: ImageTargets,
Frame Markers e Buttons. O primeiro tipo de tracker
reconhece qualquer imagem fornecida ao mesmo. O Segundo
tipo reconhece marcadores fiduciais com códigos e o terceiro
reconhece formas dentro de ImageTargets como botões de
interação virtual com o usuário. A seguir apresentamos cada
tipo de tracker.
(a): Imagem original
(b): Resultado do algoritmo para gerar o ImageTracker da Vuforia.
Figura 2.Rankeamento da vufória com nível 5. Imagem apresenta todas as
características consideradas fortes para reconhecimento pela ferramenta.
Fonte: Qualcomm [8].
FrameMarker:Este tipo de tracker não é gerado online. A
SDK disponibiliza 512 padrões diferentes de marcadores
organizados de 0 à 511. A Figura 3 apresenta o padrão de
design de todos os FrameMarkets, o ID deste exemplo é 0. A
parte de cor laranjada da figura representa informações que
podem ser customizadas no marcador e todo o resto deve ter o
mesmo formato do original para que possa ser reconhecido.
Buttons:Desenho de botões que podem ser adicionados em
ImageTrackers e reconhecidos individualmente pela SDK.
161
criada uma biblioteca compartilhada contento todas as
funcionalidades necessárias utilizadas pelo sistema. Estas
bibliotecas são carregadas na aplicação e acessadas via Java
Native Interface (JNI). O JNI é um padrão de programação
que permite com que a máquina virtual do Java (JVM)
manipule códigos nativos de outros sistemas [5]. Para criar
estas bibliotecas compartilhadas está sendo utilizado o
AndroidNativeDevelopment Kit (NDK)[3], que fornece um
conjunto de ferramentas para compilação independentes de
plataforma (Windows, Linux, etc).
Figura 3. Exemplo de FrameMarker padrão da ferramenta QualcommVuforia.
Fonte [8].
VI. SISTEMA PROPOSTO
Esta sessão dedica-se em apresentar o sistema proposto para
auxiliar na manutenção do instrumento de medição
Extensômetro de Haste Múltipla de Itaipu e suas principais
características em termos de tecnologia utilizada para
construção.
Princípios da construção do sistema
Para que este sistema possa ser utilizado de fato pelo técnico
que realiza manutenção em extensômetros ele deve idealmente
levar os seguintes fatores em consideração em sua construção:
 Tutorial passo a passo que auxilia no processo de
manutenção do extensômetro;
 O extensômetro deve ser reconhecido in-situ;
 O extensômentro deve ser reconhecido preferencialmente
sem adição de marcadores fiduciais;
Como visto anteriormente, o código da aplicação de RA
deve ter 3 preocupações básicas: manipular os marcadores,
lógica particular da aplicação e manipular o render gráfico. Os
tópicos a seguir descrevem a solução considerada para
desenvolver cada parte do trabalho.
Descrição das configurações de trabalho com a OpenGl ES
OpenGL ES é a versão da OpenGL (API multiplataforma
padrão da indústria de computação gráfica), especializada em
aplicações embarcadas (EmbeddedSystems). Ela fornece
funções na linguagem C/C++ e para sua utilização no sistema
proposto foi adotada a mesma estratégia proposta para uso dos
elementos da QualcommVuforia, que é a criação de uma
biblioteca compartilhada através da Android NDK, utilizando
JNI como padrão de comunicação.
Objetos 3D:Os objetos 3D carregados no sistema (tais como
setas indicadoras, ferramentas e o próprio extensometro 3D),
são provenientes das ferramentas Blender 3D e SolidWorks. A
biblioteca OpenGL gerada para realizar animações erenderizar
os gráficos da cena do sistema utilizam Array com
coordenadas para representar cada objeto, estas coordenadas
representam os vértices, as normais, a coordenada das texturas
e os índices do objeto.
Construção dos marcadores
Para construção de marcadores foi optado inicialmente
pelos ImageTargets. A figura 4 apresenta o resultado do
processo de detecção dos marcadores ImageTargets gerados
pela ferramenta da Vuforia para detecção do extensômetro
exemplo utilizado na aplicação. Para ambas as imagens o
ranking do sistema foi zero.
Descrição do ambiente de trabalho para desenvolvimento de
aplicações Android
Para desenvolvimento de sistemas para a plataforma
Android é utilizado por padrão a linguagem de programação
Java. Para construção deste sistema foi configurado o
ambiente de desenvolvimento utilizando a ferramenta Eclipse,
onde foi instalado oAndroidDevelopment Tools (ADT), que
permite configuração de máquinas virtuais de teste e geração
de aplicativos para Android e instalado o Android SDK, para
suporte às funcionalidades básicas da plataforma. Para testes
unitários na criação do sistema está sendo utilizado um
dispositivo Galaxy Y Samsung, com Android 2.3.6 instalado.
A API disponibilizada para programaçãoAndroid é
contabilizada em níveis conforme atualização da mesma. Para
a construção deste sistema está sendo utilizada como base a
API nível 10, suportada porAndroid 2.3 e superiores.
Descrição das configurações para trabalho com a SDK
QualcommVuforia
A SDK da Vuforia é escrita nas linguagens C/C++. Para ter
acesso as suas funções na aplicação escrita em Java está sendo
162
(a)
(b)
Figura 4.Imagens (a) superior e (b) lateral da cabeça do extensômetro de
haste múltipla utilizado para realizar os testes.
Figura 5.Screenshoot da aplicação rodando em sistema Android,
reconhecendo o marcador FrameMarker.
VII. RESULTADOS OBTIDOS
O sistema está em fase final de desenvolvimento, onde
estão sendo finalizadas animações 3D e implementados os
passos do tutorial de acordo com levantado por Moreira [7]
junto
a
especializas.Os
marcadores
estiloImageTargetsutilizados na construção de um protótipo
inicial de teste da SDK apresentou baixo desempenho em
testes de uso em laboratório devido a simplicidade das
imagens (o algoritmo da Vuforia reconhece melhor imagens
complexas) e devido ao fato de que utilizar imagens sólidas
(fotografia 2D) limitam fortemente a faixa de angulação na
qual o dispositivos de vídeo reconhece o objeto 3D. Estes
problemas aconteceram por que a tecnologia ImageTargets da
QualcommVuforia
é
fortemente
voltada
para
o
reconhecimento do ambiente via marcadores, ou seja, é
necessário que o ambiente seja modificado com a adição de
marcadores para que o mesmo possua desempenho relevante.
Para correção deste problema e dar continuidade ao
desenvolvimento do sistema, optou-se por utilizar os
marcadores do estilo Frame Markers. Tal decisão irá
introduzir os benefícios de apresentar melhor desempenho em
laboratório e consequentemente in-situ (ambientes externos ao
laboratório possuem maior número de condições adversas
como, por exemplo, iluminação e clima, que dificultam a
detecção da imagem) e irá introduzir como ponto negativo a
necessidade de adicionar ao extensômetro um marcador
fiducial padronizado para reconhecimento pelo sistema. A
figura 5 apresenta telas de uso do sistema em testes de
laboratório.
VIII. CONCLUSÃO
Os esforços realizados para o desenvolvimento do trabalho
até então identificaram que é necessário um entendimento
maior sobre a diferença de uso pelo técnico de Itaipudo
sistemas utilizandomarcadores fiduciais e os que não
necessitam.
Foi descoberto que a SDK da QualcommVuforia em sua atual
versão não suporta reconhecimento sem marcadores,
denominados pelo mercado marklesstracking, que permitem
reconhecimento de objetos 3D do mundo real. Durante todo o
processo tentamos utiliza a solução ImageTargets como
tecnologia para substituir o uso de marcadoresmarcadores, o
que resultou em um sistema que não reconhecia o aparelho,
obrigando a mudança para FrameMarkers, que são marcadores
fiduciais tradicionais.
Como proposta para evolução está sendo proposto o estudo
da diferença das abordagens, algoritmos envolvidos e casos de
uso.
O resultado final também possibilitou constatar que a
ferramenta QualcommVuforia não implementa algoritmos de
oclusão de objetos, fazendo com que no efeito final o objeto
3D sempre apareça sob a imagem real, neste caso, propõe-se o
estudo de algoritmos de oclusão para adição futura na
ferramenta.
A maior dificuldade encontrada durante a produção foi
definir de forma sistemática a posição relativa do objeto 3D
com o objeto real. Através da Vuforia o programador apenas
tem acesso a posição no espaço 3D do marcador e pode
posicionar objetos 3D partindo desta posição relativa, não
levando em consideração particularidades do extensômetro.
Neste caso foi posicionado através de tentativa e erro os
objetos no espaço 3D até se alcançar uma posição relativa
aceitável pelo usuário. Esta questão pode ser foco de
desenvolvimento de novas tecnologias pois é uma demanda de
incremento que se fosse implementada pouparia grande
esforço no desenvolvimento (cerca de 30% do tempo gasto no
163
desenvolvimento da ferramenta foi sob o posicionamento de
forma aceitável pelo usuário final).
REFERÊNCIAS
[1]
[2]
[3]
[4]
[5]
[6]
[7]
[8]
J. F. A. Silveira,Instrumentação e Segurança de Barragens de Terra e
Enrocamento,Oficina de Textos, 2006.
R. Azuma, “A Survey of Augmented Reality”, Teleoperators and
Virtual Enviroments, Vol. 6, 1997.
Google,“Android Website”,Disponível em: www.android.com, 2012.
Qualcomm,
“QualcommVuforia
Website”,Disponível
em:
www.qdev.net.
Sun Microsys, “Java Website”, Disponível em: www.java.com.
J. Strickland. A Arquitetura do Android. Disponível em:
http://informatica.hsw.uol.com.br/google-phone2.htm,.2012.
T. Moreira, “Auxílio na Manutenção de um Extensômetro Utilizando
Realidade Aumentada”,Unioeste, 2011.
Qualcomm,
“QualcommVuforia
Website”,
Disponível
em:
https://ar.qualcomm.at/qdevnet/developer_guide/Target%20Manageme
nt%20System, 2012.
164
QoSTVApp:Uma Aplicação Semântica para o
SBTVD
M. S. Couto, V. L. da Silva, C. Mª F. A. Ribeiro
Abstract— The warranty of a certain level of Quality of
Service (QoS) is a key requirement in many interactive
applications used in Brazilian Digital TV System (SBTVD). This
study aims to analyze the QoS requirements, and for this, we
created a semantic model for knowledge representation through
an ontology covering the various elements that can impact on the
quality levels set by interactive applications. The created model
focuses on SBTVD, and we believe it can help in the automated
reasoning on the feasibility of tasks and interactive applications,
considering the work on different technological circumstances.
Keywords— Digital Television, Interaction, Quality of Service.
I. INTRODUÇÃO
O
modelo da TV Digital oferece aos usuários a
oportunidade de novas experiências relacionadas à troca
de informações, principalmente por meio da
interatividade, o que possibilita o desenvolvimento de novos
aplicativos e serviços.
De acordo com [1], para prover comunicação através do
canal de retorno é necessária a escolha de algum meio de
transmissão (fibra óptica, rádio, satélite entre outros),
considerando as características específicas de cada tecnologia
e parâmetros limitantes do canal de comunicação (vazão,
atraso e perda de pacotes). A seleção desses parâmetros em
detrimento de outros, pode variar de um lado pela aplicação e,
por outro lado, pelas tecnologias de comunicação disponíveis
e seus fatores limitantes.
No Brasil, dada as suas características de dispersão
geográfica e assimetria na oferta de serviços de
telecomunicação, é fundamental avaliar previamente o nível
de interatividade que uma determinada aplicação pode
proporcionar aos seus usuários. Concebido dentro de uma
política nacional de oferta de serviços ao cidadão, o Sistema
Brasileiro de TV Digital (SBTVD) precisa disponibilizar
meios de validação prévia da exequibilidade de aplicações
interativas enquanto instrumento essencial de políticas sociais
nacionais.
Para a validação do modelo QoSTVModel utilizado neste
trabalho, foram consideradas duas estratégias complementares.
A primeira baseia-se nos dados apurados pelo simulador de
rede, para identificar valores limitantes na utilização de
tecnologias de retorno em cenários bem definidos. Esta
estratégia esbarra na baixa escalabilidade e baixo desempenho
para simulação de cenários mais realistas, que consideram, por
exemplo, a quantidade provável de usuários em um bairro ou
cidade. Para enfrentar este desafio, foram utilizados métodos
estatísticos para análise e projeção de valores para cenários
reais, de forma a permitir a avaliação do impacto da
degradação do nível de qualidade de serviço (QoS) sobre as
aplicações, mais especificamente sobre a interatividade.
Considerando-se a heterogeneidade dos elementos
envolvidos e a complexidade e dinamismo das relações entre
os mesmos, optou-se por representar este conhecimento por
meio de ontologias de domínio com a aplicação QoSTVApp.
Tal tecnologia possibilitará, dentre outros benefícios, o
raciocínio automatizado para verificação da exequibilidade de
aplicações interativas em um dado contexto. Estes e outros
conceitos que fundamentam a proposta estão descritos nas
seções a seguir.
II. CONTEXTO DO TRABALHO
A evolução trazida pela TV Digital substitui o antigo
modelo unidirecional e oferece ao telespectador um canal de
interatividade para sua comunicação, possibilitando, desta
forma, a troca de informações. O canal de interatividade ou
canal de retorno é o meio através do qual os usuários
conseguem interagir com o sistema.
Os aplicativos interativos com recursos multimídia ainda
estão em processo de desenvolvimento, com o surgimento de
novos conteúdos e a construção de novos modelos e
linguagens [2]. Portanto, é preciso gerenciar esse tipo de
aplicativo em relação aos parâmetros necessários para a
sincronização entre diferentes mídias e limites tecnológicos da
comunicação.
De acordo com [3], os aplicativos interativos que são
disponibilizados na TV Digital precisam atender algumas
características como usabilidade e aplicabilidade, para a
aceitação dos usuários. A avaliação desta aceitação envolve
questões subjetivas de difícil validação, tais como interesse
pelo assunto. Contudo, a aplicação é um elemento importante
que deve ser considerado para validação do modelo utilizado.
III. SOLUÇÃO
Com base neste cenário e nos desafios que o mesmo
apresenta, foi utilizado o modelo denominado QoSTVModel,
que conjuga os requisitos de QoS da aplicação interativa com
os requisitos da tecnologia de acesso [4]. Os diversos
elementos envolvidos no modelo são apresentados
graficamente na Figura 1.
No modelo QoSTVModel são explicitados os componentes
________________________
diretamente envolvidos com a interatividade, suas
M. S. Couto, Instituto Federal do Sertão Pernambucano (IF Sertão),
propriedades ou funções específicas e o relacionamento entre
Ouricuri, Pernambuco, Brasil, [email protected]
V. L. da Silva, Universidade do Estado do Rio Grande do Norte (UERN), os mesmos.
Natal, Brasil, [email protected]
A dinâmica entre os elementos sugere o envio do aplicativo
C. Mª F. A. Ribeiro, Universidade do Estado do Rio Grande do Norte pela Estação de TV Digital, responsável pela difusão da
(UERN), Natal, Brasil, [email protected]
programação. O receptor, que possui propriedades específicas,
165
tais como poder de processamento, capacidade de memória e
portas de comunicação, é o equipamento que recebe e
armazena o aplicativo que será disponibilizado ao usuário.
Conforme [5], o usuário pode interagir com o aplicativo de
forma local, intermitente ou permanente. Para a troca de
informações, o receptor precisa estar conectado a uma
determinada tecnologia de acesso, que restringe os requisitos
de QoS (vazão, atraso e perda de pacotes) e possui
características que a diferencia de outra, tais como: alcance,
largura de banda, disponibilidade da rede e custo da
infraestrutura. O provedor de canal de retorno é o responsável
pela tecnologia de acesso a ser utilizada na última milha para o
canal de retorno, e o provedor de conteúdo oferece acesso a
serviços e conteúdos especializados aos usuários, por meio do
provedor de canal de retorno.
O termo ontologia passou a ser adotado por grupos de
pesquisas para referenciar os conceitos e termos que podem
ser utilizados para apresentar alguma área do conhecimento ou
desenvolver uma representação. Uma ontologia determina um
domínio, ou, mais formalmente, define uma conceitualização
acerca dele [6].
Para o desenvolvimento da ontologia em relação aos
conhecimentos sobre QoS em TV Digital, utilizou-se a
ferramenta Protégé1. Essa ferramenta open source é baseada
em Java e integrada ao framework Jena2, para construir
aplicações da Web Semântica. O modelo criado é representado
por meio de classes, apresentadas na Figura 2.
Fig. 3. Representação das Classes e suas Relações
IV. ESTUDO DE CASO E RESULTADOS
Como estratégia de validação do modelo proposto, foram
realizadas simulações por meio do Network Simulator-2 [7],
para analisar os parâmetros da rede no cenário descrito. O NS2 é uma ferramenta poderosa para simulação de redes que
cobre um grande número de aplicações, protocolos, tipos de
redes, elementos de rede e modelos de tráfego.
A noção de tempo no NS-2 é obtida através de unidades de
simulação que podem ser associadas, para efeitos didáticos, a
segundos. A rede é construída usando nós os quais são
conectados por meio de enlaces. Quando é simulada uma rede
cabeada, como é o caso deste trabalho, os parâmetros de um
enlace precisam ser ajustados.
Os agentes utilizados podem ser associados aos nós e eles
são responsáveis pela geração de diferentes pacotes. A fonte
de tráfego é uma aplicação à qual é associado um agente
particular. Os agentes precisam de um receptor que receberá
seus pacotes. A Figura 4 mostra a estrutura padrão dos objetos
de simulação.
Fig. 2. Representação das Classes
O modelo também foi formalizado em uma ontologia de
domínio, sendo este, representado por meio de classes e
propriedades. A representação das classes da ontologia e as
suas relações são vistas na Figura 3.
Para representar o papel de cada componente do modelo de
QoS utilizado na ontologia, foram utilizadas as propriedades
de objetos, onde cada propriedade possui um domínio e uma
imagem que são as classes que representam os componentes
aos quais cada propriedade está relacionada.
1
2
http://protege.stanford.edu/
http://protege.stanford.edu/plugins/owl/jena-integration.html
Fig. 4. Objetos de Simulação do NS-2
Neste trabalho, o cenário que serviu de base para as
simulações representa o bairro Neópolis, na cidade de Natal,
Rio Grande do Norte, a menor cidade em termos
populacionais, dentre as sedes da Copa 2014. Neópolis possui
aproximadamente 6481 residências, segundo os dados da
Prefeitura do Natal [8]. A tecnologia escolhida foi a ADSL,
uma das mais usadas para o acesso à Internet. O tráfego foi
gerado entre os receptores e o provedor de canal de retorno,
composto pelo link de dados do tipo assimétrico. Segundo [9],
foi adotado um link de 1 Mbps para download e 300 Kbps
para upload, valores geralmente ofertados pelas operadoras. A
166
partir dessa transferência de dados, foi realizada a análise dos
parâmetros de QoS: vazão, atraso e perda de pacotes.
Foi gerado um tráfego entre os receptores e o provedor de
canal de retorno, sendo que os dados como o tamanho dos
pacotes e atraso do link para aplicações multimídia foram
definidos como mostrado na Tabela I, para obter os dados
mais próximos de uma aplicação interativa da TV Digital [10].
A partir dessa transferência de dados, foi realizada a análise
dos parâmetros de QoS.
TABELA I
VARIÁVEIS CONSIDERADAS NA AVALIAÇÃO DE TÉCNICAS DE INTERAÇÃO
DESCRIÇÃO
VALORES
Nº de nós
Até 1000
Tamanho do Pacote
1500 bytes
Atraso
20ms
Taxa de Transmissão (download)
1 Mbps
Taxa de Transmissão (upload)
300 Kbps
O objetivo principal deste trabalho é, portanto, investigar e
analisar requisitos de QoS no SBTVD por meio da aplicação
semântica QoSTVApp, com a ênfase nos aplicativos e nas
tecnologias de acesso para o canal de retorno.
A. RESULTADOS
Foi desenvolvida uma aplicação semântica, denominada
QoSTVApp, que utiliza ontologia como base para o raciocínio
automatizado. Esse aplicativo busca responder aos
questionamentos de viabilidade técnica para provimento da
interatividade, tanto por parte dos provedores quanto dos
desenvolvedores de aplicações, como mostrada na Figura 5.
A aplicação QoSTVApp utiliza as informações do
QoSTVModel para definir a rota de comunicação dos
elementos que compõem o SBTVD.
Conforme previsto, o NS-2 apresentou queda progressiva de
desempenho, a partir de 1000 aparelhos receptores. A partir de
então, foi utilizada a técnica estatística da Regressão Linear
Simples [11], que pode prever valores futuros de uma variável,
para estimar um número maior de receptores utilizados para o
cálculo das médias dos parâmetros de QoS em um cenário real
utilizado na simulação.
Por meio dos resultados obtidos nas simulações para a
tecnologia ADSL, a análise de cada um dos parâmetros de
QoS indica que após um determinado número de receptores
não é mais possível garantir a entrega do serviço com
qualidade. Mais especificamente, a interatividade do aplicativo
tem o seu desempenho afetado quando a vazão da rede fica
abaixo dos 100 Kbps [4].
De acordo com [12], em relação ao atraso, quanto maior for
o seu valor, maior deverá ser o tamanho do buffer para
garantir uma determinada reserva de dados. O valor desse
parâmetro começa a prejudicar a aplicação quando fica
superior a 0,5s, ou seja, em torno de 330 usuários conectados.
Na Figura 6, a aplicação semântica apresenta os resultados
para 200 receptores, sendo possível perceber que cada
parâmetro de QoS está relacionado diretamente ao número de
receptores conectados a tecnologia ADSL, utilizando o
aplicativo interativo.
De acordo com esse cenário, o provedor de acesso só
poderia disponibilizar essa conexão para aproximadamente
330 receptores, sendo este, o número máximo de conexões
com a garantia de que esse serviço não comprometeria os
parâmetros de QoS, já que o atraso foi o maior limitador do
número de receptores.
Fig. 6. Resultados dos Parâmetros do QoSTVApp
Fig. 5. Tela Inicial do Aplicativo QoSTVApp
Estes resultados parciais, embora careçam de maior
investigação, apontam claramente para a existência de um
gargalo tecnológico. Tal fato pode limitar seriamente a adoção
deste tipo de tecnologia em novos modelos de negócios e para
o suporte às políticas públicas, indicando a necessidade de
investimento na área. Se for considerada a assimetria na oferta
de serviços de comunicação nas várias regiões do Brasil, é
correto afirmar que este fato pode aprofundar o problema de
exclusão digital existente atualmente.
167
[6]
V. CONCLUSÃO
As mudanças trazidas pela TV Digital não se resumem
apenas aos ganhos em relação à qualidade de áudio e vídeo.
As aplicações interativas já estão sendo trabalhadas dentro do
novo padrão de TV, associada às tecnologias de acesso, que
criam um caminho para a troca de informações suscitando
maior participação do telespectador.
A aplicação semântica QoSTVApp, permite inferir sobre a
exequibilidade da interatividade considerando requisitos da
aplicação e do ambiente de execução. Utilizou-se o
conhecimento representado no modelo e os dados obtidos na
fase de validação para a construção de uma ontologia de
domínio, a partir da qual os desenvolvedores de aplicativos
interativos ou provedores de serviços podem usar os
resultados do QoSTVApp para avaliar os parâmetros de QoS
da comunicação.
Como trabalho futuro pretende-se fazer a inclusão de regras
de inferência para ampliar o raciocínio e a precisão das
informações apresentadas pela aplicação semântica.
REFERÊNCIAS
[1]
[2]
[3]
[4]
[5]
Campista, Miguel Elias M.; Moraes, Igor M.; Esposito, Pedro Miguel;
Amodei Jr., Aurélio; Cunha, Daniel de O.; Costa, Luís Henrique M. K.;
Duarte, Otto Carlos M. B.“The Ad Hoc Return Channel: a Low-Cost
Solution for Brazilian Interactive Digital TV”. Grupo de Teleinformática
e Automação, PEE/COPPE – DEL/POLI. Universidade Federal do Rio
de Janeiro, Brasil. 2006.
Gosciola, V. Roteiro para as novas mídias: do game à TV Interativa.
São Paulo: Editora Senac, 2003.
Margalho, M., Frances, R. and Wely, J. “Return path in Brazilian digital
television with interactivity based on continuous signalization
mechanism and qos bandwidth control”, Latin America Transactions,
IEEE (Revista IEEE America Latina), 5(5):367 –372, Sep. 2007.
Couto, M.S.; da Silva, V.L.; da Rocha, B.G.; Ribeiro, C.M.F.A.
QoSTVModel: A semantic model for analysis of QoS in interactive
applications for SBTVD. Information Systems and Technologies
(CISTI), 2012 7th Iberian Conference on Publication 2012.
Montez, C.; Becker, V. TV Digital Interativa: conceitos, desafios e
perspectivas para o Brasil. Florianópolis: Ed. Da UFSC, 2005. 2ª edição.
Gruber, T. R. Towards Principles for the Design of Ontologies Used
for Knowledge Sharing. International Journal of Human and Computer
Studies, v. 43, p. 907-928, 1995.
[7] Issariyakul, T; Hossain, E. Introduction to Network Simulator NS2.
Springer Publishing Company, 2008. ISBN: 0387717595.
[8] Natal. Bairros de Natal / Secretaria Municipal de Meio Ambiente e
Urbanismo. 2ª ed. SEMURB. Natal, 2010.
[9] Caires, G. O. J. “Explorando a Tecnologia ADSL: Uma Ferramenta de
Suporte ao Ensino Presencial e a Distância”. In Dissertação (Engenharia
Elétrica). Universidade Salvador, Bahia. 2003.
[10] Couto, M. S.; Costa, F. S.; Ribeiro, C. M. F. R. Simulação do Canal de
Retorno na TV Digital via Network Simulator: uma proposta com a
tecnologia ADSL. II Workshop Técnico Científico de Computação
(WTCC), Mossoró - RN, p. 127 - 133, jun. 2011.
[11] Charnet, R.;Charnet, E.M.R.; Freire, C.A.F.; Bovino, H. Análise de
modelos de regressão linear com aplicações. Campinas, Editora da
Unicamp, 1999.
[12] Guojun, LU. Communication and Computing for Distributed
Multimedia Systems. Artech House. 1996.
Mailson Sousa Couto é graduado em Ciência da Computação pela
Universidade Estadual do Sudoeste da Bahia (UESB), Vitória da
Conquista, Bahia, Brasil, em 2009. Obteve o título de mestre em
Ciência da Computação pela Universidade do Estado do Rio
Grande do Norte (UERN), Natal, Rio Grande do Norte, em 2012.
Atualmente é professor do Instituto Federal de Educação, Ciência
e Tecnologia do Sertão Pernambucano (IF Sertão) e suas pesquisas se
concentram na área de Qualidade de Serviço, Geoprocessamento e TV Digital.
Vandeclécio Lira da Silva é estudante do curso de Ciência da Computação
na Universidade do Estado do Rio Grande do Norte (UERN),
integrante do Laboratório LUMEN trabalhando em projetos de
TV Digital. Atualmente estagiando na SEPLAN-RN como
programador. Suas áreas de interesse são: ASP, VB, SQL
Server e TV Digital.
Cláudia Mª Fernandes Araújo Ribeiro possui graduação em Ciência da
Computação pela Universidade Estadual do Ceará (1987),
mestrado em Sistemas e Computação pela Universidade
Federal do Rio Grande do Norte (1999) e doutorado em
Ciência da Computação pela Universidade Federal de
Pernambuco (2004). Atualmente é professora adjunta da
Universidade do Estado do Rio Grande do Norte (UERN) e do Instituto
Federal do Rio Grande do Norte (IFRN). Tem experiência na área de Ciência
da Computação, com ênfase em Sistemas Distribuídos, atuando nos seguintes
temas: SOA, Web Semântica e Especificação Formal de Sistemas.
Fig. 1. Modelo de Interatividade - QoSTVModel
168

Introdução ao Desenvolvimento de Jogos para Facebook

Transcrição

Documentos relacionados

Confira como instalar e usar o Flash Player no seu equipamento

solidworks FLOW SIMULATION: MÓDULO DE

Painel 10 - Os Direitos Autorais na era dos Conteúdos

Aplicativo Habbo para Android é lançado na Play

Plano de Negócios e as Novas Fontes de Riqueza na

Lenovo adquire CCE em busca da liderança no

Apresentação Engº Mário Fernandes - Siteinforma

Estudo de Caso no Caprinos Culinária Regional - Anais

Roteiro

Where am I? Desenvolvimento de um Objeto de