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