Upload
others
View
7
Download
0
Embed Size (px)
Citation preview
UNIVERSIDADE DO VALE DO ITAJAÍ
CENTRO DE CIÊNCIAS TECNOLÓGICAS DA TERRA E DO MAR CURSO DE CIÊNCIA DA COMPUTAÇÃO
DESENVOLVIMENTO DE UM SISTEMA PARA ARMAZENAMENTO DE EXPERIÊNCIAS PESSOAIS BASEADO EM COMPUTAÇÃO MÓVEL
Área de Sistemas Embarcados
por
Elias de Oliveira Costa
Rafael Luiz Cancian, M.Sc. Orientador
São José (SC), 2008.
i
UNIVERSIDADE DO VALE DO ITAJAÍ
CENTRO DE CIÊNCIAS TECNOLÓGICAS DA TERRA E DO MAR CURSO DE CIÊNCIA DA COMPUTAÇÃO
DESENVOLVIMENTO DE UM SISTEMA PARA ARMAZENAMENTO DE EXPERIÊNCIAS PESSOAIS BASEADO EM COMPUTAÇÃO MÓVEL
Área de Sistemas Embarcados
por
Elias de Oliveira Costa Relatório apresentado à Banca Examinadora do Trabalho de Conclusão do Curso de Ciência da Computação para análise e aprovação. Orientador: Rafael Luiz Cancian, M.Sc.
São José (SC), 2008.
ii
DEDICATÓRIA
Aos meus pais, Edvaldo Carneiro da Costa e Maria Geny de Oliveira Costa,
por todo o amor, carinho e principalmente pela educação que me deram.
À minha irmã Eliane de Oliveira Costa, pelas palavras de força que recebi.
iii
AGRADECIMENTOS
Aos meus pais, Edvaldo Carneiro da Costa e Maria Geny de Oliveira Costa, pelos
ensinamentos, carinho, amor e por nunca deixarem de acreditar em mim.
A minha irmã Eliane de Oliveira Costa, por todos os momentos de apoio.
A Ana Paula da Silva Melo, por toda a ajuda e paciência que demonstrou durante esse
último ano. Obrigado por todos os momentos de apoio e carinho.
Ao meu orientador Rafael Luiz Cancian, pelo incentivo, conhecimento e principalmente
por esta oportunidade que me foi dada para a realização deste trabalho. Foi um enorme prazer
desenvolver este projeto. Muito obrigado.
Aos professores que fizeram parte da banca examinadora, pelos elogios e valiosas
sugestões e críticas que fortaleceram o desenvolvimento deste trabalho.
A coordenadora do curso Anita Maria da Rocha Fernandes, que colaborou direta e
indiretamente na realização deste com todas as palavras de apoio.
Aos meus antigos professores, que me ensinaram com prazer e dedicação parte do que sei
e, o que é mais importante, me ensinaram a aprender sozinho.
A todos os meus verdadeiros amigos que me deram força e ajudaram para a realização
deste trabalho.
iv
SUMÁRIO
LISTA DE ABREVIATURAS .................................................................................vii LISTA DE FIGURAS ................................................................................................ ix RESUMO......................................................................................................................x ABSTRACT ................................................................................................................ xi 1 INTRODUÇÃO.................................................................................................................12 1.1 CONTEXTUALIZAÇÃO .............................................................................................12 1.2 PROBLEMATIZAÇÃO................................................................................................13 1.3 OBJETIVOS...................................................................................................................14 1.3.1 Objetivo Geral .........................................................................................................................14 1.3.2 Objetivo Específico..................................................................................................................14 1.3.3 Metodologia..............................................................................................................................14 1.3.4 Estrutura do Trabalho............................................................................................................15 2 FUNDAMENTAÇÃO TEÓRICA...................................................................................16 2.1 MEMÓRIA HUMANA .................................................................................................16 2.2 MEMÓRIA DIGITAL EXPANDIDA .........................................................................17 2.2.1 Projeto MyLifeBits..................................................................................................................19 2.3 MULTIMÍDIA ...............................................................................................................22 2.3.1 Arquivos de Imagem ...............................................................................................................22 2.3.2 Arquivos de Vídeo ...................................................................................................................23 2.3.3 Arquivos de Áudio...................................................................................................................24 2.4 MULTIMÍDIA BASEADA EM CELULARES ..........................................................25 2.5 TECNOLOGIA DE REDES MÓVEIS E CELULARES...........................................27 2.5.1 Telefonia Móvel .......................................................................................................................27 2.5.2 Tecnologia de Redes de Celulares..........................................................................................28 2.6 GERAÇÃO DAS REDES CELULARES ....................................................................31 2.6.1Primeira Geração de Sistemas Móveis ...................................................................................31 2.6.2 Segunda Geração de Sistemas Móveis (2G)..........................................................................32 2.6.3 Sistemas Móveis de 2.5G e 2.7G.............................................................................................33 2.6.4 Terceira Geração de Sistemas Móveis (3G)..........................................................................34 2.7 GPS.................................................................................................................................36 2.8 TECNOLOGIAS DE DESENVOLVIMENTO.......... ...............................................37 2.8.1 SuperWaba ..............................................................................................................................37 2.8.2 Visual Studio............................................................................................................................38 2.8.3 NetBeans...................................................................................................................................39 2.8.4 Wap...........................................................................................................................................40 2.8.5 Brew..........................................................................................................................................41 2.8.6 Symbian....................................................................................................................................44 2.8.7 Java Micro Edition (JME)......................................................................................................45 2.8.7.1 Desenvolvimento JME com Multimídea e GPS................................................................48 2.8.7.2 Segurança de Aplicações JME ............................................................................................52 2.9 DISCUSSÃO...................................................................................................................53 3 DESENVOLVIMENTO...................................................................................................54
v
3.1 VISÃO GERAL..............................................................................................................54 3.2 ARQUITETURA DO SISTEMA .................................................................................55 3.3 MODELAGEM DO SISTEMA....................................................................................56 3.3.1 Análise de Requisitos ..................................................................................................57 3.3.1.1 Requisitos Funcionais ..........................................................................................................57 3.3.1.2 Requisitos Não-Funcionais ..................................................................................................58 3.3.1.3 Regras do negócio.................................................................................................................58 3.3.2 Diagrama de casos de uso .......................................................................................................59 3.3.3 Diagrama Classe......................................................................................................................59 3.3.4 Diagrama de Seqüência ..........................................................................................................61 3.4 IMPLEMENTAÇÃO.....................................................................................................63 3.5 PROTOTIPAÇÃO DE TELAS.........................................................................................65 3.6 TESTES E AVALIAÇÕES...........................................................................................68 3.7 RESULTADOS ..............................................................................................................71 4 CONCLUSÕES.................................................................................................................72 REFERÊNCIAS BIBLIOGRÁFICAS...............................................................................74 APÊNDICES. .......................................................................................................................78 A MODELAGEM DO SISTEMA......................................................................................79 A1 CASOS DE USO.............................................................................................................79 A.1.1 UC 01 Gerenciar Categorias .................................................................................................79 A.1.2 UC 02 Incluir Categorias .......................................................................................................79 A.1.3 UC 03 Editar Categorias........................................................................................................80 A.1.4 UC 04 Excluir Categorias ......................................................................................................80 A.1.5 UC 05 Iniciar Gravação .........................................................................................................81 A.1.6 UC 06 Parar Gravação...........................................................................................................81 A.1.7 UC 07 Gerenciar Experiência ...............................................................................................81 A.1.8 UC 08 Visualizar Mídia .........................................................................................................82 A.1.9 UC 09 Excluir Mídia ..............................................................................................................82 A.1.10 UC 10 Enviar Mídia .............................................................................................................83 A2 CLASSES DO SISTEMA..............................................................................................84 A.2.1 Pacote Mobilelife.business .....................................................................................................84 A.2.2 Pacote Mobilelife.persistence ................................................................................................85 A.2.3 Pacote Mobilelife.beans..........................................................................................................86 A.2.4 Pacote Mobilelife.connection.................................................................................................88 A.2.5 Pacote Mobilelife.utility .........................................................................................................88 ANEXOS........... ....................................................................................................................89 AI Descrição do Dispositivo Móvel Utilizado..........................................................................90 AII Especificações Técnicas da Plataforma S40 .....................................................................91 AIII Especificações Técnicas da Plataforma S60 ....................................................................92 AIV Netbeans UML Modeling................................................................................................93
vi
LISTA DE ABREVIATURAS
AAC Advanced Audio Coding ADS Application Download Server AMPS Advanced Mobile Phone System API Application Programming Interface AuC Authentication Center AVI Áudio-vídeo-interleaved BMP BitMap BREW Binary Runtime Environment for Wireless BTS Base Transceiver Station CCC Central de Comutação e Controle CCD Connected Device Configuration CDMA Code Division Multiple Access CLDC Connected Limited Device Configuration D-AMPS Digital-Advanced Mobile Phone Service EDGE Enhanced Data rates for GSM Evolution DOS Disk Operating System EIR Equipament Identity Register EM Estação Móvel ERB Estação Rádio Base ETSI European Telecommunications Standards Institute FDMA Frequency Division Multiple Access GIF Graphics Interchange Format GPRS General Packet Radio Service HLR Home Location Register HSCSD Hig-Speed Circuit-Switched Data IMEI International Mobile Equipment Identity IMTS Improved Mobile Telephone System JAD Java Application Descriptor JME Java Micro Edition JPEG Joint Photographic Experts Group JVM Java Virtual Machine LZW Lempel-Ziv-Welch MID Musical Instrument Digital Interface MMAPI Mobile Media API MMS Multimedia Messaging Service MPEG Motion Picture Experts Group MTSO Mobile Telephone Switching Office OEMS Original Equipment Manufacture OPL Open Programming Language PCS Personal Communications Services PDA Personal Digital Assistant PDC Personal Digital Cellular PNG Portable Network Graphics PROM Programmable Read-Only Memory PSTN Rede de Telefonia Pública Comutada QIS Qualcomm Internet Services
vii
RGB Red-green-blue SCPC Single Channel per Carrier SMC Serviço Móvel Celular SMS Short Message Service TACS Total Access Communication SystemTDMA Time Division Multiple Access TGA Targa TIFF Tagged Image File Format TXN Transaction Manger UAM Unified Application Manager UMTS Universal Mobile Telecommunications System UML Unified Modeling Language VGA Video Graphics Array VLR Visitor Location Register WAP Wirelless Application Protocol WAV Waveform WML Wireless Markup Language
viii
LISTA DE FIGURAS
Figura 1. Memex ................................................................................................................................18 Figura 2. Nokia N96 ..........................................................................................................................19 Figura 3. SenseCam ...........................................................................................................................20 Figura 4. Ilustração dos arquivos em forma de gráfico......................................................................21 Figura 5. Modelo da Nokia com recursos multimídia ......................................................................26 Figura 6. Topologia de uma rede celular............................................................................................29 Figura 7. Evolução dos padrões celulares ..........................................................................................33 Figura 8. Netbeans Mobility Pack 6.1................................................................................................39 Figura 9. Processo de distribuição do Brew.......................................................................................43 Figura 10. Ericsson R380 ...................................................................................................................44 Figura 11. Nokia 9210........................................................................................................................44 Figura 12. Edições da plataforma Java ..............................................................................................45 Figura 13. Arquitetura do perfil MID................................................................................................48 Figura 14. Hierarquia de classes de MIDP.........................................................................................50 Figura 15. Processo de funcionamento da MMAPI ...........................................................................51 Figura 16. Ciclo de vida de um Player ...............................................................................................51 Figura 17. Arquitetura MIDP.............................................................................................................55 Figura 18. Arquitetura do Sistema .....................................................................................................56 Figura 19. Diagrama de casos de uso.................................................................................................59 Figura 20. Diagrama de classe do sistema .........................................................................................60 Figura 21. UC 02:Diagrama de seqüência Incluir Categoria .............................................................62 Figura 22. UC 02: Diagrama de seqüência Incluir Categoria – Continuação ....................................62 Figura 23. UC 05: Diagrama de seqüência Iniciar Gravação.............................................................63 Figura 24. Tela Iniciar Gravação........................................................................................................65 Figura 25. Tela Nova Categoria .........................................................................................................66 Figura 26. Tela Gerenciar Experiências.............................................................................................67 Figura 27. Tela Gerenciar Categorias ................................................................................................68 Figura 28. Imagens Capturadas..........................................................................................................70 Figura 29. Trajeto Percorrido .............................................................................................................71 Figura 30. Classes Regra de Negócio.................................................................................................84 Figura 31. Classes Regra de Negócio – Continuação ........................................................................85 Figura 32. Classes Persistência ..........................................................................................................86 Figura 33. Classes Entidades..............................................................................................................87 Figura 34. Classes Entidades – Continuação .....................................................................................87 Figura 35. Classe Conexão.................................................................................................................88 Figura 36. Classe Utilidade ................................................................................................................88
ix
RESUMO
COSTA, Elias de Oliveira. Desenvolvimento de um sistema para armazenamento de experiências pessoais baseado em computação móvel. 2008, 93. Trabalho de Conclusão de Curso (Graduação em Ciência da Computação)-Centro de Ciências Tecnológicas da Terra e do Mar, Universidade do Vale do Itajaí, São José, 2008. Em um mundo onde o ser humano cada vez mais realiza diariamente atividades distintas, torna-se difícil recordar grande parte dos fatos ocorridos. Muitas vezes quando são recordados, não são com grandes detalhes. Além disso, a cada ano aumenta o uso de dispositivos móveis em todo o mundo. Celulares fáceis de transportar e com recursos multimídia cada vez mais se tornam comum no cotidiano das pessoas. Nesse sentido, o presente texto apresenta o desenvolvimento de um sistema multimídia para armazenamento de experiências pessoais baseado em computação móvel. Com a finalidade de enriquecer e complementar o tema sobre computação móvel, foram pesquisados conceitos sobre o funcionamento da comunicação via rede celular e as diferentes gerações tecnológicas celulares. Além disso, o texto apresenta algumas das principais tecnologias para desenvolvimento de aplicações móveis, dando-se maior destaque para a JME (Java Micro Edition). O sistema tem como finalidade capturar o ambiente em volta do usuário da aplicação. Portanto, é realizada a captura periódica de recursos multimídia como áudio, vídeo e imagem. Além disso, com o objetivo de capturar em quais locais o indivíduo esteve, o sistema coleta dados de posicionamento global (GPS). Todas essas informações ficam armazenadas no próprio sistema de arquivos do celular, para, posteriormente, o usuário visualizar, excluir e/ou enviar as mídias para um servidor web. Todo o desenvolvimento do projeto, tanto a diagramação como a codificação, foi desenvolvido utilizando como IDE o Netbeans 6.1. Palavras-chave: Computação Móvel. JME. MyLifeBits.
x
ABSTRACT
In a world where human beings increasingly different activities taking place daily, it is difficult to remember much of events occurred. Often when they are reminded, are not in great detail. Moreover, every year increases the use of mobile devices worldwide. Cell phones are easy to carry and with multimedia features become increasingly common in the daily lives of people. In that sense, this paper presents the development of a multimedia system for storing personal experiences based on mobile computing. In order to enrich and complement the theme on mobile computing, were investigated concepts on the operation of mobile communication and the different generations cellular technology. Moreover, the text presents some of the key technologies for development of mobile applications, with greater emphasis on JMe (Java Micro Edition). The system aims to capture the environment around the user's application. Therefore, it is carried out periodically capture of multimedia resources such as audio, video and image. Moreover, aiming to capture at which locations the individual was, the system collects data from global positioning (GPS). All these information are stored in the phone's file system, to, later, the user view, delete and / or send the media to a web server. The entire development project, both the layout such as encryption, was developed using the NetBeans IDE 6.1. Keywords: Mobile Computing. JME. MyLifeBits.
xi
1 INTRODUÇÃO
1.1 CONTEXTUALIZAÇÃO
Por toda sua vida, a memória humana adquire muitos dados. Porém, o ser humano não é
capaz de recuperá-los em sua totalidade. Quando recorda acontecimentos, muitas vezes isso ocorre
com poucos detalhes e sem muita precisão. Há raros casos de pessoas que conseguem lembrar com
precisão acontecimentos vividos anos antes. De acordo com Marshall (2008), uma moradora da
Califórnia de 42 anos, consegue lembrar cada dia da sua vida desde a adolescência com muitos
detalhes.
Batizada de hipertimésica (do grego timesis, lembrar), os neurocientistas já identificaram
outras pessoas com características similares. Tal fato pode ser explicado por causa de uma falha das
estratégias do cérebro para ajudar a esquecer fatos irrelevantes.
Grande parte das pessoas não consegue lembrar com precisão acontecimentos vividos muito
tempo atrás. Schacter (2008), chefe do Departamento de Psicologia da Universidade de Harvard, diz
que o cérebro desenvolveu estratégias para eliminar fatos de menor importância ou ultrapassados.
Chamada de esquecimento eficiente, essa característica é crucial para uma memória funcional.
Porém, segundo Schacter (2008), esquecer reuniões, não lembrar onde guardou os óculos ou
chaves e não recordar o nome de pessoas conhecidas são problemas que vem se tornando
corriqueiros para muitos adultos ocupados que tentam conciliar a vida profissional e familiar.
Nessa mesma linha de raciocínio, uma equipe de pesquisadores da Microsoft iniciou um
projeto de memória digital e expandida. Esse projeto, intitulado MyLifeBits, tem como objetivo
armazenar quase todo tipo de informação experimentada por uma pessoa. Um dos autores do
projeto, Gordon Bell, foi o pioneiro a experimentar essa idéia. Quando Gordon Bell trabalha em seu
computador, por exemplo, o sistema registra uma cópia de cada página visitada, músicas tocadas,
buscas realizadas e até mesmo que janelas estão em primeiro plano e a atividade do mouse e do
teclado.
Com o projeto MyLifeBits, pesquisadores da Microsoft desenvolveram uma câmera com um
sensor capaz de registrar momentos apropriados para fotos. Chamada de SenseCam, ela registra
imagens quando detecta a proximidade de um corpo pelo calor ou quando detecta que houve
mudança significativa no nível de luminosidade em um ambiente. Além disso, ela é capaz de
registrar imagens fotográficas periodicamente, como por exemplo, a cada 30 segundos.
Além de suas características tecnológicas, a SenseCam é pequena e compacta o suficiente
para ser usada ao redor do pescoço, como se fosse um colar. Um equipamento compacto e fácil de
transportar pode ser bastante útil e fornecer diversas funcionalidades. Nesse sentido, os dispositivos
móveis, principalmente os celulares, tornam-se cada vez mais parte do cotidiano das pessoas.
Segundo dados coletados do portal Teleco1, o Brasil iniciou 2006 com crescimento para um
número de celulares recorde para um mês de janeiro. Foram 1,26 milhões de novos celulares,
patamar alcançado em anos anteriores a partir do mês de março. Isto demonstra que o usuário final
cada vez mais busca novos recursos e funcionalidades nos aparelhos, além dos mais básicos
(serviço de voz, mensagem SMS). E muitas das funcionalidades incorporadas nos celulares são
recursos multimídia, como por exemplo, envio de mensagens contendo imagens e áudio e celulares
com câmeras embutidas para captura de imagens.
De acordo com Vaughan (1994), multimídia é qualquer combinação de texto, arte gráfica,
som, animação e vídeo transmitido pelo computador. Segundo Bell e Gemmel (2007), na medida
em que melhora o hardware para gravação digital, as pessoas cada vez mais tendem a criar registros
digitais pessoais de suas vidas em forma de multimídia, como arquivos de imagem, áudio ou vídeo.
Além disso, o advento de câmeras digitais baratas e de alta qualidade, principalmente as
incorporadas nos celulares, provocou um grande aumento no hábito de fotografar.
Neste contexto, torna-se viável o desenvolvimento de um protótipo de aplicação multimídia
para armazenamento de experiências pessoais baseado em computação móvel, tendo como foco
aparelhos celulares com suporte a aplicações Java, de modo similar a SenseCam do projeto
MyLifeBits.
1.2 PROBLEMATIZAÇÃO
Todo ser humano diariamente recebe uma grande quantidade de informação, seja esta
auditiva ou visual, entre outras. Muitas dessas informações são irrelevantes, ou seja, não há a
necessidade do cérebro armazenar tais informações por um longo período de tempo. Porém, há
informações muito úteis, e que precisarão ser lembradas com detalhes em algum momento futuro.
Contudo, o ser humano não é capaz de relembrar muitos desses registros diários. De acordo
com Schacter (2008), quando o ser humano esquece de algo útil, significa simplesmente que o
1 Teleco. Disponível em <http://www.teleco.com.br/comentario/com145.asp>. Acesso em: 15 Março 2006.
13
sistema de abstração do cérebro está trabalhando bem demais. Portanto, esquecer informações úteis
é algo bastante comum e que acontece com qualquer ser humano.
Hoje é comum notar pessoas segurando celulares ou os carregando nos bolsos de suas
vestimentas. Conforme aumenta a aquisição de aparelhos móveis, principalmente celulares, surge a
viabilidade do desenvolvimento de um sistema multimídia para armazenamento de experiências
pessoais baseado em dispositivos móveis. Com o desenvolvimento desse sistema, fatos importantes
que aconteceram no passado poderão ser facilmente acessados e conseqüentemente relembrados.
1.3 OBJETIVOS
1.3.1 Objetivo Geral
O objetivo deste trabalho é o desenvolvimento de uma aplicação para telefone celular para a
captura de imagem, vídeo, áudio e coordenadas GPS (Global Positioning System) visando arquivar
digitalmente a experiência pessoal de uma pessoa ao longo do tempo.
1.3.2 Objetivos Específicos
São objetivos específicos deste trabalho:
● adquirir conhecimento sobre APIs (Aplication Programming Interface) Java Micro
Edition e demais tecnologias necessárias para o desenvolvimento do sistema;
● modelar a aplicação proposta;
● implementar a aplicação;
● testar e avaliar a aplicação; e
● documentar o desenvolvimento e os resultados da pesquisa.
1.4 METODOLOGIA
Para a Fundamentação Teórica primeiramente foram realizadas pesquisas para a
compreensão das características da memória do ser humano, pesquisa essa que teve como principal
fonte de informação matérias publicadas em revistas científicas conceituadas. Em seguida, foram
pesquisados projetos para uma parcial solução do esquecimento enfrentado por uma pessoa.
14
Para adquirir um conhecimento mais aprofundado sobre dispositivos móveis, foram
realizadas pesquisas direcionadas à tecnologia de comunicação de redes celulares e as gerações
tecnológicas enfrentadas pelos mesmos. Além disso, com o intuito de adquirir conhecimento e
competência para o desenvolvimento do trabalho proposto, foram coletadas informações
importantes sobre JME e APIs usadas na codificação do sistema. Buscou-se também entender o
funcionamento de tecnologias para o desenvolvimento de aplicações móveis que não serão
iaplicadas ao projeto atual. Para essas pesquisas, foram utilizados materiais disponíveis na internet e
revistas, além de informações coletadas em livros.
O desenvolvimento do projeto foi iniciado com uma descrição geral sobre as principais
funcionalidades da aplicação. Em seguida, foram descritos os requisitos funcionais, não funcionais
e regras de negócio do sistema. Os requisitos funcionais foram identificados visando obter mais de
um tipo de mídia centrada numa pessoa, como imagem, áudio e vídeo e coordenadas GPS.
Na modelagem do sistema foi elaborado o diagrama de casos de uso e em seguida o
diagrama de classe com todas classes que fizeram parte do desenvolvimento do projeto. Ainda na
modelagem, foi feito o diagrama de seqüências para as principais funcionalidades do sistema,
conforme a linguagem UML (Unified Modeling Language). Na seqüência foi feita toda a
codificação das classes identificadas na modelagem do sistema, testes, avaliações e conclusões.
1.5 ESTRUTURA DO TRABALHO
Este trabalho está estruturado em quatro capítulos. O primeiro capítulo, Introdução,
apresenta uma breve descrição geral do que vem a ser o trabalho. No Capítulo dois, Fundamentação
Teórica, é apresentado os principais conceitos sobre computação móvel e questões tecnológicas que
estão envolvidas direta e indiretamente com este trabalho, além de ser documentado características
relacionadas à memória humana. No Capítulo 3, Desenvolvimento, é realizada toda a documentação
do desenvolvimento do projeto implantado no celular, como diagramas, requisitos e apresentação
das telas, além de ser mostrado os resultados alcançados. Por fim, nas Conclusões, são abordadas
questões apresentadas em todo o trabalho, problemas encontrados, entre outros.
15
2 FUNDAMENTAÇÃO TEÓRICA 2.1 MEMÓRIA HUMANA
Ao longo de sua vida, a memória humana armazena diversas informações. Apesar da
capacidade em armazenar grande quantidade de dados, o ser humano não é capaz de recordar todas
essas informações armazenadas. Quando consegue recordar alguns acontecimentos, muitas vezes é
com poucos detalhes e sem muita precisão. Há raros casos de pessoas que conseguem relembrar
com muita precisão acontecimentos vividos muitos anos antes. É o caso de A. J., uma mulher de 42
anos moradora da Califórnia. Ela se lembra de cada dia da usa vida desde a adolescência com extraordinário
detalhe. Quando alguém menciona qualquer data desde 1980 é como se A. J. fosse
imediatamente transportada de volta no tempo, descrevendo onde estava, o que estava
fazendo e quais foram as notícias daquele dia. Nos primeiros testes feitos com ela,
descobriram que ela era capaz de identificar corretamente a data de todas as Páscoas dos
últimos 24 anos. (MARSHALL, 2008).
A maioria das pessoas não carrega esse “fardo” de relembrar com muita precisão
acontecimentos vividos muito tempo atrás. De acordo com Schacter (2008), chefe do Departamento
de Psicologia da Universidade Harvard, o ser humano deixa de recordar porque o cérebro
desenvolveu estratégias para eliminar fatos irrelevantes ou ultrapassados. Essa característica,
chamada de esquecimento eficiente, é crucial para uma memória funcional.
Jacob Filho (2006) cita que:
Não conheço ninguém que esteja satisfeito com a própria memória. Embora o
esquecimento faça parte do processo de aprendizagem, todos nos revoltamos contra essa
traição do cérebro, às vezes, nas horas mais inconvenientes. É o menino que esqueceu quanto
é nove vezes oito bem na hora da prova de matemática, o adolescente que não se lembrou de
levar o material para o trabalho de grupo, o marido que deixou passar a data do aniversário
de casamento, o adulto que largou a chave do carro e a carteira não sabe onde.
Quanto ao tempo de armazenamento, a memória pode ser classificada em memória de curto
prazo e memória de longo prazo. No mesmo momento em que a informação está sendo recebida, a
memória de curto prazo está sendo processada. Nesta, a informação pode ser armazenada por
períodos mais longos ou descartada logo em seguida. Já na memória de longo prazo, segundo
Godoy (2004), estão contidos dados autobiográficos e nela a informação é retida de forma
definitiva.
16
De acordo com o neurocirurgião Godoy (2004), o esquecimento é uma falha na retenção ou
na evocação dos dados da memória. É um fenômeno comum que ocorre com qualquer pessoa.
Nesse sentido, as pessoas procuram combater o esquecimento de várias maneiras, como por
exemplo, fazendo anotações em cadernos ou até mesmo deixando recados de seus compromissos na
própria secretária eletrônica. Mas mesmo assim não há como deixar de escapar algumas
informações relevantes. Além disso, cada vez mais aumentam as buscas para a solução desse
problema.
2.2 MEMÓRIA DIGITAL E EXPANDIDA
Uma equipe de pesquisadores da Microsoft deu início a um projeto de memória digital e
expandida, em que quase todo o tipo de informação centrada numa pessoa é gravado. Este projeto,
chamado MyLifeBits, teve início através da vida de um dos próprios funcionários e autores do
projeto. Durante alguns anos, todos os documentos e interações de áudio, imagens e/ou vídeo
adquirida por Gordon Bell foi gravada em um arquivo pessoal.
Bell e Gemmel (2007) citam:
As memórias digitais podem fazer mais do que apenas auxiliar na lembrança de
eventos passados, conversas e projetos. Sensores portáteis podem até realizar leituras
impercebíveis pelos seres humanos, como o nível de oxigênio no sangue ou a quantidade de
dióxido de carbono no ar. Computadores podem então analisar esses dados para identificar
padrões: por exemplo, que condições ambientais agravam a asma de uma criança. Sensores
também poderiam registrar os cerca de três bilhões de batimentos cardíacos na vida de uma
pessoa, juntamente com outros indicadores fisiológicos, e alertar sobre um possível ataque
cardíaco.
Mas assim como muitas tecnologias hoje utilizadas, a idéia de gravar digitalmente toda
interação de uma pessoa não é recente. No final da Segunda Guerra Mundial, Vannevar Bush,
diretor da agência do governo americano, apresentou um dispositivo intitulado Memex (Figura 1),
em um artigo de 1945 chamado As We May Think.
17
Figura 1: Memex. Fonte: Scielo (1999).
Baseado em microfilmes, o Memex (memory extender – ou extensor de memória)
armazenaria uma biblioteca multimídia, como livros, fotos, gravações e comunicações de um
indivíduo. Este seria “montado em uma mesa e equipado com um teclado, um microfone e vários
visores. A pessoa sentada à mesa poderia usar uma câmera para fazer cópias em microfilme de fotos
e papéis, ou criar novos documentos escrevendo em uma tela sensível ao toque” (BELL e
GEMMEL, 2007).
Apesar de algumas das idéias de Bush terem sido desenvolvidas, o Memex não se
concretizou, pois este estava tecnologicamente fora de alcance para a época. Porém, nos últimos
anos, vários avanços tecnológicos se concretizaram, como o aumento da capacidade das mídias de
armazenamento e do desempenho de processadores, o desenvolvimento de sensores e dispositivos
portáteis. Com isso, permitiu-se ir além da idéia que Vannevar Bush teve décadas atrás.
O avanço tecnológico na capacidade de armazenamento de arquivos digitais foi e é intenso.
Hoje é comum encontrar no mercado discos rígidos para computadores pessoais de 160 gigabytes,
500 gigabytes e até mesmo de um terabyte. Com esse crescimento, torna-se possível armazenar
durante vários anos e-mails lidos, páginas da internet, livros e fotografias tiradas. É tão notável o
avanço que até mesmo dispositivos móveis estão cada vez suportando maiores capacidades de
armazenamento. O aparelho N96 da fabricante Nokia (Figura 2), com capacidade de 16 gigabytes é
um bom exemplo do avanço tecnológico nesse setor. E com todos esses bytes incorporados, as
mídias de armazenamento tornam-se mais acessíveis financeiramente para seus usuários finais.
18
Figura 2: Nokia N96. Fonte: Forum Nokia (2008).
Além disso, pode-se encontrar no mercado sensores que futuramente se tornarão mais
comuns no cotidiano das pessoas. Dentre outros, há sensores de luz, capazes de detectar mudanças
de luminosidade no ambiente, sensores de som, capazes de detectar mudanças sonoras, etc. “Alguns
sensores podem ser usados no corpo, outros são projetados para ser colocados em recintos ou
incorporados a aparelhos domésticos, como refrigeradores. E microfones e câmeras agora são tão
baratos que estão sendo instalados virtualmente em todos os lugares” (BELL e GEMMEL, 2007).
Empresas como VivoMetrics, da Califórnia, e BodyMedia, da Pensilvânia, já comercializam
sensores que podem ser usados no corpo, para por exemplo, monitorar o batimento cardíaco e a
respiração de uma pessoa.
O aumento do desempenho dos processadores é outro item que vem crescendo radicalmente.
Mais uma vez, os dispositivos móveis merecem destaque. Tais aparelhos eletrônicos, que antes
apenas serviam para conversação e mandar mensagens, hoje são capazes de executar vídeos e jogos
cada vez mais robustos e bem elaborados.
Muitas pessoas atualmente tiram mais fotografias quando comparado ao passado. Até a
invenção das câmeras digitais e de dispositivos móveis com tais recursos, a maioria das pessoas
tirava fotos apenas em ocasiões especiais, como no período de férias ou em eventos familiares.
Com todos esses avanços no mundo da tecnologia, mais e mais pessoas tendem a criar
registros digitais de suas vidas. Segundo Bell e Gemmel (2007), o interesse crescerá na medida em
que o processo de gravação digital se tornar mais fácil e mais amplo.
2.2.1 Projeto MyLifeBits
Em 1998, Gordon Bell decidiu desfazer-se de qualquer tipo de documentação pessoal e
19
profissional não digital, eliminando com isso pilhas de livros, memorandos, artigos, etc. Para isso,
ele escaneou toda essa montanha caótica de documentos e digitalizou suas gravações de vídeos e
outros tipos de mídia. Porém, após ter arquivado digitalmente todos os seus pertences, não obteve
bons resultados ao pesquisar tais documentos utilizando softwares disponíveis na época. Assim
surgiu o projeto MyLifeBits, que tem como objetivo registrar em multimídia tudo sobre a vida de
um indivíduo e dispor tais registros de forma organizada para posteriores consultas.
Bell e Gemmell (2007) citam que:
O projeto também forneceu a Gordon Bell uma variedade de ferramentas para
capturar suas interações com outras pessoas e máquinas. O sistema registra seus telefonemas
e seus programas de rádio e televisão. Quando trabalha em seu computador, o MyLifeBits
armazena automaticamente uma cópia de cada página de internet que ele visita e uma
transcrição de toda mensagem instantânea que ele envia ou recebe. Dentre outras
funcionalidades, o sistema monitora até mesmo que janelas estão em primeiro plano em sua
tela e a atividade do mouse e do teclado.
Além disso, um grupo de pesquisadores da Microsoft em Cambridge desenvolveu uma
câmera digital usada a partir das próprias vestimentas da pessoa, mais especificamente, ao redor do
pescoço como se fosse um colar. Essa câmera, chamada SenseCam, é capaz de tirar fotos a cada 30
segundos e em momentos propícios, como na mudança de luminosidade. Na Figura 3, é apresentado
a SenseCam.
Figura 3: SenseCam desenvolvida pela Microsoft. Fonte: MailOnline (2007).
O IDGNOW (2008) cita que:
Com um cartão de memória SD de 1 GB, o SenseCam pode tirar até trinta mil
imagens com resolução de 640 x 480 pixels. A especificação não é muito impressionante
frente à resolução das câmeras digitais atuais, mas é suficiente para recordar, afirmou Steve
20
Hodges, que gerencia o projeto no Microsoft Research, em Cambridge.
Apesar da baixa resolução das fotos, a SenseCam tem despertado bastante interesse no
campo da medicina para pacientes com deficiência de memória. De acordo com o IDGNOW
(2008), Emma Berry, neuropsicóloga do Hospital Addenbrooke, está trabalhando com uma paciente
de 68 anos diagnosticada há vários anos com graves problemas de memória. A paciente não
consegue lembrar-se de atividades feitas na manhã do dia anterior, por exemplo. Ao rever as
imagens tiradas pela SenseCam, a paciente teve uma excepcional recuperação de memória.
Além disso, outros projetos relacionados à memória digital estão sendo patrocinados pela
Microsoft. Um destes, chamado MyHealthBits, propõe obter um grande volume de informações
relacionados a saúde de uma pessoa, como pressão sangüínea, temperatura corporal e batimento
cardíaco, usando para isso computadores e sensores pessoais.
Depois de alguns anos de grande esforço e trabalho, Gordon Bell armazenou uma grande
biblioteca multimídia, com milhares de e-mails, arquivos PowerPoint, arquivos de áudio e vídeo,
etc. Com isso, tornou-se possível pesquisar através do software de pesquisa grande parte de sua vida
profissional, como por exemplo, de acordo com Bell e Gemmell (2007), sites de internet para
citações de seus trabalhos de pesquisa, informações para fornecer aos médicos sobre uma cirurgia
feita há muitos anos, e vários outros itens de sua vida pessoal e profissional. Dentre outras
funcionalidades, o software de pesquisa fornece representações em forma de gráficos com todos os
arquivos armazenados, como mostra a Figura 4.
Figura 4: Ilustração dos arquivos em forma de gráfico. Fonte: Microsoft (2003).
21
A ramificação de vantagens e possibilidades oferecida pelo projeto MyLifeBits não é
pequena, mas a isenção de problemas não é algo distante. Vários anos da vida de um indivíduo com
problemas na justiça armazenado em formatos digitais poderiam facilmente ser usados a favor ou
contra ele em um tribunal. Outro fator relevante seria a segurança da informação, onde uma vida
inteira poderia ser “roubada”, possibilitando aos criminosos o acesso a todas as informações
profissionais e pessoais de uma pessoa. De acordo com Bell e Gemmel (2007), a maioria das
pessoas já tem informações sensíveis em seus computadores. A segurança é uma preocupação
saliente em qualquer cenário, não apenas quando se pensa em armazenar memórias digitalmente
(apesar de que o armazenamento de uma vida inteira em um único arquivo torna o problema
quantitativamente pior, se não qualitativamente).
Apesar dos problemas que podem vir a acontecer, as vantagens oferecidas pelo MyLifeBits
obscurecem quase todas, senão todas as desvantagens proporcionadas pelo projeto. Com todos os
avanços tecnológicos, a memória digital deixou de ser mera ficção científica ou algo inatingível,
tornando-se hoje uma tecnologia “concreta” e de grande importância para a humanidade.
2.3 MULTIMÍDIA
Quando uma informação é transmitida contendo mais de uma forma (textos, figuras, sons), o
conceito de multimídia está sendo usado. “Multimídia é qualquer combinação de texto, arte gráfica,
som, animação e vídeo transmitida pelo computador” (VAUGHAN, 1994).
Além disso, foi criado outro conceito relacionado à multimídia, chamado de hipermídia. De
acordo com Pádua Filho (2000), “os títulos hipermídia derivam do conceito de hipertextos, em que
o encadeamento de referências permite a consulta não-seqüencial de uma base de informação de
texto. Ao hipertexto, a hipermídia acrescenta gráficos, imagens, som e animações”.
Para a representação do conteúdo multimídia, há diversos formatos de arquivos disponíveis
no mercado, tanto para imagens estáticas ou em movimento, quanto para áudio ou vídeo, cada um
obedecendo às especificações de suas plataformas e desenvolvedores.
2.3.1 Arquivos de imagem
As imagens são formadas por um conjunto de pixels (picture element). Um pixel é a menor
unidade de representação de uma imagem em um monitor, ou seja, uma imagem digitalizada.
Devido aos vários formatos de imagens disponíveis no mercado, Pádua Filho (2000) cita algumas
características para escolha de um formato:
22
● as resoluções suportadas, geralmente, começam no padrão VGA mínimo de 320 X 200,
podendo chegar às resoluções de milhares de linhas;
● em muitos formatos, os pixels que compõem a imagem sofrem algum tipo de compressão,
reduzindo o tamanho do arquivo;
Os principais formatos de imagem e os mais encontrados são:
● GIF (Graphics Interchange Format): criado e introduzido pela CompuServe em 1987, é
uns dos formatos mais usados para distribuição comercial de imagens, utilizando o
algoritmo com compressão sem perdas chamado LZW (Lempel-Ziv-Welch);
● PNG (Portable Network Graphics): semelhante ao GIF, o PNG foi desenvolvido como
uma alternativa sem custos de uso ao formato anterior apresentado, sendo esta a principal
diferença em relação ao formato GIF. Mas a patente do formato GIF já se encontra
expirada, sendo agora de domínio público;
● TIFF: o TIFF (Tagged Image File Format) é um “padrão independente de fabricante para
imagens de alta resolução espacial e em cores”. (PÁDUA FILHO, 2000);
● BMP: o BMP (BitMap – Mapa de bits) é o formato gráfico padrão para sistemas
operacionais Windows;
● JPEG: o JPEG (Joint Photographic Experts Group) é um formato de compressão
adequado para imagens que tenham variações suaves de intensidade, geradas por captura
de fotos. De acordo com Pádua Filho (2000), o JPEG é um padrão complexo, com suporte
para diversos tipos de algoritmos de compressão.
● TGA (Targa): “usado pelos adaptadores gráficos Targa, e por muitos programas de
animação e processamento de vídeo” (PÁDUA FILHO, 2000).
2.3.2 Arquivos de Vídeo
Nos recursos multimídia, os vídeos já se tornaram um item muito importante para fornecer
uma apresentação de um conteúdo mais agradável ao usuário. A popularização e o aumento de
banda na Internet (a própria Internet é um grande centro multimídia) favoreceram o aumento de
apresentações multimídia utilizando vídeos.
Pádua Filho (2000) descreve que:
23
A enorme capacidade de processamento de dados da visão humana se reflete nos
requisitos para armazenamento e transmissão de imagens em movimento. Uma imagem
típica de vídeo, com qualidade de televisão, ocupa cerca de 512 X 480 pixels, ou seja, 240 K
pixels. Em um sistema de cor verdadeira, isto significa 3 bytes por pixels, dando um total de
720 KB. Um segundo de vídeo compreende 30 quadros, dando um total de 21.600 KB.
Em função disso, para um armazenamento maior de arquivos e viabilizar a transmissão via
Internet, as técnicas de compressão e descompressão de vídeo são importantes. Estas são extensões
das técnicas de compressão de imagens. Os algoritmos responsáveis pela compressão e
descompressão de arquivos são chamados de codec (coder/decoder - codificador/decodificador).
Grande parte dos codecs utiliza a compressão com perdas, ou seja, no processo de
compressão partes do arquivo são descartadas, resultando na perda de qualidade com a finalidade de
maiores taxas de compressão. Algumas das tecnologias que utilizam essa técnica são:
● JPEG em movimento (motion JPEG): extensão do padrão JPEG, “cada quadro é
simplesmente comprimido segundo o método JPEG, não havendo compressão temporal.
Por isso, a taxa de compressão conseguida é limitada, e a decodificação requer
processamento intensivo”. (PÁDUA FILHO, 2000).
● MPEG (Motion Picture Experts Group): “estende o JPEG para seqüências de imagens
animadas, aproveitando o princípio da coerência entre quadros. É o padrão mais
importante para compressão de vídeo digital. O material MPEG pode consistir em vídeo
ou áudio separados, ou na combinação destes”. (PÁDUA FILHO, 2000).
Há vários formatos de arquivos de vídeo disponíveis no mercado, como o AVI (áudio-video-
interleaved) usado em sistemas operacionais Windows, o MOV para o player (tocador) QuickTime
da Apple, o RM, que é um formato proprietário da Real Networks, entre outros.
2.3.3 Arquivos de Áudio
As apresentações multimídia composta por vídeos normalmente agregam a estas recursos de
áudio, tornando-as mais atraentes para seus usuários. Pádua Filho (2000) relata que a audição é o
resultado da percepção de flutuações periódicas da pressão em um meio. Os limites da percepção
desempenham um papel central no processo de representação do som em computadores e outros
sistemas digitais.
24
Em sistemas eletrônicos digitais, o som é representado por seqüências de números.
Microcomputadores com recursos multimídia são capazes de suportar sons analógicos, arquivos de
áudio, como arquivos WAV e sons sintetizados por meio de arquivos de eventos musicais, como
arquivos MID.
Embora o fluxo de informação de áudio seja na maioria das vezes baixo, quando
comparados aos vídeos, em determinados casos a compressão é realizada. Um exemplo é a
compressão MP3, sendo “um método de compressão de áudio embutido nas tecnologias MPEG de
vídeo que consegue reduzir um fluxo de qualidade CD de um fator de 10 a 12, com perda de
qualidade pouco perceptível”. (PÁDUA FILHO, 2000).
Atualmente, a maioria dos computadores pessoais encontrados no mercado vem pronto para
o uso intenso da multimídia, fornecendo recursos como placas de vídeo, para a reprodução de
imagens gráficas, placas de som, para reprodução de áudio, gravadores de CD-ROM e DVD, alto-
falantes, entre outros.
2.4 MULTIMÍDIA BASEADA EM CELULARES
Assim como o início da computação digital, os primeiros celulares lançados no mercado
apresentavam suas informações através apenas de um formato, o texto. Pelas limitações de recursos
dos aparelhos e interfaces aéreas (tecnologias para a transmissão de dados via celular), o modo texto
predominou no início da tecnologia celular.
À medida que os aparelhos móveis e interfaces aéreas evoluem (gerações dos celulares),
tecnologias mais avançadas são desenvolvidas e incorporadas nos celulares. “Devido ao constante
crescimento da capacidade de processamento e de armazenamento dos celulares, surge cada vez
mais idéias e necessidades a serem colocadas em prática. Uma delas é a multimídia”. (GALL,
2006). Segundo o site tecnológico INFO Online2, a fabricante Nokia revelou que o setor de
multimídia é o que mais cresce no setor de telefonia móvel, e neste ano já foram vendidos mais de
10 milhões de aparelhos da sofisticada série N (aparelhos com vários recursos multimídia – Figura
5).
2 INFO online. Disponível em: <http://info.abril.com.br/aberto/infonews/092006/26092006-12.shl>. Acesso em: 01 Maio 2008.
25
Figura 5 – Modelo da Nokia com recursos multimídia. Fonte: Info (2006).
A multimídia baseada nos dispositivos móveis está em constante evolução. Quando
empregada nos aparelhos celulares, disponibiliza diversas funcionalidades para seus usuários.
Jogos, downloads de músicas e de filmes, fotografia digital e envio de mensagens multimídia
(MMS) são alguns dos recursos oferecidos por esse setor.
No caso específico da tecnologia MMS, Azevedo (2006) diz que os serviços de mensagens
multimídia vêm ganhando força nos últimos anos. O faturamento global das operadoras no ano de
2005 foi duas vezes maior em relação ao ano de 2004, segundo o instituto Júpiter Research. Este
crescimento foi sustentado basicamente pela troca de mensagens multimídia entre usuários de
celular.
A possibilidade de retirar imagens fotográficas por meio dos celulares é uma grande
evolução tecnológica dos fabricantes, facilitando com isso o acesso a câmeras digitais integradas
nos dispositivos móveis. Hoje pode ser encontrados no mercado celulares com câmera de 3
megapixels, 5 megapixels e até mais. Portanto, celulares com essas características aos poucos
substituem câmeras digitais convencionais.
Apesar das grandes vantagens, a multimídia nos aparelhos móveis agrega também algumas
desvantagens. Além de outros fatores inerentes ao celular, como display e teclado reduzido,
aplicações multimídia exigem um poder maior de processamento, acarretando em um maior
consumo de bateria. Com isso, a autonomia de uso do aparelho tem um rendimento prejudicado.
26
Mas de acordo com Oliveira, Soares, Fernandes (2004), com a introdução de baterias mais
avançadas, como a íon de lítio (Li-Ion), os aparelhos puderam alcançar tempo médio de
conversação de 5 horas e 10 dias em standby, aumentaram suas taxas de dados e inseriram
dispositivos como câmeras fotográficas com flash e interfaces como o bluetooth (comunicação sem
fio à curtas distâncias).
Além dos formatos de arquivos e compressores já apresentados no início do capítulo, há
vários outros disponíveis no mercado e que são suportados pelos celulares, tanto para imagens,
áudio e vídeo. Por exemplo, para formatos de áudio e vídeo, pode-se destacar o AAC (Advanced
Audio Coding), que é um formato (compressor) para áudio mais recente do que o conhecido MP3, e
o H.263, que possui uma qualidade maior para apresentações de vídeo em relação ao seu antecessor
(H.261).
2.5 TECNOLOGIAS DE REDES MÓVEIS E CELULARES
2.5.1 Telefonia Móvel
Cada vez mais as pessoas querem estar informadas sobre o mundo ao seu redor,
independentes de sua localização. Para isso, estão à sua disposição aparelhos fáceis de serem
carregados e com funcionalidades diversas, agregando com estes o sistema de telefonia móvel. Os
celulares são os principais e mais comuns aparelhos portáteis encontrados em todo mundo.
O primeiro sistema móvel foi criado pela AT&T nos EUA. Já na Europa, cada país criou o
seu próprio sistema de telefonia móvel, resultando em falta de integração e compatibilidade. Mas
com a chegada da tecnologia digital, todos os países da Europa passaram a utilizar um mesmo
sistema (GSM).
Em 1997, foi definido no Brasil o modelo para Telefonia Celular, chamada SMC (Serviço
Móvel Celular), operando na faixa de freqüência de 800 MHz. Conforme definição da agência
nacional de telecomunicações (ANATEL), o SMC é um serviço de telecomunicações móvel
terrestre que utiliza sistemas de comunicações de rádio com técnica celular. Aproximadamente
quatro anos depois, a Anatel criou um novo serviço, chamado SMP (Serviço Móvel Pessoal),
operando na faixa de freqüência de 1,8 GHz.
No Brasil, o sistema de telefonia celular foi iniciado em 1991, com a implantação do sistema
de transmissão analógica chamado AMPS (Advanced Mobile Phone Service). Mas com a
27
implantação de sistemas digitais, o sistema AMPS teve a redução gradual do número de usuários,
representando menos de 3% de acessos móveis no final de 2002.
Dentre as tecnologias oferecidas pelas as operadoras de telefonia móvel, o sistema GSM é o
que tem apresentado o maior crescimento e, conseqüentemente, a liderança de mercado. Segundo o
portal 3G Americas (www.3gamericas.org), a tecnologia GSM alcançou uma participação de
mercado acima de 50% na região das Américas, atraindo praticamente 100 milhões de novos
clientes no período entre junho de 2005 e junho de 2006.
No Brasil, de acordo com a Anatel3 para o mês de abril de 2006, o sistema GSM manteve uma
quantidade total de assinantes de 50.098.252, seguida da CDMA, com 24.955.739, da TDMA, com
15.411.337, e por último da tecnologia analógica, com 118.859 acessos.
Mas segundo Erasmo Rojas (diretor da 3G Américas para a América Latina e Caribe),
conforme ilustrado no site 3G Americas4, a tecnologia CDMA “está perdendo o fôlego no Brasil e
nas Américas, e operadoras como a Vivo, líder de mercado brasileiro, estão implementando a
tecnologia GSM por motivos claros”.
As políticas e tarifas de cobrança pelo uso do serviço móvel pessoal variam de operadora pra
operadora. Além disso, a tarifa cobrada depende dos vários planos de serviços oferecidos por esta,
das tecnologias e/ou operadoras envolvidas e ainda se o destino da chamada for um telefone fixo.
De acordo com o portal Teleco, para chamadas locais o valor é definido por minuto e cobrado em
unidades de 6 segundos. Para mensagens MMS a tarifa também varia conforme o plano de serviço e
a operadora envolvida.
2.5.2 Tecnologia de Redes Celulares
A primeira chamada de um aparelho celular foi realizada por Martin Cooper (na ocasião,
diretor da Motorola) no ano de 1973. Mas o conceito de telefonia celular, na verdade, surgiu em
1947 pelos laboratórios Bell. Um único transmissor de sinais e apenas um canal eram utilizados,
tanto para transmissões quanto para recepções. “Para conversar, o usuário tinha de apertar um botão
3 Anatel. Disponível em: <http://www.anatel.gov.br/Tools/frame.asp?link=/biblioteca/releases/2006/release_19_06_2006mm.pdf>. Acesso em: 22 Agosto 2008. 4 3G Americas. Disponível em: <http://www.3gamericas.org/Portuguese/News_room/DisplayPressRelease.cfm?id=2809&s=POR>. Acesso em:03 Outubro 2008.
28
que ativava o transmissor e desativava o receptor” (TANENBAUM, 2003). Esse sistema ficou
conhecido como push-to-talk.
De acordo com Rodrigues (2000), os primeiros sistemas móveis focavam a grande área de
cobertura, utilizando um único transmissor de alta potência situado em um local elevado. Apesar da
boa cobertura, o número de usuários era limitado. Uma reestruturação no sistema de telefonia era
inevitável. A Figura 6 apresenta a topologia de uma rede celular.
Figura 6 – Topologia de uma rede celular. Fonte: Autoria própria.
Em uma região a ser coberta pela rede de telefonia celular, a área total foi dividida em áreas
menores, chamadas células (por esse motivo esses aparelhos são chamados de telefones celulares).
Sousa (1998) diz que na telefonia celular a transmissão do sinal de áudio é feita por meio de
radiofreqüência, ao invés de pares de fios da rede telefônica. A forma de operação é semelhante ao
telefone comum, mudando apenas o meio de transmissão. “Ele é baseado na possibilidade de
reutilização das freqüências de áudio, distribuídas em diferentes partes em uma área, mas
suficientemente distintas umas das outras para evitar interferências” (ANTUNES, 1998). Com essa
técnica, aumenta a capacidade do tráfego em uma rede celular.
Cada célula contém uma entidade chamada ERB (Estação Rádio-Base ou apenas Estação
Base). Cada ERB é responsável pela sua área, recebendo e transmitindo sinais telefônicos para
outras ERBs e/ou estações móveis (celulares, PDAs, etc.). A ERB possui dois elementos básicos: a
29
parte de rádio e o controle. “O rádio engloba todo o conjunto de transmissão e recepção, além de
torres e antenas. O controle é uma unidade com microprocessador responsável pelo controle,
monitoração e supervisão das chamadas” (RODRIGUES, 2000). Outra função monitorada pelas
ERBs, é o nível de sinal dos aparelhos móveis (handoff).
Tanembaum (2003) diz que:
A estação base consiste em um computador e um transmissor/receptor conectados a
uma antena. Em um sistema de pequeno porte, todas as estações base estão conectadas a um
único dispositivo chamado MTSO (Mobile Telephone Switching Oflice - estação de
comutação de telefonia móvel) ou MSC (Mobile Switching Center - centro de comutação
móvel). Em um sistema maior, podem ser necessárias diversas MTSOs, todas conectadas a
uma MTSO de segundo nível e assim por diante.
As MSCs são, freqüentemente, chamadas também de Central de Comutação e Controle
(CCC). De acordo com Sousa (1998), a Central de Comutação e Controle é uma central telefônica
que faz a interconexão das estações rádio-base com as centrais públicas de telefonia comum (Rede
de Telefonia Pública Comutada - PSTN), permitindo a conexão dos aparelhos celulares a telefones
convencionais. “Uma CCC efetua todo o controle das operações atuando como um ‘cérebro’ do
sistema. A capacidade de processamento da CCC deve ser suficientemente grande para poder
atender toda uma área geográfica” (ANTUNES, 1998).
As estações móveis (EM) são os dispositivos portáteis que fazem a comunicação através de
canais de rádio com as ERBs. Sousa (1998) relata que a estação móvel sintoniza com a ERB da
célula que tem o sinal mais forte, portanto a célula em que está dentro. O modo de transmissão full-
duplex é o modo utilizado para a comunicação das estações móveis com as ERB´s. Nesse modo de
operação, a comunicação entre EM e ERB acontece nos dois sentidos simultaneamente, permitindo
ao dispositivo móvel transmitir e receber dados ao mesmo tempo com suas estações rádio-base.
Dependendo das necessidades, a área de operação de uma CCC pode variar. Segundo
Rodrigues (2000), dá-se o nome de área de serviço à área em que uma CCC serve e assinante local
(home) ao usuário que usa o serviço.
Toda estação móvel é registrada em uma área local, chamada área de serviço (ou área de
mobilidade). Esse usuário se torna um visitante caso ele se desloque a uma área diferente da área de
serviço de sua CCC, ou seja, “ele é um assinante visitante no sistema celular daquela região” (Souza
e Tude, 2002). Esse processo é conhecido como roaming.
30
Outro processo em função do deslocamento do usuário dá-se quando um telefone móvel
muda de região da célula em que se encontra para outra célula. O sinal é transferido
automaticamente para a região da nova ERB, sendo imperceptível ao usuário. Esse processo é
chamado de handoff ou handover. “O handoff é a transferência de uma estação móvel ERB para
outra, dentro de uma mesma Central de Comutação e Controle” (ANTUNES, 1998).
2.6 GERAÇÕES DAS REDES CELULARES
Segundo Tanenbaum (2003), ao longo de sua evolução, o sistema de telefonia móvel passou
por três gerações isoladas: voz analógica; voz digital; voz digital e dados. A seguir é abordada cada
geração e as tecnologias introduzidas por cada uma delas.
2.6.1 Primeira Geração de Sistemas Móveis (1G)
Ao ser lançado a primeira geração, quase não se sabia sobre seu potencial e tendências.
Devido a isso, vários padrões foram implementados. Um deles foi implantado nos anos 60,
intitulado IMTS (Improved Mobile Telephone System – Sistema de Telefonia Móvel Aperfeiçoado).
Tanenbaum (2003) cita que:
O IMTS admitia 23 canais espalhados pelas freqüências de 150 a 450 MHz. Devido
ao pequeno número de canais, muitas vezes os usuários tinham de esperar muito tempo antes
de obter um tom de discagem. Além disso, devido à alta potência do transmissor, os sistemas
adjacentes tinham de estar a diversos quilômetros de distância uns dos outros para evitar
interferência. Em suma, o sistema era impraticável devido à sua limitada capacidade.
Porém, criado pelos Laboratórios Bell, o primeiro sistema de primeira geração foi instalado
apenas em 1982, nos Estados Unidos, chamado de AMPS (Advanced Mobile Phone System –
Sistema Avançado de Telefonia Móvel).
Sverzut (2005) diz que depois de consolidada a primeira geração, a Europa estava dividida,
ou seja, vários sistemas implantados sem uma padronização entre eles. No continente europeu,
foram implantados os seguintes sistemas:
● TACS: Reino Unido, Áustria, Espanha, Irlanda e Itália;
● NMT450: Suécia, Noruega, Finlândia, Dinamarca; e
● Radiocom2000: França.
31
O Brasil adotou o mesmo padrão implantado nos Estados Unidos, o AMPS, operando na
faixa de 800 MHz e com banda de 50 MHz, podendo ser dividida entre duas operadoras (banda A e
banda B).
2.6.2 Segunda Geração de Sistemas Móveis (2G)
Os serviços de comunicações de segunda geração são baseados em sistemas de alto
desempenho, alguns com capacidade, no mínimo, três vezes superior às dos sistemas de primeira
geração. Caracterizam-se, em geral, pela utilização de tecnologia digital para transmissão tanto de
voz quanto de sinalização (PLANETA CELULAR, 2004).
Segundo Sverzut (2005), o foco principal dos padrões 2G era oferecer telefonia para o
usuário. Desta forma, os protocolos de transmissão de dados de segunda geração são apenas
adaptações do canal de voz para a transferência de bits de dados.
O sistema chamado PCS (Personal Communications Services, serviços pessoais de
comunicações) “às vezes é usado na literatura de marketing para indicar um sistema de segunda
geração. Originalmente, ele representava um telefone celular que emprega a banda de 1900 MHz”
(TANENBAUM, 2003). O PCS, com o tamanho de suas células menores, inclui serviços como
telemensagens, e-mail e bina.
Porém, os verdadeiros sistemas introduzidos na segunda geração são representados pelas
seguintes tecnologias: D-AMPS, GSM (Global System for Mobile Communications), CDMA (Code
Division Multiple Access) e PDC. O PDC (Personal Digital Cellular) é um sistema digital usado
exclusivamente no Japão e, segundo Tanembaum (2003), “é basicamente o D-AMPS modificado
para compatibilidade retroativa com o sistema analógico japonês de primeira geração”.
O sistema GSM é um dos mais utilizados para comunicação móvel. De acordo com Sverzut
(2005), na América Latina, o GSM é a tecnologia que apresenta o maior índice de crescimento em
relação àquelas tecnologias disponíveis no mercado, com um crescimento de 58,8% no número de
usuários.
O GSM originou-se em 1982 através de um consórcio de países europeus, intitulado Group
Spéciale Móbile (GSM). Além de suportes avançados que redes analógicas não ofereciam, esse
grupo visava criar uma tecnologia que permitisse roaming internacional sem maiores problemas.
Em 1989, com algumas especificações técnicas já feitas, a responsabilidade desse projeto passou
32
para o Instituto Europeu de Normas de Telecomunicações (European Telecommunications
Standards Institute - ETSI). Porém, a primeira rede GSM foi lançada apenas em 1991.
Já o sistema CDMA utiliza uma tecnologia de acesso múltiplo por divisão de código. De
acordo com Tanembaum (2003), graças à persistência de uma empresa chamada Qualcomm, o
CDMA pode ser visto hoje como a base dos sistemas móveis de terceira geração. Nos EUA, ele é
muito utilizado em sistemas móveis de segunda geração.
2.6.3 Sistemas Móveis de 2.5G e 2.75G
Sistemas móveis de 2.5G e 2.75G são tecnologias disponíveis intermediárias da terceira
geração, “desenvolvidos para suportar a troca de mensagens, e-mails e acesso a páginas da web”
(SVERZUT, 2005). São melhorias acrescentadas às tecnologias de segunda geração.
A Figura 7 ilustra toda a trajetória dos sistemas móveis até a terceira geração.
Figura 7 – Evolução dos padrões celulares. Fonte: Sverzut (2005).
De acordo com Sverzut (2005), o serviço GPRS utiliza os recursos já existentes na rede
GSM, porém acrescenta uma infra-estrutura para suportar a comunicação de dados (transferência de
pacotes) pelo protocolo IP (Internet Protocol), que posteriormente será usada na integração dos
serviços de voz (voz sobre IP - VoIP) e dados de terceira geração.
Sverzut (2005) cita também algumas aplicações importantes a serem introduzidas por esse
serviço:
• Comércio eletrônico (e-commerce): venda de ingressos, acesso a banco e compras pela
internet;
33
• Aplicação de localização baseadas (location-based): navegação, informação sobre as
condições de tráfego, informações sobre vôos; e
• Avisos: informações sobre promoções ao entrar em recintos comerciais (por exemplo,
shopping centers), viagens, meteorologia etc.
O GPRS introduz a comutação de pacotes nas redes GSM, sendo que esta utiliza a
comutação de circuitos (transferência de dados não muito eficiente). “A comutação de pacotes é
uma modalidade de transferência de dados específica para tratar devidamente as características de
uma comunicação de dados” (SVERZUT, 2005).
Conhecido também como GPRS melhorado (Enhanced General Packet Radio Service -
EGPRS), o EDGE é uma evolução do GPRS, oferecendo em média três vezes mais capacidade de
transporte de dados em relação ao seu antecessor.
Soares (2003) diz que:
O EDGE está relacionado ao aumento da capacidade de transmissão da interface aérea no
corrente padrão GSM. A principal idéia é adicionar novas características na rede GSM,
mantendo compatibilidade com os telefones celulares GSM /GPRS e com os equipamentos
da rede (BSS, BSC, TRAU, MSC, SGSN e GGSN).
Conforme Sverzut (2005), a tecnologia EDGE permite uma transmissão de dados três vezes
maior do que a GPRS.
2.6.4 Terceira Geração de Sistemas Móveis (3G)
Os sistemas celulares de primeira geração eram totalmente analógicos, com o foco principal
no tráfego de voz. Já os sistemas de segunda geração evoluíram de analógicos para sistemas
digitais, mas foram projetados para o envio de voz ou dados utilizando baixas taxas de
transferência.
Na mesma proporção que a internet evoluia, os sistemas móveis começaram a adquirir
funcionalidades mais poderosas e modernas. O perfil dos usuários aos poucos também começou a
mudar. Apenas realizar chamadas de voz (ou até mesmo o envio de mensagens de texto) já não era
suficiente para agradar a essa demanda de novos assinantes.
34
A terceira geração da telefonia celular veio para atender a todos esses usuários que cada vez
se tornam mais exigente. Além de outros serviços, com o advento da terceira geração se tornou
possível:
• Acesso à internet;
• Serviços multimídia, como reprodução de áudio e vídeo, fotos digitais e acesso à
canais de televisão;
• Jogos online em tempo real; e
• Envio de mensagens SMS com imagens anexadas.
Em 1989, de acordo com Sverzut (2005), visando obter um padrão para sistemas de terceira
geração, a União Internacional de Telecomunicações (UIT ou International Telecommunication
Union - ITU) apresentou um documento contendo as características gerais do sistema, requisitos
mínimos para sua operação e restrições de funcionamento.
A esse projeto deu-se o nome de IMT-2000 (International Mobile Telephony 2000 –
Telecomunicações Móveis Internacionais 2000). Desde então, várias empresas e órgãos ao redor do
mundo começaram a estudar e propor soluções para atingir às especificações desse projeto de
terceira geração. Várias propostas foram submetidas a ITU. A seguir algumas delas:
• UWC-136: Universal Wireless Communications (evolução do padrão IS-136);
• UTRA: Universal Terrestrial Radio Access;
• SAT-CDMA: Satellite CDMA;
• UMTS: Universal Mobile Telecommunications System (evolução do padrão
GSM - especificação adotada pela União Européia);
• DECT: Digital Enhanced Cordless Telecommunications;
• WCDMA: Wideband CDMA; e
• CDMA2000: Wideband CDMA (evolução do padrão IS-95).
Sverzut (2005) diz que quatro dessas propostas foram selecionadas pelo ITU: WCDMA,
CDMA2000, UTRA e DECT. Na prática, as propostas UTRA e WCDMA foram unificadas pelo
35
UMTS (ou seja, UMTS, UTRA e WCDMA é uma única tecnologia). Mas conforme as
características do mercado de sistemas de segunda geração, a expectativa é que o padrão UMTS
(tecnologia WCDMA) e o CDMA2000 sejam as tecnologias implantadas.
2.7 GPS
A sigla GPS significa Global Positioning System (Sistema de Posicionamento Global), e foi
criado pelos Estados Unidos da América no final da década de 70 para propósitos militares. Com
um receptor de sinais GPS, esse sistema fornece as coordenadas (latitude, longitude e altitude) de
um lugar na Terra. Era utilizado principalmente pelas forças armadas norte-americanas e não era
liberado para civis. Portanto, a margem de erro propositadamente era de aproximadamente 100
metros. Ao ser liberado, a margem de erro passou para entre 5 e 10 metros.
O sistema GPS engloba três órbitas com oito satélites cada uma ao redor da Terra. A
organização das órbitas está disposta de tal forma que cada receptor em algum ponto da Terra é
capaz de identificar pelo menos quatro satélites em qualquer momento do dia. Dessa forma, usando
um ponto de trigonometria, as coordenadas são calculadas. Além disso, há estações de controle
terrestres que têm como função corrigir as órbitas dos satélites, caso necessário.
Daniel Oliveira (2006) descreve que:
Cada satélite e usuário devem sincronizar seus relógios internos entre si. Esse
relógio é conhecido como UTC (Universal Time Coordinated) e marca o horário no
meridiano de Greenwich. O usuário deve se comunicar com pelo menos quatro satélites. O
sinal transmitido carrega informações de posicionamento do satélite transmissor em relação
ao sistema de coordenadas da Terra e o instante em que o sinal foi enviado. O usuário, após a
recepção, verifica o tempo gasto na propagação e com isso calcula sua distância em relação à
fonte do sinal.
Além de outras informações possíveis, como distância percorrida ou velocidade, ao ser
concluído o cálculo do posicionamento do receptor GPS, dois parâmetros retornados são suficientes
para descobrir em qual ponto da superfície da Terra o receptor GPS se encontra. Esses parâmetros
são representados pela latitude e longitude.
A latitude são linhas imaginárias paralelas entre si e ao Equador, medida ao longo do
meridiano de Greenwich. Segundo Daniel Oliveira (2006), o pólo norte representa a latitude 90
graus norte (+90 graus) e o pólo sul 90 graus sul (-90 graus).
36
A longitude são linhas imaginárias que definem a posição leste-oeste na superfície da Terra,
medida ao longo da linha do Equador, de 0 a 180 para leste ou para oeste, sendo “a longitude 0
graus, 100 metros a leste do meridiano que passa por Greenwich, na Inglaterra” (DANIEL
OLIVEIRA, 2006).
Há no mercado diversos aparelhos capazes de receber sinais GPS. Além disso, automóveis e
até mesmo alguns telefones celulares hoje já vem de fábrica com um receptor GPS acoplado para o
mesmo propósito, facilitando com isso o desenvolvimento de aplicações para telefones celulares
que usam dados de posicionamento global.
2.8 TECNOLOGIAS DE DESENVOVIMENTO
A partir da evolução das gerações de telefonia móvel, recursos de banda e capacidade dos
dispositivos móveis, diferentes tecnologias foram desenvolvidas para o acesso a dados via internet e
também para a criação de aplicativos móveis. Com a finalidade de fornecer acesso à internet aos
dispositivos móveis, pode-se destacar o protocolo WAP (Wireless Application Protocol). Para o
desenvolvimento de aplicativos móveis, as principais tecnologias encontradas no mercado são:
linguagem SuperWaba , Visual Studio, IDE Netbeans, WAP, BREW, Symbian e Java ME. Todas
essas tecnologias fornecem poderosos recursos para o desenvolvimento de aplicativos móveis, cada
uma com suas peculiaridades e plataformas distintas.
2.8.1 SUPERWABA
O SuperWaba é uma plataforma para desenvolvimento de aplicações para PDA (Personal
Digital Assistants) e Smartphones. (SUPERWABA, 2006). Ele é um projeto OpenSource derivado
do projeto chamado Waba, mantido pela WabaSoft.
Waba é uma máquina virtual Java destinada a aplicações móveis presente atualmente para as
plataformas DOS, Linux, Windows CE, Gameboy e PalmOS. (PEREIRA, 2005). A biblioteca de
classe do Waba é designada para ser simples e fácil de programar. É composta por todas as classes
básicas que possibilitam criar programas avançados como I/O, networking (redes), interface com
usuário e classes gráficas. A Waba Virtual Machine pode ser criada e executada em quantidades
muito pequenas de memória. Por exemplo, o completo Waba Virtual Machine para o PalmPilot é
em torno de 60K.
37
Em 1999, Rick Wild, dono do projeto Waba, começou a desenvolvê-lo, mas, pouco tempo
depois, o projeto foi descontinuado. No começo do ano 2000, o brasileiro Guilherme Campos
Hazan, após ter conhecido Rick Wild, começou a desenvolver novas funcionalidades e a melhorar o
desenvolvimento de alguns aspectos do projeto Waba, como suporte a mais tipos de cores, suporte a
threads e suporte a bibliotecas em C e em Java. Sendo assim, o SuperWaba é uma versão melhorada
do Waba, rodando em aparelhos com os sistemas WindowsCE, PalmOS e Symbian OS. (PEREIRA,
2005).
O SuperWaba é uma plataforma que possui uma implementação própria de linguagem,
máquina virtual, formato de arquivos de classe, um conjunto de classes e, além disso, em seu
desenvolvimento pode ser usado ferramentas (IDE´s) Java. (PEREIRA, 2005).
2.8.2 Visual Studio
O Visual Studio (VS) é uma ferramenta de desenvolvimento que engloba várias linguagens
para atingir o máximo de desenvolvedores possíveis, destinada à plataforma .NET da Microsoft.
Dentre outras, o Visual C# (C Sharp) e o Visual Basic são as duas linguagens mais usadas.
O Visual Studio oferece poderosa ferramentas de design, construção, testes e instalação de
Web Services e aplicações windows. No contexto da computação móvel, os desenvolvedores
poderão criar aplicações móveis baseadas em browser para dispositivos móveis. (MICROSOFT,
2003).
Na versão 2003 do VS.NET vem integrado uma plataforma de desenvolvimento destinada a
dispositivos móveis, chamada .NET Compact Framework (CF). Utilizando o Windows Forms
Designer, Visual Basic e C# os desenvolvedores poderão construir, depurar e instalar aplicações
para Pocket PC, Pocket PC Phone Edition e outros Smart Device (dispositivos inteligentes) que
executam no .NET Compact Framework. Graças à emulação integrada, o desenvolvimento e a
depuração poderão ser feitas sem a necessidade de um dispositivo. (MICROSOFT, 2003). Segundo
Haddad (2004), o .NET já suporta mais de 200 dispositivos de diferentes fabricantes.
Haddad (2004) diz ainda que quando o foco no Visual Studio .NET 2003 for os telefones
celulares, o desenvolvedor deverá instalar um emulador que pode ser conseguido em qualquer site
dos fabricantes de celulares. No Visual Studio, para estes aparelhos, a aplicação a ser criada é do
tipo ASP.NET Mobile Application. Os controles utilizados são semelhantes com os de uma página
ASP.NET, no entanto, mais limitados. O tipo de aplicação, para Pocktes PC, é Smart Device
Application.
38
2.8.3 NETBEANS
Há várias tecnologias de software disponíveis no mercado para desenvolvimento de códigos
Java, como o JBuilder, Eclipse e Netbeans. Para este projeto foi utilizado o Netbeans IDE
(Integrated Development Enviroment – Ambiente de Desenvolvimento Integrado) 6.1 para todo o
desenvolvimento do código fonte.
O NetBeans IDE é um ambiente de desenvolvimento - uma ferramenta pra
programadores, que permite a você escrever, compilar, debugar e instalar programas. A IDE
é completamente escrita em Java, mas pode suportar qualquer linguagem de programação.
Existem também um grande número de módulos para extender a IDE NetBeans. O NetBeans
IDE é um produto livre, sem restrições de como ele pode ser usado. (NETBEANS, 2002).
Para desenvolver aplicações para dispositivos móveis em versões inferiores ao Netbeans 6.0,
é utilizado um plug-in que é acoplado a IDE destinado a esse fim, chamado Mobility Pack. O
Mobility Pack é um pacote que fornece suporte ao desenvolvimento visual destinado a ambientes
móveis. A partir da versão 6.0 do Netbeans, o Mobility Pack vem incorporado na própria IDE, não
sendo necessário realizar separadamente o download da IDE e o download do pacote para
desenvolvimento móvel. A Figura 8 ilustra um projeto sendo criado utilizando a programação visual
fornecida pelo Netbeans 6.1.
Figura 8 – Netbeans Mobility Pack 6.1.
Para simular um dispositivo móvel, a Sun disponibiliza uma ferramenta destinada a esse fim
(emulador), chamada Wireless Toolkit (WTK). Porém, o aplicativo será instalado em um celular do
fabricante Nokia. Então, o emulador para testes usado será o oferecido pela própria fabricante,
disponível no site http://www.forum.nokia.com. Além disso, dependendo do emulador (ou
39
dispositivo) a ser testado o aplicativo, há a possibilidade de pequenas variações na interface gráfica
caso a mesma aplicação seja instalada em outros aparelhos (ou testada em outros emuladores).
2.8.4 WAP
Com a total consolidação da internet e com o advento da terceira geração de telefonia móvel,
novos serviços (como acesso a internet móvel, além de outros) foram sendo oferecidos pelas
operadoras de telefonia móvel além dos mais básicos (voz e mensagens SMS), atraindo com isso
novos perfis de usuário, seja ela pessoa física ou corporativa.
Depois de pesquisas distintas para a consolidação da internet móvel, as empresas Nokia,
Ericsson, Motorola e Phone.com uniram-se e, com isso, fundaram em junho de 1997 a WAPForum.
Segundo Araújo (2001), a WAPForum dedica-se a habilitar telefonia e serviços de informações a
dispositivos portáteis. E, além disso, ela não desenvolve produtos, sendo responsável simplesmente
pela criação de padrões de licenças livres, para que toda indústria possa desenvolver seus produtos.
Como resultado dessa junção, surgiu um novo protocolo para internet móvel, chamado WAP
(Wireless Application Protocol, protocolo de aplicação sem fio). Araújo (2001) diz que a
WAPForum consolidou-se em cima desse protocolo como um órgão independente, com a finalidade
de desenvolver seu conteúdo e padronizá-lo.
De acordo com Oliveira (2000), trata-se de uma série de especificações para desenvolver
aplicações WEB para ambiente de rede móvel. O WAP permite que aparelhos portáteis acessem a
internet através de um microbrowser ou micronavegador (navegador padrão para dispositivos
móveis), especificando a estrutura e os protocolos de rede para tais dispositivos.
O usuário do terminal móvel acessa através de um microbrowser todo o conteúdo
armazenado no servidor. A WML (Wireless Markup Language) é a linguagem responsável por criar
esse conteúdo. De acordo com Oliveira (2000), a WML é semelhante à HTML que é usada na
criação de sites da WEB. Mas, ao contrário da HTML, a WML foi criada para atender às
necessidades dos dispositivos e redes Wireless.
Em WML, os desenvolvedores criam cards. Um baralho tem um URL como uma página
Web e contém uma ou mais cartas. Cada carta representa uma pequena tela de informação, como
um menu ou uma tela de entrada de dados. (LEE, SCHNEIDER, SCHELL, 2005).
40
Porém, como o protocolo de acesso à internet de aparelhos móveis difere do padrão usado
na internet convencional, a conversão entre protocolos é necessária para o acesso às informações. O
responsável por essa tarefa é o Gateway WAP, realizando a conversão dos protocolos WAP para
protocolos Internet (HTTP/TCP/IP) e vice-versa. Oliveira (2004) diz que o gateway pega uma
página WML que foi requisitada e o compila para um bytecode da página WML. Os dados
compilados são enviados ao telefone, e é isto que o telefone WAP realmente recebe.
No WAP, o cliente móvel também é conhecido como User Agent (UA). “O termo user agent
é utilizado para indicar a parte do dispositivo WAP que representa a comunicação do usuário com a
rede”. (BERNAL FILHO, 2004). Foi desenvolvido como complemento para aplicações WAP o
Wireless Telephony Application (WTA). Oliveira (2000) descreve que:
O WTA é uma aplicação para serviços de telefonia. O usuário-agente WTA é uma
extensão ao usuário-agente de WML padrão com a adição de capacidades para conectar com
serviços de redes móveis disponível para um dispositivo de telefonia móvel.
Para acrescentar recursos dinâmicos às aplicações WML, usa-se a linguagem WMLScript,
uma linguagem semelhante a JavaScript. Tanto WML como WMLScript são adaptadas e
otimizadas para o ambiente Wireless. (OLIVEIRA, 2000).
Para adequar-se às características das redes sem fio, o WAP teve que implementar uma pilha
de protocolos. “A pilha de protocolos isola a aplicação das operadoras. Isso torna possível que as
aplicações sejam executadas, qualquer que seja o serviço de transporte usado” (OLIVEIRA, 2000).
2.8.5 BREW
BREW (Binary Runtime Environment for Wireless) é uma plataforma voltada para o
desenvolvimento de aplicativos móveis criada pela QUALCOMM Internet Services (QIS), que é
uma divisão do grupo QUALCOMM Wireless & Internet (QWI) da QUALCOMM Incorporated.
Segundo a Qualcomm (2002), a empresa enfoca seus esforços e serviços de comunicação móvel de
nova geração, que combinam recursos de dados e voz para melhor atender às necessidades dos
clientes em um mundo caracterizado pela convergência entre a comunicação móvel e a internet.
A plataforma BREW é uma solução completa, abrangendo elementos técnicos e comerciais
para satisfazer as necessidades de cada um dos participantes envolvidos no ramo de aplicativos de
comunicação móvel. Segundo a Qualcomm (2002), as operadoras usam o mercado virtual do
41
BREW para adquirir aplicativos e oferecer a seus assinantes. Por sua vez, os usuários podem ter
uma prévia e adquirir programas a partir de seus próprios telefones.
As aplicações BREW são de cliente magro, sendo muitas vezes menor do que outras
plataformas ou sistemas operacionais completos. A Qualcomm (2002) diz que:
A plataforma BREW é aberta e fica diretamente sobre o software de sistema do
chip, permitindo aplicativos nativos em C/C++ rápidos e fácil integração de navegadores,
máquinas virtuais baseadas em tecnologia Java, e extensões como mecanismos de jogos em
3D, analisadores de XML e players de vídeo.
Para o desenvolvimento de aplicativos, a BREW oferece o BREW SDK® (versões 1.0, 1.1 e
2.0), que, segundo a Qualcomm (2002), fornece ferramentas de desenvolvimento e depuração
gerais, aplicativos de exemplo com seu código-fonte, materiais de referência e manuais do usuário,
bem como um emulador de telefones. Além disso, o desenvolvedor não precisa conhecer o software
de sistema do chip e nem a equipe de desenvolvimento do fabricante do dispositivo.
(QUALCOMM, 2002).
Além dos aplicativos e suporte a várias linguagens de desenvolvimento, a plataforma BREW
fornece um modelo de negócios integrado baseado nos componentes do Sistema de Entrega do
BREW (BREW Delivery System - BDS).
Com tecnologias abertas e extensíveis, o BDS é um ambiente de distribuição e cobrança de
serviços de dados de comunicação móvel, possibilitando à operadora implantar rapidamente um
negócio de aplicativos de comunicação móvel sobre o serviço de telefonia móvel que ela já oferece.
Com isso, a operadora ganha a possibilidade de terceirizar suas soluções de dados, ao mesmo tempo
que conserva o controle sobre as mesmas. (QUALCOMM, 2002).
A Qualcomm (2002) diz ainda que:
Demonstrando a flexibilidade do sistema BREW ainda mais, o BDS também suporta a
distribuição de aplicativos para dispositivos alternativos, tais como smartphones (telefones
inteligentes) e PDAs, através do aplicativo BREW Shop ("loja do BREW"), que pode ser
executado em diversos sistemas operacionais, inclusive o software Microsoft Windows
Mobile para pocket PCs, smartphones com Windows e Palm OS.
O fluxo do processo de distribuição do BREW pode ser acompanhado através da Figura 9:
42
Figura 9: Processo de distribuição do BREW. Fonte: Qualcomm (2003). As duas primeiras etapas (1a e 1b) são responsáveis pela submissão do aplicativo (padrão ou
gerenciado pela operadora) através de uma interface Web, sendo processados e armazenados no
repositório UAM (Unified Application Manager – gerenciador de aplicativos unificado). Em
seguida (etapas 2 e 3), o desenvolvedor cria planos de preços para as operadoras e, a partir de então,
as mesmas fazem o download do aplicativo e realizam testes, antes de negociar o plano de preço
com o desenvolvedor. O UAM se encarrega de armazenar o plano de preços do aplicativo do
desenvolvedor.
A etapa 4 contém o catálogo de aplicativos gerenciados pela a operadora. A operadora é
responsável pela organização das categorias e dos aplicativos compostos por cada uma delas, bem
como o controle de todos os preços de venda a varejo expostos a seus assinantes. A exceção está no
preço do aplicativo do desenvolvedor, na qual a operadora não pode alterá-lo.
Com o catálogo dos aplicativos concluído, a operadora define uma data e hora para ativar o
catálogo em um componente responsável pela a hospedagem, chamado ADS (Application
Download Server – Servidores de Download de Aplicativos).
Nas etapas 6 e 7, após a ativação do catálogo no ADS, o usuário pode fazer o acesso através
do cliente BREW. Caso o usuário decida fazer o download do aplicativo, é exibido a ele um pedido
de confirmação com a indicação do preço do serviço. Confirmado o download, os arquivos são
transferidos do ADS para o dispositivo pelo ar.
43
Nas últimas duas etapas, o TXN (Transaction Manager – gerenciador de transações)
processa os eventos de telefone coletados pelos ADSs e converte cada registro em um registro de
uso mediado, contendo informações como o identificador do assinante, nome do desenvolvedor e
preço de varejo. Tais registros mediados são freqüentemente exportados para as operadoras e
usados também pelo serviço de cobrança do BREW.
2.8.6 Symbian
Em 1991 a empresa Psion lançou no mercado a primeira versão do sistema operacional
EPOC para handhelds. O Psion Series 5 foi lançado em 1997, sendo o primeiro handheld a utilizar
o sistema operacional EPOC32 (32 bits). Com sede em Londres, em 1998 foi fundada a companhia
Symbian, realizado através de um consórcio pela Motorola1, Nokia, Ericsson e Psion.
O objetivo era desenvolver uma versão do EPOC32 específica para aparelhos celulares,
intitulado Symbian OS. O aparelho-alvo desse sistema operacional são os smartphones (aparelhos
centrados em voz, com capacidade para dados) e communicators (aparelhos centrados em dados,
com capacidade para voz). (PEIXOTO, IIDA, 2005a).
No ano de 2000 foi lançado o primeiro smartphone com o sistema operacional Symbian OS,
o Ericsson R380. No ano seguinte o primeiro communicator foi lançado, o Nokia 9210. A figura 10
e 11 ilustra os primeiros aparelhos com o sistema operacional Symbian OS lançados.
Figura 10 - Ericsson R380. Figura 11 - Nokia 9210. Fonte: ERICSSON (2001). Fonte: NOKIA (2001).
44
Peixoto e Iida (2005a) dizem que:
Muitas outras companhias possuem licença para fabricar aparelhos com esse sistema
operacional, já que a empresa não cobra uma alta taxa de licença de desenvolvimento para a
produção de um determinado aparelho. Ao invés disso, é cobrado uma taxa por unidade
produzida, permitindo à empresas menores de lançarem seus produtos com competitividade
com relação a companhias maiores.
O Symbian OS atende os requisitos dos aparelhos das gerações 2.5 e 3 de celulares. “Ele é
composto por um kernel multi-tarefa, suporte integrado à telefonia, protocolos de comunicação,
gerenciamento de dados, suporte a gráficos avançado, interface com o usuário de baixo nível e uma
variedade de algoritmos para aplicações”. (PEIXOTO, IIDA, 2005b).
Além do OPL (Open Programming Language), com o Symbian OS podem ser
desenvolvidos softwares usando Symbian C++ (linguagem nativa) e Java (JME MIDP 1.0 e MIDP
2.0 e PersonalJava 3.0 com as opções do JavaPhone 1.0). Com uma implementação modular e
flexível, o Symbian OS suporta padrões como IP v4 e v6, bluetooth, Java, WAP e SyncML (um
padrão para troca de dados entre computadores móveis e PC’s). (TRINDADE, 2004).
2.8.7 Java Micro Edition (JME)
A tecnologia Java é composta por três edições: JSE (Java Standard Edition), voltada para
aplicações desktop; JEE (Java Enterprise Edition), destinada à aplicações Web; e a JME (Java
Micro Edition), voltada à aplicações para dispositivos móveis. A Figura 12 mostra as diferentes
edições de Java.
Figura 12 – Edições de Java.
Fonte: Adaptado de Muchow (2004, p 2).
45
JME são classes e API´s voltadas exclusivamente ao desenvolvimento de aplicações para
dispositivos com poder limitado (celulares, PDAs), como memória, velocidade de processamento e
tamanho da tela (display). Tais dispositivos eram configurados durante o processo de fabricação por
seus fabricantes, oferecendo um conjunto fixo de funcionalidades e, com isso, impossibilitando ao
usuário downloads de novos aplicativos ou a opção de navegar na internet. “Com a introdução do
JME, os dispositivos ‘micros’ não precisam mais ter natureza ‘estática’. Exatamente como um
navegador Web fazendo download de applets Java, uma implementação de JME em um dispositivo
permite a opção de navegar, fazer download e instalar aplicativos Java e conteúdo” (MUCHOW,
2004).
“Em um mundo ideal, um dispositivo móvel executaria a mesma JVM que o JSE e teria
acesso às suas bibliotecas básicas inteiras, tudo em pouco mais de um megabyte” (MUCHOW,
2004). Mas, devido às limitações presentes nesses aparelhos, isso não é possível. “A ‘Micro
Edition’ foi introduzida para tratar das necessidades especiais dos dispositivos para o consumidor
que estão fora da abrangência do JSE e do JEE” (MUCHOW, 2004).
No entanto, os recursos dos dispositivos podem sofrer bastantes variações. “Mesmo
dispositivos que parecem semelhantes em tamanho podem variar muito em seus recursos. Um
telefone celular ou PDA tem um tamanho físico limitado, apesar de um telefone celular poder ter
uma tela com resolução total de 12.288 pixels (96 x 128), enquanto a resolução de um PDA pode
começar em 20.000 pixels e daí para cima” (MUCHOW, 2004). Devido a isso, foi introduzido o
conceito de Configuração e Perfil.
Atualmente existem dispositivos com diferentes capacidades e poder de processamento.
Apesar da limitação de todos eles, há aqueles que oferecem um poder maior ou mais limitado de
processamento. Uma TV digital, por exemplo, pode ser adaptada sem maiores problemas para
armazenar uma grande quantidade de memória ou capacidade de armazenamento de dados. Em
contrapartida, telefones celulares ou pagers, por suas dimensões restritas, são impossibilitados de
oferecerem grande capacidade de memória ou armazenamento quando comparadas a outros
aparelhos, como uma TV digital. A Sun (empresa criadora do Java) introduziu o conceito de
configuração para suprir essas diferenças entre dispositivos.
“Uma Configuração define uma plataforma Java para uma ampla variedade de dispositivos.
Ela está intimamente vinculada a uma máquina virtual Java (JVM, Java Virtual Machine)”
(MUCHOW, 2004).
46
A JME foi divida em 2 tipos diferentes de configuração: CDC (Connected Device
Configuration, Configuração de Dispositivos Conectado) e CLDC (Connected Limited Device
Configuration, Configuração de Dispositivo Conectado Limitado).
A CDC abrange aparelhos com maiores capacidades de armazenamento ou memória, como:
TV digital, forno micro-ondas, geladeiras, dentre outros. Suas características são:
• 512 kilobytes (no mínimo) de memória para executar o Java.
• 256 kilobytes (no mínimo) de memória para alocação de memória em tempo de execução.
• Conectividade de rede, largura de banda possivelmente persistente e alta.
A CLDC abrange dispositivos com recursos restritos de memória, velocidade de processamento
ou armazenamento de dados, como: telefones celulares, pagers e PDAs. “O primeiro objetivo da
CLDC é definir uma especificação para uma JVM, e o segundo é definir um conjunto de classes
(bibliotecas) Java. Cada objetivo tem um tema em comum: suportar uma ampla variedade de
dispositivos com memória, capacidade de vídeo e recursos limitados” (MUCHOW, 2004).
Por trás de todo aplicativo Java, está a JVM (Java Virtual Machine, Máquina Virtual Java). A
JVM é um programa que carrega e executa os aplicativos Java, transformando os arquivos de classe
(bytecode, código de byte) no código de máquina para a plataforma que está executando a JVM. E é
esse programa que garante a portabilidade de aplicativos Java.
Para a CLDC, a Sun desenvolveu uma nova implementação da JVM capaz de atender
aplicações destinadas a aparelhos com poder limitado, chamado K Virtual Machine (Máquina
Virtual K). “A KVM foi projetada para ser a menor e a mais eficiente possível, e ainda permanecer
rápida para as necessidades da linguagem Java” (MUCHOW, 2004). Dentre todos esses conceitos,
algumas características da CLDC são:
• 128 kilobytes de memória para executar o Java.
• 32 kilobytes para alocação de memória em tempo de execução.
• Interface restrita com o usuário.
• Baixo poder, normalmente alimentado por bateria.
• Conectividade de rede, normalmente dispositivos sem fio com largura de banda baixa e
acesso intermitente.
Apesar de determinados dispositivos se encaixarem perfeitamente nas limitações da CLDC, os
mesmos diferem entre si. PDAs, por exemplo, apresentam um tamanho maior da tela quando
comparadas a telefones celulares. JavaCards, por sua vez, não apresentam um display para a
interação com o usuário. É justamente nesse ponto que entra o conceito de perfil.
47
“Um perfil é uma extensão de uma configuração. Ele fornece as bibliotecas para um
desenvolvedor escrever aplicativos para um tipo em particular de dispositivo. Por exemplo, o MIDP
(Mobile Information Device Profile, perfil de dispositivo de informação móvel) define APIs para
componentes, entrada e tratamento de eventos de interface com o usuário, armazenamento
persistente, interligação em rede e cronômetros, levando em consideração as limitações de tela e
memória dos dispositivos móveis” (MUCHOW, 2004).
Atualmente, o MIDP se encontra na sua terceira versão, MIDP 2.1, tendo sido a versão 1.0 a
introdutória. Ele se encaixa dentro das configurações do CLDC. Para o CDC, há outros perfis
definidos, como:
• Foundation Profile (FP): fornece uma implementação de rede sem interface com o
usuário.
• Personal Profile (PP): utilizado em dispositivos que necessitam de suporte para interfaces
ou applets.
• Personal Basis Profiles (PBP): fornece um ambiente para dispositivos que suportem um
nível básico de apresentação gráfica.
A Figura 13 apresenta a arquitetura de uma configuração MID.
Figura 13 – Arquitetura do perfil MID.
Fonte: Muchow (2004, p 7) – Adaptado por Elias de O. Costa.
2.8.7.1 Desenvolvimento JME com Multimídia e GPS
Assim como existe agregado a navegadores de internet pequenos aplicativos Java chamados
applets, existe a midlet (nome dado a aplicativos J2ME) agregado a dispositivos móveis, construído
com a classe MIDlet. Muchow (2004) diz que é através dos métodos dessa classe que o Gerenciador
de Aplicativos (software implementado pelo fabricante do dispositivo) realiza a comunicação com a
aplicação (midlet) desenvolvida.
48
Geralmente, a distribuição de uma aplicação JME consiste em muitos arquivos (como
imagens), além das classes Java. Todos esses arquivos e classes são empacotados em um arquivo
JAR (Java Archive). O arquivo JAR, além dos próprios conjuntos de classes e arquivos, contém um
outro arquivo, chamado manifesto. Esse arquivo, que tem o nome de manifest.mf, descreve o
conteúdo de um JAR.
Além disso, outro arquivo importante faz parte de aplicações JME, chamado JAD (Java
Application Descriptor). Segundo Muchow (2004), um arquivo JAD fornece informações para o
gerenciador de aplicativos sobre o conteúdo de um arquivo JAR. Com essas informações, o
gerenciador de aplicativos poderá posteriormente tomar decisões, como, por exemplo, quais ou
quantas MIDlets poderão ser executas no dispositivo.
No seu ciclo de vida, uma MIDlet passa por muitas fases, estando ela sempre em um dos três
estados a seguir:
• Pausa: a MIDlet entra nesse estado quando o construtor da classe é chamado, mas antes de
ser iniciada. Depois de iniciada, a MIDlet pode alternar muitas vezes entra os estados de
pausa e ativa.
• Ativa: quando a MIDlet está em execução.
• Destruída: a MIDlet libera seus recursos para, logo em seguida, o gerenciador de
aplicativos destruí-la.
Cada MIDlet faz referência a um objeto da classe Display. Esse objeto faz o controle de tudo
aquilo mostrado no visor de um dispositivo móvel. Além de um objeto Display poder recuperar
informações sobre a tela atual (por exemplo, quantidade de cores suportadas), ele oferece
métodos para que um determinado objeto (Form, TextField etc.) seja mostrado na tela. E todos
esses objetos que podem ser mostrados na tela se tornam um objeto da classe Displayable.
Existem duas subclasses de Displayable incluídas pelo MIDP: Screen e Canvas. A Figura 14
mostra toda a hierarquia de classes do perfil MIDP.
A JME fornece vários pacotes opcionais para diversos propósitos, como comunicação via
Bluetooth e envio/recebimento de informações via WebServices. Cada fabricante de celular
implementa determinados pacotes de acordo com o modelo do dispositivo. Para recursos
multimídia, existe o pacote chamado MMAPI (Mobile Media API). Atualmente ela se encontra
na versão 1.1. “Trata-se de um pacote opcional que dá suporte a recursos multimídia, tais como
reprodução, edição e captura de áudio e vídeo de diversas origens (sources)” (GALL, 2006).
49
Figura 14 – Hierarquia de classes de MIDP. Fonte: Muchow (2004).
Segundo Gall (2006), o processo de funcionamento consiste em duas partes:
• Protocol handling: faz a captura da mídia, seja ela de um arquivo local, streaming ou
câmera e microfone, por exemplo.
• Content handling: decodifica e renderiza os dados recebidos para, posteriormente, enviar
para os dispositivos de saída.
A JSR 135 (Java Specification Request 135), que define a MMAPI, utiliza dois objetos de
alto nível: DataSource e Player. Gall (2006) diz que o DataSource recebe a mídia e faz um
processo de controle do protocolo e Player, além de controlar o conteúdo fornecido por DataSource,
processa e envia para o dispositivo de saída.
Além destes objetos, existe o Manager, que cria uma instância de Player. “Após criado, o
Player fornece à interface Control os controles necessários para manipular a mídia de áudio ou
vídeo, possibilitando alternar os estados do ciclo de vida do Player” (GALL, 2006). A Figura 15
mostra a ordem desses objetos.
50
Figura 15: Processo de funcionamento da MMAPI. Fonte: Gall (2006, p 55).
O ciclo de vida de um Player, conforme ilustra a Figura 16, é divido em cinco estados:
• Unrealized: primeiro estado a ser processado após o Player ser construído;
• Realized: estabelece comunicação entre os recursos de mídia e o Player;
• Prefetched: reduz o tempo de carregamento para a reprodução da mídia;
• Started: mídia em execução;
• Closed: libera recursos da mídia.
Figura 16 – Ciclo de vida de um Player.
Fonte: Gall (2006, p 56).
A MMAPI é um poderoso recurso voltado para desenvolvimento multimídia.
Funcionalidades como fotografar, gravar e reproduzir áudio e vídeo é oferecida por essa API.
Agregado ao WTK (Wireless Tolkit – ambiente de desenvolvimento com emuladores para
desenvolvimento JME) existe o JavaDOC (documentação JAVA) da MMAPI, para melhor
aprofundamento no estudo de suas classes e métodos.
51
Para a captura de coordenadas GPS a JME fornece um pacote opcional especificado pela
JSR 179, chamado de Location API. A plataforma mínima para o uso da JSR 179 é a CLDC 1.1,
pois a API requer números de pontos flutuantes. Através da API, o desenvolvedor poderá coletar
dados de posicionamento global, como latitude, longitude, altitude, dentre outros.
Todas as classes para uso da Location API estão contidas no pacote
javax.microedition.location. De acordo com o FORUM NOKIA (2006), a API inicia-se com a
classe LocationProvider, no qual representa o módulo que fornece a localização. Uma instância
dessa classe pode ser criado através do método LocationProvider.getInstance(Criteria criteria). O
objeto criteria define alguns parâmetros importantes. Por exemplo, o método
setSpeedAndCourseRequired(boolean b) define se serão recuperadas informações de velocidade e
curso. Já o método setAltitudeRequired(boolean b) define se serão capturadas dados de altitudes.
Com o objeto LocationProvider criado, pode-se agora criar um objeto da classe Location
para recuperar a posição geográfica do usuário, através do método getLocation(int i). No método
getLocation(int i) é passado como parâmetro um número inteiro que representa o tempo máximo de
espera para a recuperação das coordenadas. Em seguida, é preciso instanciar um objeto da classe
QualifiedCoordinates através do método getQualifiedCoordinates() através de um objeto Location.
Finalmente, com o objeto da classe QualifiedCoordinates criado, pode-se usar os métodos
getLatitude() e getLongitude() para obter as coordenadas geográficas.
2.8.7.2 Segurança de aplicações JME
Com a finalidade de evitar o uso inadequado de aplicações maliciosas, o perfil MIDP 2.0
estabelece um modelo de segurança de acesso a algumas APIs. Esse modelo permite que MIDlets
acessem APIs que são consideradas sensíveis. Por exemplo, realizar uma conexão utilizando o
protocolo HTTP pode ter algum custo para o usuário. Nesse sentido, o perfil MIDP 2.0 inclui o
conceito de trusted (confiável) e untrusted (não confiável) MIDlets.
Untrusted MIDlets possuem acesso restrito a determinadas APIs. Dessa forma, é necessária
uma confirmação do usuário para permitir o acesso do aplicativo a qualquer API que é protegida.
Por outro lado, trusted MIDlets podem adquirir algumas permissões automaticamente dependendo
da política de segurança do aparelho. Porém, a aplicação precisa ser assinada com algum certificado
disponível no dispositivo móvel. No endereço http://www.forum.nokia.com, existem alguns
documentos para downloads que explicam como assinar uma aplicação Java para celular. No
52
endereço http://www.forum.nokia.com/document/Java_ME_Developers_Library_v1/, além de
outros assuntos, também está disponível um documento para o mesmo propósito.
2.9 DISCUSSÃO
As gerações de rede celular, juntamente com as operadoras de telefonia móvel e empresas
criadoras de aparelhos móveis estão buscando, cada vez mais, melhores formas de serviços para o
usuário final, como cobertura geográfica mais ampla, aumento da velocidade do tráfego de dados,
acesso à internet móvel com um preço mais acessível e aumento dos recursos dos dispositivos. Na
medida em que essa evolução progride, a demanda por programas melhores arquitetados cresce,
obrigando as empresas desenvolvedoras de softwares a fornecerem mais recursos tecnológicos para
o desenvolvimento de aplicações móveis.
Consolidada já no mercado, a tecnologia JME da SUN oferece ótimas oportunidades de
negócio, tanto para as operadoras de telefonia móvel como para os desenvolvedores. Recursos
como segurança, orientação à objetos e boa documentação de suas classes e métodos para uma
adaptação mais fácil, fazem da tecnologia Java ME muito procurada entre os desenvolvedores.
Nesse contexto, será desenvolvido um protótipo de aplicação multimídia para celular,
utilizando os recursos oferecidos por essa tecnologia, atendendo com isso às restrições dos
aparelhos móveis.
53
3 DESENVOLVIMENTO
Este capítulo descreve as etapas relacionadas ao desenvolvimento do projeto. Além de uma
breve descrição da aplicação, é apresentada a arquitetura do sistema. Em seguida são descritos
aspectos pertinentes à análise e modelagem, implementação e testes. Concluindo, os resultados
alcançados são apresentados.
3.1 VISÃO GERAL
O foco do projeto é o desenvolvimento de uma aplicação para telefone celular para a captura
de imagem, vídeo, áudio e coordenadas GPS com o objetivo de arquivar digitalmente a experiência
pessoal de um indivíduo, como tudo que ele vê e escuta ao longo do dia. Periodicamente são
capturadas imagens e vídeos com a câmera embutida no aparelho. A aplicação também realiza a
gravação de arquivos de áudio para capturar o som ambiente que o usuário ouve. Além disso, o
sistema coleta coordenadas através do receptor GPS embutido no dispositivo celular, indicando por
onde a pessoa esteve. Todas essas informações são armazenadas utilizando o próprio sistema de
arquivo do celular, através do pacote opcional do JME destinado a esse fim, a FileConnection API.
Uma vez que diferentes telefones celulares diferem em muitos aspectos, como aspectos específicos
de implementação e dessa maneira dificultando sua portabilidade, este trabalho focou seu
desenvolvimento sobre o aparelho celular modelo Nokia N95. As especificações técnicas desse
modelo podem ser verificadas no Anexo I.
O sistema, chamado de MobileLife, também é flexível o bastante para se adaptar de acordo
com as necessidades do usuário. Com isso, o usuário pode criar categorias para todos os arquivos
que são armazenados no celular. A forma como são gravadas as mídias depende exclusivamente de
como está configurada a categoria selecionada no momento do início da gravação da experiência
pessoal do usuário.
O usuário ainda poderá gerenciar suas experiências pessoais, como por exemplo, excluir
arquivos gravados ou visualizá-los e, se desejar, enviar tais arquivos para um servidor web. O
celular poderá ser usado ao redor do pescoço simulando a câmera SenseCam desenvolvida por
pesquisadores da Microsoft para o projeto MyLifeBits.
54
3.2 ARQUITETURA DO SISTEMA
Esta seção tem como objetivo apresentar a arquitetura lógica dos componentes envolvidos
no desenvolvimento do sistema. Na Figura 17, pode-se observar a arquitetura do perfil MIDP, assim
como onde a aplicação MobileLife é executada.
Figura 17: Arquitetura MIDP. Fonte: Adaptada de Gall (2004). A seguir uma breve descrição de cada componente apresentado na Figura 17: • MID (Mobile Information Devices): Dispositivos MID definidos pela especificação
JME.
• Sistema Nativo: Sistema operacional do dispositivo.
• CLDC (Connected Limited Device Configuration): Configuração JME, que é onde está a
máquina virtual KVM.
• MIDP (Mobile Information Device Profile): Perfil JME.
• Classes Específicas OEM (Original Equipament Manufacturer): Classes não englobadas
pelo perfil MIDP que fornecem funcionalidades específicas para determinados
aparelhos.
55
• Aplicações Específicas OEM: aplicações fornecidas pelo fabricante do aparelho que
utilizam classes OEM.
• Aplicações Nativas: Aplicações implementadas diretamente no sistema do aparelho e
não são codificadas em Java.
• Aplicações MIDP: Aplicações JME que usam API´s fornecidas pelo perfil MIDP e
configuração CLDC, como o MobileLife.
Através da Figura 18, pode-se observar a organização dos componentes e seus
relacionamentos envolvidos no projeto.
Figura 18 – Arquitetura do Sistema.
Todo o desenvolvimento do projeto foi organizado em pacotes. O pacote view contém a
classe responsável pela criação dos componentes da interface gráfica. No pacote business, está
contido todas as classes responsáveis pela regra de negócio da aplicação. O pacote persistence
contém as classes que são responsáveis por abrir uma conexão com o sistema de arquivos do celular
e RMS para a persistência dos dados. No pacote útil, está contida a classe que fornece métodos
static utilitários para a aplicação como um todo, como por exemplo, métodos que retornam data e
hora, entre outros. O pacote connection contém a classe responsável por estabelecer uma conexão
HTTP com um servidor web para enviar os arquivos armazenados no celular.
3.3 MODELAGEM DO SISTEMA
A modelagem do sistema foi realizada baseada no padrão UML (Unified Modeling
Language). Segundo Booch, Rumbaugh e Jacobson (2006), a UML é uma linguagem padrão para a
56
elaboração da estrutura de projetos de software. É uma linguagem muito expressiva, abrangendo
todas as visões necessárias ao desenvolvimento e implantação de sistemas. Toda a modelagem do
sistema foi realizada utilizando a própria IDE Netbeans 6.1, que por sua vez oferece a opção para
criar um projeto UML.
Nesta seção é apresentada parte da descrição dos diagramas, sendo também apresentado
funcionalidades de maior importância para o sistema.
3.3.1 Análise de Requisitos
O levantamento dos requisitos é de extrema importância para o desenvolvimento de um
sistema. Com isso, o desenvolvedor previamente tem conhecimento das funcionalidades que o
sistema deverá oferecer. Nesta seção são mostrados os requisitos funcionais e não funcionais e
regras de negócio da aplicação.
3.3.1.1 Requisitos Funcionais
Os requisitos funcionais do sistema são:
• RF01: O sistema deve permitir ao usuário o gerenciamento (criação, edição e remoção)
de categorias para armazenar os arquivos;
• RF02: Ao iniciar uma gravação, o sistema deve permitir ao usuário escolher qual
categoria uma gravação multimídia estará associada.
• RF03: O sistema deve permitir a seleção das mídias a serem gravadas, a periodicidade de
gravação para cada mídia e, caso escolha gravar imagens ou vídeos, poderá também
escolher qual das duas câmeras embutidas no celular será utilizada;
• RF04: Caso o usuário configure a categoria para gravar vídeo e/ou áudio, o sistema deve
permitir a definição do tempo total em segundos de cada gravação;
• RF05: O sistema deve permitir ao usuário a remoção e visualização dos arquivos
armazenados;
• RF6: O sistema deve permitir ao usuário o envio dos arquivos armazenados via conexão
HTTP para um servidor web;
• RF07: O sistema deve permitir ao usuário a execução da aplicação em background.
57
• RF08: O sistema deve permitir ao usuário coletar coordenadas GPS (latitude e longitude)
através do receptor embutido no próprio aparelho.
3.3.1.2 Requisitos Não Funcionais
Os requisitos não funcionais são:
• RNF01: O sistema deve ser desenvolvido utilizando a tecnologia JME;
• RNF02: O sistema deve ser instalado em celulares com o perfil MIDP 2.0 e configuração
CLDC 1.1;
• RNF03: O sistema deve ser instalado em celulares que dêem suporte à API de
multimídia do JME, ou seja, a JSR 135 (Mobile Media API);
• RNF04: O sistema deve ser instalado em celulares que dêem suporte a API para
manipulação de arquivos, ou seja, a JSR 75 (PDA Optional Packages for the J2ME
Platform);
• RNF05: O sistema deve ser instalado em celulares que dêem suporte a API de
localização via satélite, ou seja, a JSR 179 (Location API);
• RFN06: O sistema deve ser instalado em celulares que tenham um receptor GPS
integrado ao seu hardware;
• RNF07: As imagens capturadas devem ser salvas no formato PNG;
• RNF08: Os áudios capturados devem ser salvos no formato WAV;
• RNF09: Os vídeos capturados devem ser salvos no formato 3GPP.
3.3.1.3 Regras de Negócio
• RN01: Somente poderão ser excluídas categorias que não tenham nenhuma mídia
relacionada a mesma;
• RN02: Áudio e vídeo não poderão ser selecionados ao mesmo tempo.
58
3.3.2 Diagrama de casos de uso
Segundo Booch, Rumbaugh e Jacobson (2006), os diagramas de casos de uso são
importantes para visualizar, especificar e documentar o comportamento de um elemento. Dessa
forma, sistemas, subsistemas e classes ficam acessíveis e compreensíveis por apresentarem uma
visão externa sobre como esses elementos podem ser utilizados no contexto.
Os casos de uso pertencentes ao sistema são apresentados na Figura 19. As setas tracejadas
no diagrama representam relacionamento de dependência entre os casos de uso.
Figura 19 – Diagrama de casos de uso do sistema.
No Apêndices A1, é descrito o fluxo de eventos de cada caso de uso apresentado na Figura
19.
3.3.3 Diagrama de Classe
Os diagramas de classe mostram os relacionamentos das classes contidas no sistema. De
acordo com Booch, Rumbaugh e Jacobson (2006), os diagramas de classes são importantes não só
para a visualização, a especificação e a documentação de modelos estruturais, mas também para a
59
construção de sistemas executáveis por intermédio de engenharia de produção. A Figura 20 ilustra o
diagrama de classe5 do sistema.
Figura 20 – Diagrama de classe do sistema.
A classe MobileLife é a principal do sistema. Esta classe é responsável por toda a criação
dos objetos de interface gráfica. Ela herda de MIDlet e implementa a interface CommandListener.
Portanto, a classe MobileLife é responsável pelo tratamento das ações geradas pelo sistema e pelo
ciclo de vida da midlet.
Não menos importante, a classe Scheduler realiza todo o processo de escalonamento entre as
mídias. Nesta, processos distintos são criados para cada tipo de mídia. A instância de cada objeto é
obtido através da classe MediaFactory, que por sua vez contém um método static que retorna um
5 Para uma melhor visualização do relacionamento das classes do sistema, foram omitidos os atributos e os métodos. No APÊNDICE A2, podem ser visualizados as classes com seus respectivos atributos e métodos.
60
AbstractMidia. A classe ReturnBeans é um singleton que apenas serve para obter uma instância de
um objeto bean.
As classes ImageBean, GpsBean, AudioBean e VideoBean são as entidades pertencentes ao
sistema. Ou seja, cada uma destas possui set´s e get´s para seus atributos. As classes CategoryPrst,
MediaPrst e ExperiencePrst são responsáveis pelo armazenamento das informações. A classe
CategoriaPrst contém métodos para manipulação de uma categoria, como salvar, excluir e verificar
se existe determinada categoria. A classe MediaPrst contém apenas dois métodos. O mais
importante é responsável pela persistência de cada mídia capturada. A classe ExperiencePrst
contém métodos para manipulação de uma mídia salva, como: excluir uma mídia e para retornar
todas as mídias de uma categoria.
As classes GPS, Video, Image e Audio herdam de AbstractMedia os métodos para o
processamento das mídias, como: iniciar a captura de uma mídia; parar a captura de uma mídia; e
salvar uma mídia.
3.3.4 Diagrama de Seqüência
De acordo com Booch, Rumbaugh e Jacobson (2006), os diagramas de seqüência têm como
finalidade realizar a modelagem de forma dinâmica do sistema. A Figura 21 e a Figura 22 mostram
todo o fluxo para adicionar uma nova categoria. Nos diagramas apresentados a seguir, foi assumido
que no sistema já havia categorias cadastradas. Na Figura 23, pode-se visualizar o diagrama de
seqüência para o processo de iniciar uma gravação.
61
Figura 21. UC 02: Diagrama de seqüência Incluir Categoria.
Figura 22. UC 02: Diagrama de seqüência Incluir Categoria - Continuação.
62
Figura 23. UC 05: Diagrama de seqüência Iniciar Gravação.
3.4 IMPLEMENTAÇÃO
Esta seção descreve questões envolvidas na codificação do projeto implantado no celular.
Pelo suporte e pela facilidade, toda codificação foi realizada utilizando a IDE Netbeans 6.1 para o
desenvolvimento de aplicações para celulares. Através de técnicas “arrastar/soltar” de componentes
fornecidas por esta IDE, a produtividade no desenvolvimento aumenta quando comparadas a outras
IDE´s sem esta técnica disponíveis no mercado tecnológico.
Como especificado na definição de escopo, a aplicação foi instalada no celular Nokia N95.
Portanto, visando um ambiente mais próximo de um celular Nokia, foi utilizado um emulador da
própria fabricante em todo o desenvolvimento do projeto. O modelo N95 se enquadra na plataforma
S60 3rd Edition, Feature Pack 1. O software que emula essa plataforma não se mostrou fiel ao
dispositivo real para manipulação do sistema de arquivos do celular. Por esse motivo, foi utilizado
para todo o desenvolvimento um emulador da plataforma S40 5th Edition, Feature Pack 16. A
manipulação de arquivos e o acesso a recursos multimídia se mostraram fiéis ao dispositivo real.
Porém, não foi possível realizar testes para a captura de coordenadas GPS nessa plataforma, pois a
mesma não suporta o pacote utilizado para este fim, a Location API. Dessa forma, na medida em
que o desenvolvimento dos métodos da classe com essa funcionalidade prosseguia, os testes iam
sendo realizados somente no dispositivo real, sem a ajuda de emuladores. As especificações 6 Todos os emuladores Nokia podem ser encontrados no site http://www.forum.nokia.com
63
técnicas da plataforma S40 e plataforma S60 podem ser verificadas no Anexo II e Anexo III,
respectivamente.
No desenvolvimento do código foi necessário utilizar técnicas de processamento paralelo
com threads. Dessa maneira, foi possível realizar a captura de mais de uma mídia ao mesmo tempo,
como por exemplo, “tirar” uma foto e gravar um áudio. Conseqüentemente, com o uso de threads
pôde-se evitar o bloqueio das teclas do celular, permitindo ao usuário parar o processo de gravação
das mídias envolvidas.
Todos os arquivos e diretórios criados pela aplicação foram salvos no cartão de memória
microSD acoplado ao celular. Em celulares Nokia, o acesso ao cartão de memória com o
desenvolvimento JME faz-se através do diretório E/. O diretório MobileLife contém todos os
arquivos armazenados pela aplicação. Vale ressaltar que o usuário da aplicação não precisará criar
nenhum diretório manualmente. Toda a estrutura é criada pela aplicação. Em seguida é possível
visualizar as categorias criadas. Para toda categoria criada, existe um arquivo salvo no celular
contendo as informações necessárias para o processamento adequado de gravação das mídias. Para
exemplificar, o arquivo "1A|1|10;1B|30|5;1D|40*", significa que a categoria irá capturar uma
imagem (1A) usando a câmera principal do celular (1) a cada 10 segundos, um áudio (1B) de 30
segundos a cada 5 segundos, e coordenadas GPS (1D) a cada 40 segundos. O símbolo “*” serve
apenas para indicar o final do arquivo.
As pastas onde são salvas as mídias são nomeadas no formato DDMMAA (DD=Dia; MM=
Mês; AA= Ano). Já as mídias são nomeadas no formato DDMMAAHHmmssCategoria.extensão
(DiaMêsAnoHoraMinutoSegundoCategoria.ext). Um exemplo para um formato de imagem seria:
110608003225Pessoal.png. Neste caso, a aplicação capturou uma imagem no dia 11 de Junho de
2008 às 00 horas, 32 minutos e 25 segundos, para a categoria Pessoal.
Por fim, foi desenvolvida uma servlet Java para receber as mídias enviadas pelo celular. Foi
utilizado o Tomcat7 como servidor de aplicação.
7 No endereço http://tomcat.apache.org/, existe toda a documentação do Tomcat, além de ter o link para download.
64
3.5 PROTOTIPAÇÃO DE TELAS
A aplicação MobileLife inicia-se com a tela mostrada na Figura 24(a). Nela estão contidas os
itens do menu principal da aplicação. Entrando no primeiro item, Iniciar Gravação, a tela da Figura
25(b) é mostrada. Nela o usuário pode escolher a categoria que desejar. Caso não exista nenhuma
categoria criada, a tela da Figura 25(c) é mostrada no celular. Ainda nesta mesma tela há a opção
para a aplicação ser executada em background. Desta maneira, o usuário poderá realizar outras
atividades no celular enquanto a aplicação é processada.
Figura 24: Tela Iniciar Gravação.
Ao ser selecionado a opção Sim na tela da Figura 25(c), o fluxo da aplicação chama a tela
para criar uma nova categoria. Nesta tela, é preenchido o nome da categoria e as mídias envolvidas
no processo de gravação, conforme mostra a tela da Figura 26(a). Em seguida, caso o usuário tenha
escolhido imagem e/ou vídeo, é mostrada uma tela para a escolha da câmera do N95 a ser utilizada
65
(Figura 26(b)). Na próxima tela, representado pela Figura 26(c), é apresentado o formulário para
preenchimento das características das mídias e fornecimento da periodicidade de gravação.
Figura 25: Tela Nova Categoria.
Ao ser selecionado o comando Iniciar na tela da Figura 25(a) e ao ser selecionado a
categoria na tela da Figura 25(b), o processo de gravação é iniciado. Em seguida, o fluxo retorna
para a tela inicial. Porém, a primeira opção do menu, Iniciar Gravação, será alterada para Parar
Gravação.
A Figura 27 mostra as telas caso o usuário queira gerenciar suas experiências. Na Figura
27(a) pode-se observar todas as experiências organizadas por data e categoria. A tela da Figura
27(b) mostra o menu de opções. As opções visualizar e excluir apenas executa e exclui a mídia,
respectivamente. A última opção, enviar, permite ao usuário enviar o arquivo selecionado para um
servidor web.
66
Figura 26: Tela Gerenciar Experiências.
Retornando ao menu principal da aplicação (Figura 25(a)), existe a funcionalidade Gerenciar
Categorias. Ao ser escolhida esta opção, é mostrada uma tela com todas as categorias criadas pelo
usuário. No menu de opções, representado pela tela da Figura 28(a), existe as opções incluir, editar
e excluir. No comando editar, o usuário poderá alterar as configurações da categoria selecionada.
Caso o usuário queira excluir uma categoria, e se a categoria selecionada conter arquivos
relacionados a ela, a mensagem da Figura 28(b) é mostrada.
67
Figura 27: Tela Gerenciar Categorias.
3.6 TESTES E AVALIAÇÕES
O objetivo dos testes é encontrar possíveis erros que estão ocorrendo no software. Os
principais testes realizados no sistema foram:
• Testes unitários: Foram efetuados testes das unidades dos componentes de maneira
isolada. Tais testes visam verificar a integridade de pequenas partes isoladas do sistema
ou a lógica da unidade em questão.
• Testes de integração: Foram efetuados testes no funcionamento dos componentes
envolvidos no sistema como um todo e a troca de mensagens entre cada um deles.
68
• Testes de interface: Visando a usabilidade do usuário final e a verificação se as telas
correspondem ao que foi especificado, foi realizado testes de interface de todo o sistema.
O emulador usado para todo o desenvolvimento do projeto foi o S40 5th Edition, Feature
Pack 1. Como dito no item 3.5, essa plataforma não suporta a API para captura de coordenadas
GPS. Dessa forma, os testes para essa funcionalidade foram realizados no próprio dispositivo.
Apesar da plataforma usada no desenvolvimento suportar a captura de imagens, áudio e
vídeo, ao ser executada a aplicação, o emulador se comportou de forma distinta comparada ao
comportamento quando instalada no celular real.
Para captura e visualização de imagens o emulador se mostrou fiel ao telefone celular.
Porém, para ser possível o funcionamento no celular, um trecho de código precisou ser alterado.
Para captura de áudio o emulador também se comportou da forma esperada. Porém, não foi possível
reproduzir um arquivo de áudio no emulador usado. No celular, o mesmo código se comportou da
forma esperada para esta funcionalidade. Para a gravação e reprodução de vídeos, não foi possível
reproduzir no emulador, pois o mesmo lançava uma exceção. Porém, a reprodução e visualização de
vídeos no celular foram executadas sem problemas.
Para o envio dos arquivos para um servidor, foi testado apenas no emulador para imagem e
áudio. Tais testes, realizados apenas com uma aplicação servidora local ativa, funcionaram como o
esperado.
Diante dos fatos ocorridos durante o desenvolvimento, ao ocorrer algum erro ou exceção
apresentado pelo emulador, o mesmo código era testado também no celular, para desta forma ser
verificado o comportamento da aplicação no dispositivo real usado no desenvolvimento.
A avaliação do sistema foi realizada pela execução repetitiva de testes durante e após toda
implementação. Dessa maneira pode-se confirmar o favorecimento pré-estabelecidos para o sistema
dos requisitos funcionais e não funcionais e regras de negócio.
Um dos testes da aplicação foi realizado no centro da cidade de Florianópolis, estado de
Santa Catarina. Foi criada uma categoria chamada Teste. Para esta categoria foi selecionada as
mídias Imagem e GPS. A câmera principal, ou seja, a câmera com melhor qualidade do celular foi
escolhida para a captura das imagens. Para as periodicidades, foram armazenados 40 segundos para
a mídia imagem e 60 segundos para coordenadas GPS. Ou seja, a cada 40 segundos uma imagem
foi capturada e a cada 60 segundos coordenadas GPS foram capturadas. A Figura 29 mostra as
69
imagens capturadas durante o processo de gravação com seus respectivos nomes. A primeira
imagem capturada localiza-se no canto superior esquerdo e as próximas capturas são as outras duas
na mesma linha, seguindo nesse sentido até o final. Através das coordenadas GPS coletadas, a
Figura 30 mostra os pontos exatos onde foram capturadas as coordenadas GPS no trajeto percorrido
durante o teste. Foi usado a Google Maps API. De acordo com Azevedo (2008), a API consiste
basicamente de um pequeno conjunto de classes JavaScript que fornecem a interface necessária
para que o usuário possa construir aplicações para exibir mapas, realizar consultas por endereços,
acrescentar pontos de referências, dentre outras possibilidades. O trajeto foi percorrido no mesmo
sentido permitido por automóveis, sendo demonstrado no mapa pelas setas.
Figura 28: Imagens capturadas.
70
Figura 29: Trajeto percorrido.
A periodicidade digitada para a captura de imagens foi de 40 segundos. No teste realizado,
passado exatos 40 segundos a aplicação iniciava o processo para a captura de uma imagem. Porém,
conforme mostra a Figura 29, as nomeações dos arquivos não se mostraram fiéis quanto ao tempo
de 40 segundos entre uma captura e outra. Isso ocorreu também para as outras mídias envolvidas na
aplicação, inclusive GPS. Suspeita-se que pelo fato da aplicação solicitar uma confirmação toda vez
que uma captura das mídias envolvidas for requisitada, o momento exato da captura seja alterado.
Porém não foi possível chegar a uma conclusão plausível dentro do prazo pré-determinado.
3.7 RESULTADOS
Os resultados do projeto foram alcançados conforme os requisitos estabelecidos para o
sistema e os testes realizados conforme mostra o item anterior. Porém, apesar dos resultados terem
sido atingidos, a aplicação ainda se mostra bastante limitada pelo fato da existência de API´s que
são protegidas. Tais API´s não podem ser utilizadas sem antes uma confirmação manual do usuário
final. Para não haver tais confirmações, a aplicação JME precisa ser assinada, fato que não ocorreu
no desenvolvimento deste projeto.
71
4 CONCLUSÕES
O estudo e pesquisa realizados neste projeto permitiram a compreensão sobre diversos
assuntos, como o funcionamento da memória do ser humano; projeto MyLifeBits; computação
móvel; gerações de redes aéreas; tecnologias de desenvolvimento para dispositivos móveis. Na
revisão bibliográfica destacam-se temas como memória do ser humano e computação móvel. Em
seguida, foi aprofundada a pesquisa sobre o projeto da Microsoft chamado MyLifeBits com o
objetivo de ser uma alternativa para o combate do esquecimento de uma pessoa. Além disso,
conceitos do funcionamento e tecnologias das redes celulares foi apresentado. Posteriormente, a
pesquisa se voltou exclusivamente para tecnologias de desenvolvimento focadas em dispositivos
móveis. Como o objetivo deste projeto era desenvolver uma aplicação utilizando JME, houve um
maior aprofundamento das pesquisas sobre esta tecnologia.
Por fim, o esforço foi voltado exclusivamente para questões relacionadas ao
desenvolvimento da aplicação. Foi apresentada uma descrição geral sobre a aplicação, requisitos
funcionais e não funcionais, regras de negócios, arquitetura do sistema e modelagem da aplicação
baseados nos padrões UML. Além disso, questões envolvidas na implementação da aplicação e
prototipação de telas foram mostradas.
O principal objetivo do trabalho era capturar dados multimídia e armazená-los no sistema de
arquivos do telefone celular. Pelos testes reais realizados, a aplicação se comportou de acordo
conforme os requisitos estabelecidos.
No inicío da modelagem do aplicação, algumas ferramentas foram testadas. Dentre elas,
merecem destaques: Enterprise Architect; JUDE; e a ferramenta própria do Netbeans. Visando não
envolver muitas ferramentas para o desenvolvimento, o próprio Netbeans foi usado para a
modelagem. O mesmo se mostrou simples e fácil de manipular.
Pelo fato da grande incompatibilidade encontrada no emulador usado comparado ao celular
real, todo o esforço do desenvolvimento foi concentrado principalmente nos testes. Dentre as etapas
de testes unitários realizados, a que mais demandou tempo foi o uso de coordenadas GPS através do
receptor embutido no celular. Como não foi possível testar no emulador, os testes foram feitos no
próprio celular. Verificou-se que em dias nublados, a coleta das coordenadas se mostrou bastante
demorada quando comparadas a dias sem nuvens.
72
Ainda no desenvolvimento, foram realizados testes com envio das mídias gravadas para um
servidor web local. Como o foco deste trabalho não era aplicações web, não foi dada muita ênfase a
respeito de tecnologias relacionadas. Porém, para testes locais realizados com o emulador, o envio
de imagens e de áudio ocorreu com sucesso.
Como ponto fraco, a aplicação não verifica se há espaço suficiente no cartão de memória do
telefone celular para o armazenamento das mídias. Outro ponto negativo foi a diferença de
comportamento do emulador usado e do telefone real, atrasando dessa forma o desenvolvimento do
projeto. Como ponto forte pode-se citar a flexibilidade dada ao usuário para a escolha das mídias
sujeitas a processamento. Dessa maneira, o usuário pode criar categorias e escolher as mídias de seu
interesse para posterior armazenamento.
Durante o desenvolvimento do projeto, algumas idéias surgiram como forma de realização
de trabalhos futuros. Uma aplicação desktop poderia ser desenvolvida para a organização e
principalmente para a pesquisa dos arquivos coletados pelo celular. O envio dos arquivos do celular
para o computador poderia ser através de cabo USB ou através de tecnologias sem fio, como o
Bluetooth. Com funcionalidades semelhantes a aplicação desktop, uma aplicação web poderia ser
desenvolvida. Dessa forma, enviando os arquivos para um servidor web determinado, o usuário
final irá visualizar seus arquivos de qualquer computador conectado à internet. Além disso, uma
aplicação poderá ser desenvolvida para a comunicação via bluetooth com microcontroladores para
coletar dados de sensores não disponíveis nos telefones celulares.
Atualmente, a capacidade dos celulares para recursos multimídia é bastante avançada.
Existem celulares com câmeras integradas de 5 megapixels e até mais. Conseqüentemente, memória
e processamento também evoluem. Este trabalho apresentou o desenvolvimento de uma aplicação
baseada em computação móvel com a finalidade de coletar e armazenar dados utilizando recursos
multimídia do celular Nokia N95. Todo o desenvolvimento foi feito utilizando a tecnologia Java
Micro Edition junto com a IDE Netbeans 6.1. As especificações técnicas do celular Nokia N95
podem ser verificadas no Anexo I.
73
REFERÊNCIAS BIBLIOGRÁFICAS
ANATEL. Telefonia móvel se aproxima das 97 milhões de habilitações em outubro. 2006. Disponível em: < http://www.anatel.gov.br/Tools/frame.asp?link=/biblioteca/releases/2006/release_20_11_2006mm.pdf > Acesso em: 22 maio 2008.
ANTUNES, Sérgio R.. Telefone Celular – Teoria e Prática. 2ª ed. Rio de Janeiro: Antenna Edições Técnicas Ltda. 1998. ISBN 85-7036-028-2.
ARAÚJO, Jário. Desenvolvendo para WAP com WML. Rio de Janeiro: Ciência Moderna Ltda, 2001.
AZEVEDO, Carlos Renato. Google Maps API. 2008. Disponível em < http://imasters.uol.com.br/artigo/7832/programacao/google_maps_api/> Acesso em: 17 de Novembro 2008.
AZEVEDO, Mauro Pisaneschi. MMS Ganha Força no Brasil. 2006. Disponível em < http://www.teletime.com.br/revista/91/ponto.htm> Acesso em: 10 de março 2008.
BOOCH, Grady; RUMBAUGH, James; JACOBSON Ivar. UML – Guia do usuário. 1ª Ed. Rio de Janeiro: Campus, 2000. ISBN 85-352-0562-4.
BELL, Gordon; GEMMEL, Jim. Uma vida digital. 2007. Disponível em < http://www.developer.com/ws/brew/article.php/1454711> Acesso em: 12 de março 2008.
ERICSSON. 2001. Disponível em< http://www.sonyericsson.com/spg.jsp?cc=global&lc=en&ver=4001&template=ps2_1&zone=ps&supptemplate=ps1#previous > Acesso em: 01 de junho 2008.
FILHO, Huber Bernal. Wireless Application Protocol (WAP). 2004. Disponível em < http://teleco.com.br/tutoriais/tutorialwap/default.asp> Acesso em: 09 de maio 2008.
FILHO, Wilson de Pádua Paula. Multimídia: Conceitos e Aplicações. Rio de Janeiro: LTC – Livros Técnicos e Científicos Editora S.A., 2000. 85-216-1222-2.
FORUM NOKIA. MIDP: Location API Developer´s Guide. 2006. Disponível em < http://sw.nokia.com/id/175bf8e6-a1f5-4d3d-a591-6fc936506a6b/MIDP_Location_API_Developers_Guide_v2_0_en.pdf> Acesso em: 15 de maio 2008.
FORUM NOKIA. Devices, Docs & Tools. 2008. Disponível em < http://www.forum.nokia.com/devices/N96> Acesso em: 10 de maio 2008.
GALL, L. - Multimídia em dispositivos móveis. Mundo Java, Curitiba, n. 16, p. 54-60, maio, 2006.
GODOY, Roberto. Memória. 2004. Disponível em < http://drauziovarella.ig.com.br/artigos/memoria.asp> Acesso em: 09 de julho 2008.
74
HADDAD, Renato. Entendendo Aplicações Móveis no .NET. 2004. Disponível em: <http://www.microsoft.com/brasil/msdn/Tecnologias/movel/mobilidade_entendendo.aspx>Acesso em: 23 de Abril 2008.
IDGNOW. MS desenvolve câmera vestível para pacientes com problemas de memória. 2008. Disponível em < http://idgnow.uol.com.br/computacao_pessoal/2008/01/15/ms-desenvolve-camera-vestivel-para-pacientes-com-problemas-de-memoria/> Acesso em: 10 de Fevereiro 2008.
INFO. Nokia estréia celulares multimídia nos EUA. 2006. Disponível em <http://info.abril.uol.com.br/aberto/infonews/092006/26092006-12.shl> Acesso em: 05 de outubro 2008.
JACOB FILHO, Wilson. Memória. 2006. Disponível em < http://drauziovarella.ig.com.br/entrevistas/memoria1.asp> Acesso em: 10 de maio 2008.
LEE, Valentino; SCHNEIDER, Heather; SCHELL, Robbie. Aplicações Móveis – Arquiterura, projeto e desenvolvimento. São Paulo: Pearson Education do Brasil Ltda. 2005. ISBN 85-346-1540-3.
MAILONLINE. Alzheimer's camera aid 'helps to restore memory. 2007. Disponível em < http://www.dailymail.co.uk/health/article-501046/Alzheimers-camera-aid-helps-restore-memory.html> Acesso em: 04 de abril 2008.
MICROSOFT. MyLifeBits: Attempting to realize the Memex Vision. 2003. Disponível em < research.microsoft.com/users/GBell/Bell_MyLifeBits_Talks_February2003.ppt> Acesso em: 04 de abril 2008.
MARSHALL, Jessica. – Esquecer para lembrar. Mente e Cérebro, São Paulo, n. 183, p. 39-45, abril, 2008.
MICROSOFT, Perguntas Frequentes sobre o Visual Studio .NET 2003. [2003?]. Disponível em: < http://www.microsoft.com/brasil/msdn/produtos/VisualStudio/FAQ/Default.mspx > Acesso em: 28 de maio 2008.
MUCHOW, J. W. Core J2ME – Tecnologia & MIDP. São Paulo: Pearson Makron Books, 2004.
NETBEANS. [2002?]. Disponível em <http://www.netbeans.org/index_pt.html> Acesso em: 05 agosto 2008.
OLIVEIRA, Luciana Bianchini de; SOARES, Marilson Duarte; FERNANDES, Michelle Poliana. Evolução dos Terminais Celulares. 2004. Disponível em < http://www.teleco.com.br/tutoriais/tutorialcelular/default.asp> Acesso em: 10 de setembro 2008.
OLIVEIRA, Wilson José de. WAP – Tecnologia e Segurança. Florianópolis: Visual Books, 2000.
OLIVEIRA, Daniel. – JavaME usando GPS. Web Mobile, Rio de Janeiro, n. 11, p. 20-29, 2006.
PEIXOTO, Eduardo; IIDA, Renato. Desenvolvimento C++ para Symbian OS – Introdução à programação em Symbian C++. Web Mobile, Rio de Janeiro, Edição 04 , p. 16-17, Agosto/Setembro, 2005a.
75
PEIXOTO, Eduardo; IIDA, Renato. Desenvolvimento C++ para Symbian OS – Como funciona o sistema de interface com o usuário. Web Mobile, Rio de Janeiro, Edição 05, p. 74-82, Outubro/Novembro, 2005b.
PEREIRA, Rogério. Introdução ao SuperWaba. 2005. Disponível em: < http://www.superwaba.org/etc/wm_introducao_ao_SuperWaba.pdf> Acesso em: 20 maio 2008.
PLANETA CELULAR. A Evolução nas Comunicações Celulares. 2004. Disponível em < http://www.planetacelular.com.br/pesquisa_e_tecnologia.htm> Acesso em: 12 de maio 2008.
QUALCOMM. A Solução BREW®. 2002. Disponível em < http://brew.qualcomm.com/brew/pt/developer/resources/gs/brew_solution.html#qcom> Acesso em: 22 de maio 2008.
QUALCOMM. 2003. Disponível em < http://www.qualcomm.com.br> Acesso em: 22 de maio 2008.
RODRIGUES, Márcio Eduardo da Costa. Telefonia Celular. 2000. Disponível em < http://www.wirelessbrasil.org/wirelessbr/colaboradores/marcio_rodrigues/tel_01.html> Acesso em: 12 de maio 2008.
SANTOS, Marcelo dos. Sistema Móvel Celular - SMC. [1998?]. Disponível em < http://www.wirelessbrasil.org/wirelessbr/colaboradores/msantos/smc_00.html> Acesso em: 10 de maio 2008.
SCIELO. Hipertexto: evolução histórica e efeitos visuais. 1999. Disponível em < http://www.scielo.br/scielo.php?script=sci_arttext&pid=S0100-19651999000300004&lng=es&nrm=iso&tlng=es> Acesso em: 5 de dezembro 2008.
SCHACTER, Daniel L. – Os sete Pecados. Mente e Cérebro, São Paulo, n. 183, p. 47-51, abril, 2008.
SOUZA, José Luis de; TUDE, Eduardo. ROAMNG. 2002. Disponível em < http://www.teleco.com.br/tutoriais/tutorialroam/default.asp> Acesso em: 15 de setembro 2008.
SOARES, Marilson Duarte. GSM. 2003. Disponível em < http://www.teleco.com.br/tutoriais/tutorialedge/default.asp> Acesso em: 21 de Agosto 2008.
SuperWaba. [2004?]. Disponível em: < http://www.portaljava.com/home/modules.php?name=Content > Acesso em: 15 abril 2008.
SUPERWABA. 2006. Disponível em <www.superwaba.com.br> Acesso em: 22 maio 2008.
SVERZUT, José Umberto. Redes GSM, GPRS, EDGE e UMTS – Evolução a Caminho da Terceira Geração (3G). 1ª Ed. São Paulo: Érica, 2005. ISBN 85-365-0087-5.
TANENBAUM, Andrew S. Redes de Computadores. 4ª. ed. Rio de Janeiro: Campus, 2003. ISBN 85-352-1185-3.
TEIXEIRA, Clóvis; CARNIEL, Juliano D.; JEVEAUX, Paulo César M.. Tudo Sobre
76
TELECO. Aplicações Atuais e Futuras para Internet móvel. 2003. Disponível em <http://teleco.com.br/tutoriais/tutorialcmovel/default.asp> Acesso em: 4 de maio 2008.
TRINDADE, Cristiano. Symbian OS e 3G: A nova geração de celulares. 2004. Disponível em < http://www.imasters.com.br/artigo/2566/mobile/symbian_os_e_3g_a_nova_geracao_de_celulares> Acesso em: 01 de junho 2006.
TUDE, Eduardo. UMTS. 2004. Disponível em < http://www.teleco.com.br/tutoriais/tutorialwcdma/default.asp> Acesso em: 29 de agosto 2006.
TUDE, Eduardo. EDGE. 2003. Disponível em < http://www.teleco.com.br/tutoriais/tutorialgsm/default.asp> Acesso em: 11 de maio 2006.
VAUGHAN, Tay. Multimídia Na Prática. São Paulo: Makron Books do Brasil Editora Ltda., 1994. ISBN 85-346-0183-6.
77
APÊNDICES
78
A MODELAGEM DO SISTEMA
A.1 CASOS DE USO
O diagrama de casos de uso foi apresentado na Figura 21 no item 3.4.1. A seguir é descrito o
fluxo de eventos de cada caso de uso.
A.1.1 UC 01 – Gerenciar Categorias
Caso de uso responsável pelo gerenciamento das categorias.
Fluxo Principal: Gerenciar Categorias
1. O sistema apresenta a tela principal.
2. O usuário seleciona Gerenciar Categoria no menu.
3. O sistema apresenta uma lista contendo as categorias e o menu de comandos.
A.1.2 UC 02 – Incluir Categoria
Caso de uso responsável pela inclusão de uma categoria.
Fluxo Principal: Incluir Categoria
1 O sistema apresenta uma lista contendo as categorias.
2 No menu de comandos, o usuário aperta em Incluir.
3 Na tela seguinte, o usuário preenche um nome para a categoria, escolhe as mídias e
aperta em Ok.
4 Na próxima tela, o usuário preenche os parâmetros para as mídias escolhidas e aperta
em Ok;
5 O sistema retorna para a tela principal.
Fluxo Alternativo: Escolha das mídias Imagem e Vídeo.
Se for selecionada a mídia Imagem e/ou Vídeo no passo 2, o sistema apresenta uma tela para
a escolha da câmera a ser processada.
79
A.1.3 UC 03 – Editar Categoria
Caso de uso responsável pela edição de uma categoria.
Fluxo Principal: Editar Categoria
1 O sistema apresenta uma lista contendo as categorias.
2 O usuário seleciona na lista a categoria
3 No menu de comandos, o usuário aperta em Editar.
4 O sistema apresenta uma tela para selecionar as mídias.
5 Na próxima tela, o usuário preenche os parâmetros para as mídias escolhidas e aperta
em Ok;
6 O sistema retorna para a tela principal.
Fluxo Alternativo: Escolha das mídias Imagem e Vídeo.
Se for selecionada a mídia Imagem e/ou Vídeo no passo 4, o sistema apresenta uma tela para
a escolha da câmera a ser processada.
A.1.4 UC 04 – Excluir Categoria
Caso de uso responsável pela exclusão de uma categoria.
Fluxo Principal: Excluir Categoria
1 O sistema apresenta uma lista contendo as categorias.
2 O usuário seleciona na lista a categoria.
3 No menu de comandos, o usuário aperta em excluir.
4 O usuário seleciona um item na lista;
5 O sistema retorna para a tela principal.
Fluxo de Exceção: Há mídias coletadas.
Se ao tentar excluir uma categoria conter mídias relacionadas a mesma, a seguinte
mensagem é mostrada: “Há mídias relacionadas a esta categoria !”.
80
A.1.5 UC 05 – Iniciar Gravação
Caso de uso responsável pelo início do processamento das mídias.
Fluxo Principal: Iniciar Gravação
1 O sistema apresenta a tela principal.
2 O usuário seleciona Iniciar Gravação no menu.
3 O sistema apresenta uma lista contendo todas as categorias cadastradas.
4 O usuário seleciona uma categoria na lista e aperta ok;
5 É iniciado o processo de gravação das mídias;
6 O sistema apresenta a tela principal.
Fluxo de Exceção: Não há categorias criadas.
Caso não tenha categorias cadastradas, o sistema apresenta a mensagem: “Não há categorias.
Deseja criar uma nova?”.
A.1.6 UC 06 – Parar Gravação
Caso de uso responsável pelo cancelamento do processamento das mídias.
Fluxo Principal: Parar Gravação
1 O sistema apresenta a tela principal.
2 O usuário seleciona Parar Gravação no menu.
3 O sistema cancela a execução das threads envolvidas na gravação.
4 O sistema muda o item Parar Gravação para Iniciar Gravação na tela principal.
A.1.7 UC 07 – Gerenciar Experiências
Caso de uso responsável pelo gerenciamento das mídias coletadas.
Fluxo Principal: Gerenciar Experiências
1 O sistema apresenta a tela principal.
81
2 O usuário seleciona Gerenciar Experiências no menu.
3 O sistema apresenta uma lista contendo a data e nome da categoria.
4 O usuário seleciona um item na lista; e
5 O sistema apresenta uma lista contendo as mídias coletadas.
Fluxo de Exceção: Não há mídias coletadas.
Se no passo 3 não contiver nenhuma mídia coletada, o sistema apresenta a mensagem: “Não
há experiências coletadas”.
A.1.8 UC 08 – Visualizar Mídia
Caso de uso responsável pela visualização das mídias coletadas.
Fluxo Principal: Visualizar Mídia
1 O sistema apresenta a tela principal.
2 O usuário seleciona Gerenciar Experiências no menu.
3 O sistema apresenta uma lista contendo a data e nome da categoria.
4 O usuário seleciona um item na lista;
5 O sistema apresenta uma lista contendo as mídias coletadas.
6 No menu de comandos, o usuário aperta em Visualizar;
7 O sistema apresenta a mídia selecionada em uma nova tela.
Fluxo de Exceção: Não há mídias coletadas.
Se no passo 3 não contiver nenhuma mídia coletada, o sistema apresenta a mensagem: “Não
há experiências coletadas”.
A.1.9 UC 09 – Excluir Mídia
Caso de uso responsável pela exclusão das mídias coletadas.
Fluxo Principal: Excluir Mídia
1 O sistema apresenta a tela principal.
82
2 O usuário seleciona Gerenciar Experiências no menu.
3 O sistema apresenta uma lista contendo a data e nome da categoria.
4 O usuário seleciona um item na lista;
5 O sistema apresenta uma lista contendo as mídias coletadas.
6 No menu de comandos, o usuário aperta em Excluir;
7 O sistema apresenta a mesma tela com uma mídia a menos.
Fluxo de Exceção: Não há mídias coletadas.
Se no passo 3 não contiver nenhuma mídia coletada, o sistema apresenta a mensagem: “Não
há experiências coletadas”.
A.1.10 UC 10 – Enviar Mídia
Caso de uso responsável pelo envio das mídias coletadas para um servidor web.
Fluxo Principal: Excluir Mídia
1 O sistema apresenta a tela principal.
2 O usuário seleciona Gerenciar Experiências no menu.
3 O sistema apresenta uma lista contendo a data e nome da categoria.
4 O usuário seleciona um item na lista;
5 O sistema apresenta uma lista contendo as mídias coletadas.
6 No menu de comandos, o usuário aperta em Enviar;
7 O sistema apresenta uma tela de espera;
8 O sistema exibe a mensagem: “Mídia enviada !”.
Fluxo de Exceção: Não há mídias coletadas.
Se no passo 3 não contiver nenhuma mídia coletada, o sistema apresenta a mensagem: “Não
há experiências coletadas”.
83
A.2 CLASSES DO SISTEMA
Esta seção mostra todas as classes do sistema com seus respectivos atributos e métodos.
A.2.1 Pacote mobilelife.business
Este pacote contém as classes responsáveis por toda regra de negócio do sistema, podendo
serem visualizadas na Figura 34 e Figura 35.
Figura 30: Classes Regra de Negócio.
84
Figura 31: Classes Regra de Negócio – Continuação.
A.2.2 Pacote mobilelife.persistence
Este pacote contém as classes responsáveis pela persistência dos dados no sistema de
arquivo do celular e no RMS. A Figura 36 mostra estas classes.
85
Figura 32: Classes Persistência.
A.2.3 Pacote mobilelife.beans
Este pacote contém as classes que representam as entidades do sistema. Nestas classes estão
contidos métodos para atualizar e obter algum atributo, como mostra a Figura 37 e Figura 38.
86
Figura 33: Classes Entidades.
Figura 34: Classes Entidades - Continuação.
87
A.2.4 Pacote mobilelife.connection
Este pacote contém a classe responsável por estabelecer uma conexão com um servidor web
para em seguida efetuar o envio do arquivo, assim como mostra a Figura 39.
Figura 35: Classe Conexão.
A.2.5 Pacote mobilelife.utility
Este pacote contém a classe responsável por fornecer métodos de classe utilitários para todo
o sistema, assim como mostra a Figura 40.
Figura 36: Classe Conexão.
88
ANEXOS
89
I. DESCRIÇÃO DO DISPOSITIVO MÓVEL UTILIZADO
90
II. ESPECIFICAÇÕES TÉCNICAS DA PLATAFORMA S40
91
III. ESPECIFICAÇÕES TÉCNICAS DA PLATAFORMA S60
92
IV. Netbeans UML Modeling
93