tcc - monitoramento por geolocalização
TRANSCRIPT
INSTITUTO SUPERIOR DE MONTES CLAROSFACULDADE DE COMPUTAÇÃO DE MONTES CLAROS
Curso de Tecnologia em Análise e Desenvolvimento de Sistemas
HADSON MARCELO GOMES
MONITORAMENTO DE TRAFEGO POR GEOLOCALIZAÇÃO
Montes Claros – MG
2014
HADSON MARCELO GOMES
MONITORAMENTO DE TRAFEGO POR GEOLOCALIZAÇÃO
Trabalho de Conclusão de Curso apresentado como exigência parcial para obtenção do diploma de Tecnologia em Analise e Desenvolvimento de Sistemas da Faculdade de Computação de Montes Claros.
Orientadora: Janine Alves Prates, Mestre.
Montes Claros – MG
2014
HADSON MARCELO GOMES
MONITORAMENTO DE TRAFEGO POR GEOLOCALIZAÇÃO
Trabalho de Conclusão de Curso aprovado como requisito parcial para obtenção do Diploma de Graduação em Tecnologia em Analise e Desenvolvimento de Sistemas da Faculdade de Computação de Montes Claros.
Aprovado em 16/06/2014
BANCA EXMINADORA:
Ass.________________________________________________________
Ass.________________________________________________________
Ass.________________________________________________________
Montes Claros – MG
2014
Dedico este trabalho aos meus pais, irmãos
e amada esposa.
AGRADECIMENTOS
A jornada do conhecimento humano evolui com o passar de eras. O saber está
entrelaçado à capacidade única que nos foi dada que é a do autoconhecimento.
Nesta longa estrada, muitas pedras e percalços aparecem para desviar a busca do
saber, ao mesmo tempo existem pessoas que nos ajudam a remover essas
barreiras e limpando o caminho nos ajudam no engrandecimento pessoal da
sabedoria. Assim, honro aqui essas pessoas.
Aos meus pais, Zenilton Charles e Mara, que sempre sonharam me ver graduado e
isso está muito perto de acontecer, é uma pedra lapidada do conhecimento.
A minha esposa Dani, que sempre me apoiou de todas as formas possíveis e em
todos os momentos me ajuda a remover as pedras do desvio.
A minha orientadora professora Janine Prates, que acreditou no meu trabalho.
Qualquer tecnologia suficientemente
avançada é indistinta de magia.
Arthur C. Clarke
RESUMO
Este trabalho consiste no desenvolvimento de um sistema de monitoramento de
transporte público de uma cidade de médio porte utilizando o sistema de
posicionamento global (GPS), o serviço de rádio de pacote geral (GPRS) e
computadores móveis com sistema operacional Android. Por meio de um módulo
ônibus instalado no veículo é possível obter as suas localizações e através do envio
das informações para um servidor é possível monitorar os mesmos em seu trajeto.
Os usuários de transporte público acessam estas informações pelo módulo usuário
que consiste em um aplicativo instalado em dispositivos Android, obtendo como
informação a localização dos ônibus durante os seus trajetos, assim conseguindo
um melhor planejamento de suas viagens.
Palavras-chave: GPS. Android. Sistema de monitoramento. GPRS. Transporte
público.
ABSTRACT
This work is the development of a monitoring system for public transport in a
medium-sized city using the global positioning system (GPS), the radio service
overall package (GPRS) and mobile computers with Android operating system.
Through a bus module is installed in the vehicle is possible to get their locations by
sending the information to a server you can monitor them on their path. Users of
public transport access this information by the user module consisting of an
application installed on Android devices, getting information as the location of the
buses during their commutes, thereby achieving a better plan their trips.
Keywords: GPS. Android. Monitoring system. GPRS. Public transportation.
LISTA DE FIGURAS
Figura 1 - Rede GSM acrescida da rede GPRS.
Figura 2 - Requisitos funcionais principais.
Figura 3 - Requisitos Não funcionais.
Figura 4 - Caso de uso de rastreamento.
Figura 5 - Diagrama de atividades de atualização de posição.
Figura 6 - Modelo de entidade e relacionamento.
Figura 7 - Tela da ferramenta Eclipse ADT.
Figura 8 - Tela da ferramenta PHPMyAdmin.
Figura 9 - Trecho de código PHP. Cadastro de Coordenadas.
Figura 10 - Tela inicial módulo usuário.
Figura 11 - Trecho de código que faz requisição ao servidor.
Figura 12 - Tela de escolha do veículo a ser rastreado.
Figura 13 - Código que busca as coordenadas e desenha na tela.
Figura 14 - Demonstração de desenho do veículo no mapa.
Figura 15 - Demonstração de alerta de aproximação de veículo.
ABREVIATURAS E SIGLAS
ADT Android Developer Tools
A-GPS Assisted GPS
ANSI American National Standards Institute
API Application Programming Interfaces
BSS Base Station Subsystem
CU Casos de Uso
DML Data Manipulation Language
GPS Global Positioning System .
GSM Global System for Mobile Communication
GGSN Gateway GPRS Support Node
HTML Hypertext Markup Language
ISO International Organization for Standardization
JVM Java Virtual Machine
MER Modelo de Entidade Relacionamento
MIT Massachusetts Institute of Technology
MS Mobile station
NAVSAT Navy Navigation Satellite System
NFC Near Field Communication
NSS Network and Switching Subsystem
OMS Operations and Maintenance System
OHA Open Handset Alliance
OpenGL ES OpenGL for Embedded Systems
PPS Precise Positioning Service
PHP Hypertext Preprocessor
RF Rádio Frequência
REQF Requisitos Funcionais
REQNF Requisitos Não Funcionais
SPS Standard Positioning Service
SDK Software Development Kit
SQL/DS SQL/Data System
SQL Structured Query Language
SGBD Sistema de Gerenciamento de Banco de Dados
SGSN Serving GPRS Support Node
URL Uniform Resource Locator
SUMÁRIO
1 INTRODUÇÃO 13
2 GLOBAL POSITIONING SYSTEM - GPS 15
2.1 FUNCIONAMENTO DO GPS 17
2.2 GPS EM APARELHOS CELULARES 18
2.2.1 A-GPS – Assisted GPS 18
2.3 GOOGLE MAPS 19
2.3.1 LBS no Android 20
2.4 ANDROID 20
2.4.1 Camada “Aplicações” 22
2.4.2 Camada “Framework de aplicações” 22
2.4.3 Camada “Bibliotecas” 22
2.4.4 Camada “Tempo de Execução Android” 23
2.4.5 Camada “Kernel do Linux” 23
2.5 VERSÕES DO ANDROID 23
2.5.1 Android 1.0 24
2.5.2 Android 1.5 – Cupcake 24
2.5.3 Android 1.6 - Donut 24
2.5.4 Android 2.0 – Eclair 25
2.5.5 Android 2.2 – Froyo 25
2.5.6 Android 2.3 – Gingerbread 25
2.5.7 Android 3.0 - Honeycomb 25
2.5.8 Android 4.0 - Ice Cream Sandwich 26
2.5.9 Android 4.1 - Jelly Bean 26
2.5.10 Android 4.4 – KitKat 26
2.6 JAVA 27
2.6.1 A linguagem de programação Java 27
2.6.2 A plataforma Java 28
2.6.2.1 Java Virtual Machine 28
2.6.2.2 Java Application Programming Interface 29
2.7 BANCO DE DADOS 29
2.7.1 Sistema de Gerenciamento de Banco de Dados – SGBD 30
2.7.2 SGBD SQLite 30
2.7.3 SQLite no Android 31
2.7.4 Características da biblioteca SQLite 31
2.7.5 Exemplos de uso do SQLite 32
2.8 TRANSMISSÃO DE DADOS 32
2.8.1 Redes GPRS 33
3 DESENVOLVIMENTO DO SISTEMA 35
3.1 LEVANTAMENTO DE INFORMAÇÕES 35
3.2 ESPECIFICAÇÃO 36
3.2.1 Requisitos Funcionais 36
3.2.2 Requisitos Não Funcionais 37
3.2.3 Diagrama de Casos de Uso 37
3.2.4 Diagrama de Atividades 38
3.2.5 Modelo Entidade Relacionamento 39
3.3 IMPLEMENTAÇÃO 40
3.3.1 Técnicas e ferramentas utilizadas 40
3.4 OPERACIONALIDADE DA IMPLEMENTAÇÃO 43
4 CONSIDERAÇÕES FINAIS 51
5 REFERÊNCIAS BIBLIOGRÁFICAS 53
1 INTRODUÇÃO
Para Taurion (2013), uma cidade inteligente é a que otimiza a capacidade da
infraestrutura já existente com o uso inteligente de tecnologias. Em 1800, a maior
cidade do mundo era Londres, na Inglaterra, com cerca de um milhão de habitantes.
Em 1960, o planeta tinha 111 cidades com mais de um milhão de pessoas. Em 1985
já eram 280 e hoje mais de 300, das quais 13 estão no Brasil.
É de se esperar que, com o aumento significativo da população, problemas no
transito como congestionamentos e falta de infraestrutura apropriada aconteçam.
Partindo dessa premissa, percebe-se a importância da utilização de métodos
tecnológicos para ajudar na solução de tais problemas de forma plausível e eficiente.
E uma destas respostas seria um possível desenvolvimento de um sistema que
monitorasse em tempo real a posição atual dos ônibus do transporte coletivo a fim
de melhorar e desafogar o transito das cidades, pois com um controle mais
acessível aos usuários dependentes desse sistema de transporte poderia até
mesmo encorajá-los e ainda atrair novos utilizadores deste meio de locomoção. E é
baseado nisso que se propõe a execução deste trabalho.
Neste trabalho estabeleceu-se como objetivo, identificar a existência de recursos
tecnológicos e bibliográficos disponíveis para o desenvolvimento e implementação
de uma aplicação para plataformas móveis que viabilizará o fácil acesso dos
usuários do sistema de transporte público em uma cidade de médio porte.
Para construir o referencial teórico para a realização desta pesquisa, optou-se a
utilizar os autores que aqui principalmente cito SVERZUT(2005), MORIMOTO(2009),
GOOGLE INC(2014), e ORACLE(2014), além de outros.
Quanto à natureza, esta pesquisa se enquadra como aplicada, pois busca
resultados que possam ser utilizados como solução de problemas reais e pode ser
classificada quanto aos objetivos como sendo descritiva pois, segundo GIL(2008),
uma pesquisa descritiva é assim chamada quando deve descrever as características
de determinadas populações ou fenômenos. Em relação às técnicas utilizadas,
Gil(2008) diz que quando uma pesquisa é desenvolvida com base em material já
elaborado e constituída principalmente de livros e artigos científicos, esta deve ser
uma pesquisa bibliográfica. Esse trabalho também, quanto à técnica, pode ser
classificado como experimental pois é desenvolvido um sistema que influencia de
modo geral o resultado da pesquisa. A abordagem de análise de dados é qualitativa,
sendo desenvolvida entre os períodos de agosto de 2013 e maio de 2014.
Estruturalmente, no segundo capítulo tem-se a apresentação da fundamentação
teórica pesquisada sobre a história dos sistemas de Geolocalização e seu
funcionamento, os tipo de GPS em celulares, a API do Google Maps e suas
aplicações, os sistemas Android, a linguagem Java, sistemas de gerenciamento de
banco de dados e, por fim, as redres GPRS. O 3º capítulo apresenta o
desenvolvimento do sistema, iniciando com o levantamento de informações, tendo
na sequência a especificação e implementação. Em seguida, apresenta-se as
considerações finais do autor em relação ao trabalho apresentado.
2 GLOBAL POSITIONING SYSTEM – GPS
O GPS é um sistema de posicionamento de abrangência global em tempo real,
desenvolvido pelo Departamento de Defesa dos Estados Unidos, nas últimas
décadas do século passado. Embora a obtenção das coordenadas espaciais de um
ponto possa ser considerada, atualmente, uma tarefa fácil, há muito tempo se
procurava uma maneira de localização terrestre que substituísse as fontes de
orientação pouco precisas proporcionadas pela orientação do Sol, das estrelas e dos
planetas, predominante durante séculos (MONICO, 2008).
Em 1960 a Força Aérea e a Marinha americana trabalhavam para o
desenvolvimento de um sistema de navegação por satélites. A Marinha patrocinou
dois programas:
Transit: Conhecido também como Navy Navigation Satellite System - NAVSAT. Foi o
primeiro sistema de navegação por satélite a ser usado operacionalmente. Foi criado
para obter informações precisas o posicionamento para submarinos lançadores de
mísseis balísticos, e foi usado pela marinha dos Estados Unidos com um sistema de
navegação, bem como para vigilância hidrográfica e geodésica.
Segundo ABC71 (2009), o sistema foi desenvolvido no Laboratório de Física
Aplicada da Johns Hopkins University para a marinha dos Estados Unidos. Foram
feitos vários testes usando satélites conhecidos, colocados em órbitas polares de
baixa altitude, a 1100 km acima da superfície da Terra. Em cada teste eram usados
no mínimo cinco satélites necessários para permitir uma cobertura global.
O primeiro teste bem sucedido do sistema foi realizado em 1960, para ter um bom
funcionamento foram necessários de pelo menos mais cinco satélites usados como
sobressalentes para cada satélite que estava na órbita.
Os satélites foram definidos de modo a cobrir a Terra inteira, com isso podiam calcular qualquer posição com base no instante da passagem dos satélites. No entanto para ter uma nova posição, só poderia ser calculada na próxima passagem do satélite. O intervalo de tempo entre as passagens corresponderia ao período orbital (106 minutos) se o mesmo satélite estivesse visível em ambas às passagens, caso contrário teria um atraso típico de uma hora ou duas. (ABC71, 2014, p.1)
Timation: Na Naval Research Laboratory, do Centro Naval de Tecnologia Espacial,
foi desenvolvido o sistema de navegação Timation, iniciado em 1964, mas o satélite
só foi laçado em 1967.
Na época o sistema mostrou que era mais preciso que os de sua categoria.
Segundo Pike (2011), em 1969 foi criado o Timation II mostrando novas técnicas,
como um relógio de alta precisão, podendo oferecer bases de posições mais
precisas, usando um novo sistema tridimensional de cobertura em todo mundo.
Os sistemas de navegação Transit e Timation operavam em modo 2D, pois usavam
latitude e longitude. No período de 1960 a Força Aérea estudou sistemas que
operavam em 3D que usavam latitude, longitude e altitude. Após inúmeros estudos,
foi escolhido o programa 612B.
De acordo com Pike (2011), em 1973, com a fusão dos programas Timation e 612B,
surgiu o programa Navigation Satellite with Time and Ranging - Global Positioning
System - NAVSTAR GPS. Em dezembro de 1973 foi autorizado o início da primeira
fase do programa. Foram feitos estudos sobre desempenho e real viabilidade do
sistema, que durou até o ano 1979. Em seguida, deu-se início à segunda fase com o
desenvolvimento e teste dos equipamentos GPS, que durou até 1985.
Na terceira fase foram produzidos os aparelhos GPS. Para o melhor funcionamento
do sistema foi usada uma rede de 24 satélites, que proporcionava uma cobertura
completa, com funcionamento simultâneo, conhecida como Full Operational
Capability.
De acordo com ABC71 (2009), em 1980 o presidente Ronald Reagan autorizou o
uso civil dos sistemas. Na época todos os equipamentos que foram vendidos
continham um erro artificial no sistema chamado “Disponibilidade Seletiva”, que foi
implantado pelo Departamento de Defesa americano, com o objetivo de resguarda
de segurança interna do país. Em Maio de 2000 o Presidente Clinton fez um decreto
para cancelar o erro implantado nos equipamentos, pois o contínuo desenvolvimento
tecnológico permitiu ao Departamento de Defesa obstruir a precisão do Sistema
onde e quando os interesses americanos exigissem. Com o decreto, o erro médio de
100 metros na localização do receptor ficou dez vezes menor.
O GPS surgiu com objetivo de guerra e navegação de alta precisão, para ser usado no transporte militar e mísseis. Os GPS foram usados como teste na guerra do Golfo que, facilitando a locomoção das tropas no deserto, os mísseis passaram a atingir seus alvos com erros mínimos. (PIKE, 2014, p.1)
1.1FUNCIONAMENTO DO GPS
O GPS conta com dois tipos de serviço de posicionamento diferentes: o padrão
Standard Positioning Service - SPS e o preciso Precise Positioning Service - PPS.
O SPS está disponível a todos os usuários do globo e proporciona valores com
precisão de 100 a 140 m ou de 10 a 20 m, enquanto o PPS, de uso restrito militar,
apresenta precisão de 10 a 20 m. Nota-se, assim, que ambos os serviços podem
proporcionar valores com a mesma precisão. O serviço SPS tem dois intervalos
diferentes de precisão devido à limitação seletiva imposta pelo Departamento de
Defesa Americano (DEPARTAMENT OF DEFENCE, 2008): um processo de
criptografia aplicado em um dos códigos utilizados no GPS para realizar as medidas
de distâncias, capaz de tornar as medições do SPS mais imprecisas, caso
necessário. A restrição foi imposta inicialmente por motivo de segurança nacional.
Porém, em maio de 2000, essa técnica de deterioração do sinal recebido pelo SPS
foi descontinuada, melhorando consideravelmente o nível de precisão alcançado por
usuários civis. Após essa decisão, o Conselho de Segurança americano passou a
fazer reuniões anuais para decidir pela reativação ou não da disponibilidade seletiva
do sinal (THE WHITE HOUSE, 1996)
O GPS é dividido em três segmentos: espacial, de controle e de usuários. O
segmento espacial consiste de 24 satélites distribuídos em seis planos orbitais
igualmente espaçados, que cruzam o centro da Terra. Cada plano conta com quatro
satélites. Essa configuração permite que, em qualquer local da superfície terrestre, a
qualquer momento, pelo menos quatro satélites estejam "visíveis" por um receptor.
O segmento de controle é responsável pelo monitoramento, correção dos relógios e
atualização periódica das mensagens de navegação de cada satélite. É composto
por cinco estações terrestres estrategicamente distribuídas no globo. O segmento de
usuários é constituído pelos receptores GPS. Dependendo da aplicação a qual se
destina, o aparelho necessita um grau maior ou menor de qualidade do seu relógio
interno (MONICO, 2008).
É interessante salientar que muitas pessoas se referem ao GPS como "sistema
GPS". Tal expressão é empregada de forma equivocada, visto que o acrônimo já
carrega em si a palavra sistema.
1.2 GPS EM APARELHOS CELULARES
Segundo Morimoto (2009), os componentes de um dispositivo GPS sofreram grande
miniaturização com o tempo, e em consequência, grande queda de preço. É
importante considerar que muito do valor de um GPS são hardwares de interação
como tela, botões, processadores de som, entre outros. Com isso, passou a ser uma
medida natural adotar um receptor de GPS em um smartphone, pois o mesmo já
tem muitas das características de hardware necessárias em um aparelho GPS, tanto
que quase todos os aparelhos de smartphone no mercado hoje possuem receptores
de GPS, permitindo assim uma grande redução de preço do dispositivo, que agora
teria que orçar apenas o receptor, seu processador e o software responsável pela
navegação.
Com a miniaturização dos componentes, passou a fazer sentido incluir receptores de GPS em smartphones, aproveitando a tela, processador, memória e os demais componentes. Chipsets atuais, como o navilink nl5350 (usado no n95 e em outros modelos da Nokia) combinam o receptor GPS, o processador de sinais e uma pequena quantidade de memória usada por ele em um encapsulamento incrivelmente compacto, que adiciona muito pouco ao peso e volume do aparelho. (MORIMOTO, 2009, p.362).
1.2.A A-GPS – Assisted GPS
Morimoto (2009), os smartphones usam uma antena GPS menor e menos sensível e
com chipset GPS mais fraco, causando certa demora em achar a localização ou
perdendo o sinal frequentemente. Para evitar o problema e ajudar na localização, os
smartphones utilizam um sistema híbrido, o A-GPS.
O A-GPS funciona através de uma combinação de sinais de satélites GPS e
triangulação por torres de celular, além de um servidor remoto que fornece o
posicionamento dos satélites, que facilita a rápida localização pelo receptor.
Morimoto (2009, p. 273) diz:
"Naturalmente, todas as informações são transmitidas usando a rede celular, mas o
volume de dados transferido é pequeno, apenas alguns poucos kbytes por consulta."
1.3 GOOGLE MAPS
De acordo Morimoto (2009), a opção mais simples e utilizada de softwares para
celular atualmente é o Google Maps. Ele possui versões não apenas para celulares,
mas para computadores também, podendo ser usado em diversos sistemas
diferentes, e até mesmo online. Possui ainda a opção de visualização por imagens
de satélite, o que dá uma visão mais real do local de interesse.
A concepção do Google Maps teve início em 2004, quando o Google comprou a
Keyhole, empresa de mapeamento global, e iniciou o desenvolvimento do Google
Earth. O Google Earth foi lançado ao público em 2005, pouco menos de um ano
depois da compra da Keyhole, programa esse que expandiu os horizontes do
Google, e que surpreendeu muitas pessoas. Permitia a exploração, através de
imagens de satélite, da maioria dos espaços do planeta.
O Google Earth permitia que muitas empresas e pessoas pudessem acessar
imagens aéreas de cidades ou locais com relativa qualidade, e sem custo. Muitos
passaram a utilizar esse software por simples curiosidade, para ver suas moradias
ou locais de trabalho. Motivos esses que permitiram ao software grande
popularidade logo após seu lançamento.
Ainda segundo o autor, o Google Maps permite que tracemos uma rota,
selecionando um ponto de origem e um de destino, ele exibirá um percurso no
mapa, com uma linha, exibindo todo o trajeto, disponibilizando informações sobre
quais ruas usar, distâncias e localizações. É possível selecionar qual o meio de
transporte a ser utilizado, e, dependendo do meio escolhido ele selecionará o melhor
percurso, como exemplo, se o meio selecionado for a pé, ele irá te mandar pelo
caminho mais curto, porém se for um automóvel, ele irá considerar o sentido das
ruas, e seu devido percurso.
Mais recentemente, o Google lançou sua mais nova forma de visualização urbana, o
Google Street View, que permite visualizar a cidade de forma totalmente inovadora,
através das ruas. Eles utilizaram diversos carros equipados com câmeras 360º, que
permitem que a pessoa utilizando o software consiga ver os locais de interesse
como se realmente estivessem no local. O Street View já está disponível em
diversas cidades no mundo, como Nova York, Los Angeles, Sidney, São Paulo,
Montes Claros, Varzelândia, etc.
Entretanto, o Google Maps não é muito bom em mostrar o deslocamento em tempo real quando você se move rapidamente. Em um carro em movimento, por exemplo, a seta simplesmente pula de um quarteirão para o outro, na maior parte do tempo, fazendo com que seja difícil se orientar por ele quando está dirigindo. Aplicativos que incluem suporte à navegação assistida, como o Nokia Maps e o Garmin são bem melhores nesse quesito. (MORIMOTO, 2009, p. 78).
Embora seja um programa com pouco tempo de funcionamento (disponível desde o
dia 8 fevereiro de 2005), o Maps impressiona pela quantidade de recursos
oferecidos tanto para usuários comuns, que irão utilizar de maneira mais simplista o
serviço, até usuários avançados, que poderão criar serviços utilizando as Application
Programming Interfaces - APIs disponibilizadas pelo Google Maps.
1.3.A LBS no Android
Na documentação on-line do Google INC (2014), o Android provê um framework de
localização que pode ser usado na criação de aplicações baseadas em localização.
O Android também possui uma biblioteca do Google Maps nativamente instalada
que permite a criação de serviços baseados em mapas. O Android provê, com isso,
todos os recursos necessários para a criação de sofisticados sistemas de
localização utilizando mapas.
A seguir estaremos entrando em detalhes sobre o pacote Location da API Google
Maps.
1.4 ANDROID
Segundo Google INC (2014), Android é uma plataforma para dispositivos móveis,
criada para diminuir custos e melhorar a experiência do usuário nesses dispositivos.
O Android começou como uma pequena empresa com o nome do próprio Android
Inc, em Palo Alto, Califórnia, EUA, criada por quatro sócios, chamados Andy Rubin,
Rich Miner, Nick Sears e Chris White. Somente em 2006 o Google tomou posse do
projeto comprando a Android Inc e assumindo a direção do desenvolvimento do
sistema.
No ano seguinte, em 2007, foi criada a Open Handset Alliance - OHA, liderada pela
Google, como um grupo de empresas unidas, com o objetivo de concluir o
desenvolvimento do Android como um sistema móvel e gratuito para assim, viabilizar
a sua distribuição em massa, com liberdade de desenvolvimento de aplicativos e
liberdade de plataforma de hardware. A OHA iniciou suas operações com 40
empresas.
Atualmente, esse número está perto das 90 empresas. No mesmo ano, foi liberada a
versão Beta do Software Development Kit - SDK do Android.
De acordo com a empresa, aplicações podem ser livremente desenvolvidas para a
plataforma Android, pois a mesma possui um SDK que fornece ao programador
todas as APIs necessárias para a interação inicial com a plataforma. O SDK do
Android permite, também, que o programador utilize um gerenciador de banco de
dados SQlite e suporta gráficos 3D baseados nas especificações 1.0 da OpenGL for
Embedded Systems - OpenGL ES.
Dentre muitas características, o Android possui nativamente um framework de
aplicações, uma máquina virtual Dalvik (Java) otimizada para dispositivos móveis,
um navegador web baseado na engine de código aberto Webkit, suporte a arquivos
de mídia de áudio e vídeo e um ambiente de desenvolvimento rico em ferramentas.
A empresa ainda diz que o Android foi idealizado para ser um sistema com código
fonte opensource, facilitando a adequação a diversos dispositivos diferentes e
personalização do conteúdo. Devido a essa facilidade, é comum encontrarmos
aparelhos que possuem personalizações da operadora de telefonia ou do fabricante
como forma de concorrência entre os mesmos. Pelo fato de ser baseado no Linux,
ele também possui um repositório de aplicativos, onde todos os aplicativos públicos
a serem instalados nos sistema podem ser visualizados e adquiridos.
Dentre as tecnologias que compõem o Android, pode-se destacar como principais o
Java, a linguagem de programação usada no desenvolvimento de aplicações nativas
para o Android, o SQLite, um sistema gerenciador de banco de dados leve e rápido,
usado para armazenar dados das aplicações durante a execução e o GPS, que
permite a integração do serviço com as aplicações.
A arquitetura do Android está dividido em camadas, permitindo ao programador ou à
empresa de desenvolvimento de dispositivos customizar apenas a parte que lhe será
necessária. As camadas da arquitetura do Android, da “externa” para a “interna”,
são:
Aplicações
Framework de aplicações
Bibliotecas
Tempo de Execução Android
Kernel do Linux
1.4.A Camada “Aplicações”
A camada de Aplicações contém todas as aplicações já compiladas e instaladas,
prontas para serem executadas.
Essas aplicações podem ser criadas usando as APIs do Android juntamente com a
linguagem de programação Java.
1.4.B Camada “Framework de aplicações”
A camada do Framework de aplicações contém todas as APIs necessárias para o
desenvolvimento das aplicações voltadas para o Android.
As aplicações nativas da plataforma são desenvolvidas utilizando essas mesmas
APIs, permitindo ao programador alterar, se necessário, alguma funcionalidade
contida no núcleo de uma aplicação nativa, desde que o usuário permita o acesso
de uma aplicação à outra.
1.4.C Camada “Bibliotecas”
A camada de Bibliotecas contém todas as bibliotecas necessárias para manuseio de
aplicações terceiras.
Como exemplos de bibliotecas tem-se a biblioteca do sistema C, bibliotecas de
reprodução e gravação de áudio e vídeo, bibliotecas de uma engine de gráficos 2D e
3D, bibliotecas para manuseio de bancos de dados SQLite e bibliotecas de
renderização de vetores e bitmaps.
1.4.D Camada “Tempo de Execução Android”
A camada de Tempo de Execução Android contém as bibliotecas do núcleo da
linguagem Java, necessárias para execução das aplicações, e a máquina virtual
Dalvik, otimizada para dispositivos móveis onde cada aplicação é executada como
uma nova instância na máquina virtual.
Segundo GOOGLE INC (2014), a máquina virtual Dalvik, presente nesta camada,
depende da camada Kernel do Linux para tarefas mais próximas ao hardware, como
gerenciamento de threads e de memória.
1.4.E Camada “Kernel do Linux”
A camada do Kernel do Linux contém o núcleo do Android, usando a versão 2.6 do
Linux para tarefas como gerenciamento de processos, de rede e drivers.
O Kernel também serve como camada de abstração entre o hardware do aparelho e
o resto da plataforma.
1.5 VERSÕES DO ANDROID
A empresa ainda diz em sua documentação que, de tempos em tempos, são
disponibilizadas novas versões do Android, normalmente contendo novos recursos,
melhoria de desempenho e correção de bugs e problemas.
Curiosamente, a partir da versão 1.5 do sistema, cada versão tem um codinome
representando um nome de um doce e em ordem alfabética.
1.5.A Android 1.0
Segundo Prado (2011), em 2008 foi lançada a primeira versão pública do sistema
Android, a versão 1.0. O primeiro dispositivo a venda a utilizar esse sistema foi um
Smartphone da HTC, o “HTC Dream G1”. Já nesta versão, o Android já era
multitarefa e tinha total integração com os serviços da Google, navegador web com
HTML - Hypertext Markup Language - e XHTML - XML HTML, multijanelas,
mensageiro instantâneo e suporte a Wi-Fi e Bluetooth.
Juntamente com a versão 1.0 do sistema, foi lançado o repositório de aplicações
oficial da Google, o Google Market, em que os usuários podem acessar uma lista
com quase todos os aplicativos disponíveis para o sistema. Nele é possível tanto
obter aplicativos gratuitos, como aplicativos pagos.
1.5.B Android 1.5 – Cupcake
No dia 30 de abril de 2009 foi lançada a versão 1.5, codinome Cupcake, que era
baseado na versão 2.6.27 do Kernel Linux.
Tinha melhorias no gerenciamento da câmera, nos sistemas de aquisição de GPS,
teclado na tela, e upload direto para serviços de imagem e vídeo do Google
(Youtube e Picasa).
1.5.C Android 1.6 - Donut
De acordo com Prado (2011), baseado na versão 2.6.29 do Kernel Linux foi lançada
a versão 1.6, codinome Donut, no dia 15 de setembro de 2009. Com ela, foram
adicionadas as funções de busca por voz e caixa de busca rápida, melhorias no
sistema de câmera integrada, gravador, galeria, modos de vídeo.
Foi adicionado um indicador de uso de bateria, suporte a CDMA, e funções de texto
para multilinguagem.
1.5.D Android 2.0 – Eclair
Em 2009, no dia 26 de outubro, foi lançada a versão 2.0, codinome Eclair, do
sistema, e, para Prado (2014), ainda usando a versão 2.6.29 do Kernel Linux.
Nessa versão, foram adicionados a sincronia de múltiplas contas de e-mail e
contatos, suporte a Microsoft Exchange, navegador com HTML5, Bluetooth 2.1, e
melhorias no calendário.
1.5.E Android 2.2 – Froyo
No dia 20 de maio de 2010, foi lançada a versão 2.2, codinome Froyo.
Baseado na versão 2.6.32 do Kernel Linux, com suporte melhorado ao Exchange,
suporte a hotspot, teclado multilinguagem, suporte ao Flash 10.1, e com dicas de
widgets na tela principal.
1.5.F Android 2.3 – Gingerbread
A versão 2.3, codinome Gingerbread, foi lançada no dia 6 de dezembro de 2010. De
acordo com Google INC (2014), a versão tem a função de NFC - Near Field
Communication, que permite a comunicação entre dois dispositivos próximos sem a
necessidade de cabos.
Conta também com novos ajustes de interface para simplificar e melhorar a
velocidade, além de um novo teclado com maior facilidade de digitação, copiar e
colar one touch, e de realizar chamadas pela internet.
1.5.G Android 3.0 - Honeycomb
Para Prado (2011), no dia 10 de maio de 2011 foi lançada a versão 3.0.
Sob o codinome Honeycomb, que foi desenvolvida primariamente para tablets e
dispositivos com telas maiores, com melhorias no multitouch, muititarefa otimizada e
compartilhamento de Bluetooth.
1.5.H Android 4.0 - Ice Cream Sandwich
A empresa Google INC (2014) diz, em outubro de 2011 foi anunciada a versão 4.0
codinome Ice Cream Sandwich, essa versão foi reformulada, visando apresentar um
sistema novo aos usuários, e não apenas um sistema atualizado como nas outras
versões.
Entre suas novidades estão novas fontes, visual renovado, refinamento na
movimentação do touch, sistema de reconhecimento facial, melhorias de
desempenho, navegação mais rápida e sistema de compartilhamento de dados por
NFC.
1.5.I Android 4.1 - Jelly Bean
Anunciada em 27 de junho de 2012, a versão 4.1 do Android, codinome Jelly Bean,
trouxe, ainda segundo Google INC (2014), poucas melhoras visuais, focando-se em
acessibilidade e desempenho. Entre outras, foram adicionadas funções de
acessibilidade para deficientes visuais, como gestos para ações pré-configuradas,
uma função para escrever textos por voz (somente em inglês) e foram feitas
melhorias no comportamento dos widgets na tela inicial e no desempenho do
browser e da agenda. A área de notificações foi atualizada, podendo conter mais
informações sobre cada notificação individualmente.
A empresa ainda diz que junto com esta versão do Android, a Google também
anunciou o serviço Google Now, que auxilia o usuário nas tarefas diárias como, por
exemplo, lembrando-o de compromissos agendados, avisando sobre voos atrasados
etc.
1.5.J Android 4.4 – KitKat
Ainda citando a empresa Google INC (2014), houve melhorias de desempenho para
tornar o KitKat mais suave e responsivo nos smartphones de baixo custo, com 512
MB de RAM. Além da otimização no consumo de memória, o Google afirma que
realizou melhorias no touchscreen: comandos de toque responderão de maneira
mais rápida e precisa que no Jelly Bean. Alternar entre aplicativos também está mais
rápido.
Outras novidades incluem a unificação do aplicativo Hangouts com o SMS, suporte a
novos gestos de toque, impressão de documentos em dispositivos conectados ao
Google Cloud Print e melhor suporte a serviços de armazenamento na nuvem de
terceiros.
1.6 JAVA
Segundo a Oracle (2014), em 1991, um grupo de engenheiros da empresa Sun
acreditava na tendência da junção dos dispositivos móveis pessoais e dos
computadores caseiros. Com essa perspectiva em mente, esse grupo, denominado
Green Team, liderado por James Gosling, trabalhou arduamente para criar o que,
futuramente, iria revolucionar nosso mundo: a linguagem de programação Java.
Para demonstração de sua linguagem de programação e de seu potencial, o Green
Team trabalhou num controle remoto portátil que tinha como alvo a comunicação
com as televisões a cabo digitais, mas, naquela época, esse conceito de integração
de dispositivos estava avançado demais para os equipamentos disponíveis.
Percebendo a ascensão da internet, em 1995, o grupo anunciou que navegador de
internet Netscape Navigator passaria a incorporar a tecnologia Java.
1.6.A A linguagem de programação Java
Sendo aclamada como uma linguagem de programação versátil, o Java é a principal
linguagem de programação usada nos aplicativos nativos do Android.
Para a Oracle (2014), na linguagem de programação Java, todos os arquivos de
código-fonte possuem a extensão “.java” e têm seu conteúdo inalterado, podendo
ser lidos e modificados pelo programador. Depois que o arquivo de código-fonte é
salvo, é necessário compilá-lo com o compilador javac (fornecido junto com as
ferramentas para programação Java), em um arquivo “.class”. Esse arquivo
compilado tem seu conteúdo convertido para bytecode, que não é um código que
pode ser lido ou modificado pelo programador e sim a linguagem da Java Virtual
Machine - JVM.
Segundo a Oracle (2014), uma instância da JVM na máquina do usuário lê o
bytecode do arquivo “.class” e executa a aplicação. Já que a JVM está disponível em
vários sistemas operacionais, o mesmo arquivo bytecode “.class” pode ser
executado em outra máquina, sem necessidade de edição e recompilação.
1.6.B A plataforma Java
A plataforma Java se diferencia, principalmente, das outras por ser uma plataforma
somente de software, que pode ser executada sobre diferentes tipos de hardware.
Como um ambiente independente de plataforma, a Java pode ser um pouco mais
lenta do que código nativo. Porém, avanços na tecnologia do compilador e da JVM
têm trazido o desempenho para perto que o código nativo é capaz, sem
comprometer a portabilidade (ORACLE, 2014).
A plataforma possui dois componentes:
Java Virtual Machine
Java API
1.6.B.1 Java Virtual Machine
Segundo Oracle (2014), a JVM é a peça fundamental da plataforma Java. É o que
faz com que ela seja independente de hardware e de sistema operacional. Ela é um
computador abstrato, virtual, que, como toda máquina física, real, possui conjuntos
de instruções e manipula várias áreas da memória durante a execução.
A JVM não conhece linguagem alguma, a não ser a linguagem bytecode dos
arquivos “.class” e, apesar de ser bem restrita quanto a formas sintáticas e
estruturais, se uma linguagem pode gerar uma aplicação no formato especificado
pela JVM, então essa aplicação pode se utilizar das funções da mesma.
1.6.B.2 Java Application Programming Interface
A Oracle (2014), a Java API é uma grande coleção de componentes de software
prontas que provém várias capacidades úteis. Ela está agrupada em bibliotecas de
classes e interfaces relacionadas, bibliotecas essas, também conhecidas como
pacotes.
1.7 BANCO DE DADOS
Segundo Eduardo (2008), os fundamentos de bancos de dados relacionais surgiram
na empresa IBM, nas décadas de 1960 e 1970, através de pesquisas de funções de
automação de escritório. Foi durante um período da história na qual empresas
descobriram que estava muito custoso empregar um número grande de pessoas
para fazer trabalhos como armazenar e indexar (organizar) arquivos. Por este
motivo, valia a pena os esforços e investimentos em pesquisar um meio mais barato
e ter uma solução mecânica eficiente.
O autor ainda salienta que em 1970 um pesquisador da IBM - Ted Codd - publicou o
primeiro artigo sobre bancos de dados relacionais. Este artigo tratava sobre o uso de
cálculo e álgebra relacional para permitir que usuários não técnicos armazenassem
e recuperassem grande quantidade de informações. Codd visionava um sistema
onde o usuário seria capaz de acessar as informações através de comandos em
inglês, onde as informações estariam armazenadas em tabelas.
Devido à natureza técnica deste artigo e a relativa complicação matemática, o
significado e proposição do artigo não foram prontamente realizados. Entretanto, ele
levou a IBM a montar um grupo de pesquisa conhecido como Sistema R (System R).
Continuando, o autor ainda diz que o projeto do Sistema R era criar um sistema de
banco de dados relacional, o qual eventualmente se tornaria um produto. Os
primeiros protótipos foram utilizados por muitas organizações, tais como
Massachusetts Institute of Technology - MIT, uma escola renomada de negócios
norte-americana. Novas versões foram testadas com empresas de aviação para
rastreamento do manufaturamento de estoque.
Eventualmente o Sistema R evoluiu para SQL/Data System - SQL/DS, o qual
posteriormente tornou-se o DB2. A linguagem criada pelo grupo do Sistema R foi a
Structured Query Language - SQL. Esta linguagem tornou-se um padrão na
indústria para bancos de dados relacionais e hoje é um padrão International
Organization for Standardization - ISO.
1.7.A Sistema de Gerenciamento de Banco de Dados – SGBD
Segundo Eduardo (2008), um SGBD consiste em uma coleção de dados inter-
relacionados e em um conjunto de programas para acessá-los. Um conjunto de
dados, normalmente referenciado como banco de dados, contém informações sobre
uma empresa particular, por exemplo. O principal objetivo de um SGBD é prover um
ambiente que seja adequado e eficiente para recuperar e armazenar informações de
banco de dados.
O autor ainda diz em seu livro que os sistemas de banco de dados são projetados
para gerenciar grandes grupos de informações. O gerenciamento de dados envolve
a definição de estruturas para armazenamento de informação e o fornecimento de
mecanismos para manipulá-las. Além disso, o sistema precisa fornecer segurança
das informações armazenadas, caso ocorra algum problema ou contra tentativas de
acesso não autorizado. Se os dados devem ser divididos entre diversos usuários, o
sistema precisa evitar possíveis resultados anômalos.
O autor afirma a importância das informações na maioria das organizações e o
consequente valor dos bancos de dados têm orientado o desenvolvimento de um
grande corpo de conceitos e técnicas para o gerenciamento eficiente dos dados.
1.7.B SGBD SQLite
É necessário um sistema de banco de dados para guardar as informações de
maneira estruturada. O Android usa o sistema de banco de dados SQLite, que
também é usado por muitas aplicações populares, como o Mozilla Firefox e o iOS
para o armazenamento de dados. Sem ele, os dados ficam disponíveis apenas em
tempo de execução, ou seja, após a execução do programa, esses dados são
perdidos.
Segundo Gonçalves (2014), o SQLite pode ser definido como uma ferramenta - mais
precisamente, uma biblioteca desenvolvida em C padrão (ANSI - American National
Standards Institute) - que pode ser integrada a programas escritos em diferentes
linguagens com o intuito de possibilitar a manipulação de dados através de
instruções SQL. O SQLite é um banco de dados open source. Ele suporta
características de banco de dados relacional, por exemplo, sintaxe SQL, transações
e declarações preparadas. Além disso, requer apenas memória durante o seu tempo
de execução (aproximadamente 250KB).
O autor também diz que, na prática, o SQLite funciona como um “mini-SGBD”, capaz
de criar um arquivo em disco, ler e escrever diretamente sobre este arquivo. O
arquivo criado possui a extensão “*.db” e é capaz de manter diversas tabelas. Uma
tabela é criada com o uso do comando CREATE TABLE da linguagem SQL. Os
dados das tabelas são manipulados através de comandos DML - Data Manipulation
Language - (INSERT, UPDATE e DELETE) e são consultados com o uso do
comando SELECT.
No site do SQLite é possível encontrar roteiros para a utilização da ferramenta em
programas desenvolvidos em Java, PERL, Delphi e outras linguagens (incluindo o
PHP na versão 4).
1.7.C SQLite no Android
De acordo com Vorgel (2010), o SQLite está disponível em todos os dispositivos
com Android. Além das várias inovações implementadas, o Android traz também
suporte nativo para o SQLite.
Usar o banco de dados SQLite no Android não requer nenhuma instalação de banco
de dados ou de administração. É necessário apenas definir as declarações SQL
para criar e atualizar o banco de dados. Depois disso ele é automaticamente
gerenciado por você pela plataforma Android.
1.7.D Características da biblioteca SQLite
Gonçalves (2014) diz que a biblioteca SQLite possui várias características: O
Software é gratuito, multiplataforma e desenvolvido em C padrão (ANSI). Todo o
banco de dados é guardado localmente (junto com a aplicação) em um único
arquivo, que possui a extensão “*.db” . A base de dados pode ter tamanho superior a
2 terabytes.
Ele ainda informa que o SQLite não necessita de instalação, configuração ou de
administração. Suporta também a maior parte do SQL 92, o uso de transações
(COMMIT / ROLLBACK). Seu uso é muito fácil se você estiver programando em
PHP 5 ou C / C++, porém não oferece integridade referencial (chaves estrangeiras).
Suas principais aplicações são: programas locais, sites web, substituto de banco de
dados em aulas ou demonstrações, substitui arquivo texto ou arquivos proprietários.
Não possui dependências externas de outras bibliotecas.
1.7.E Exemplos de uso do SQLite
O autor Gonçalves (2014) explica que o uso do SQLite é recomendado em sites com
menos de cem mil requisições por dia, dispositivos e sistemas embarcados,
aplicações desktop, ferramentas estatísticas e de análise, aprendizado de banco de
dados e também em implementação de novas extensões de SQL.
Seu uso não é recomendado em aplicações com muitos acessos, grande quantidade
de dados (talvez maior que algumas dúzias de gigabytes), sistemas com grande
concorrência e em aplicações cliente/servidor.
Algumas empresas e aplicações famosas que usam o SQLite são: Adobe, Apple
iPhone, iPod Touch e iPad), Dropbox, Firefox, Google (Chrome e Android),
Microsoft, Skype.
1.8 TRANSMISSÃO DE DADOS
Segundo Pirotti e Zuccolotto (2009), o padrão Global System for Mobile
Communication - GSM, que disponibiliza o serviço GPRS como alternativa para
transmissão de dados via celular, é o mais difundido no mundo. Esta tecnologia
utiliza as redes de celulares para o envio de dados. Com o constante aumento da
área de cobertura das redes de telefonia móvel, este tipo de transmissão tende a ser
cada vez mais utilizada.
O padrão de telefonia celular GSM era chamado de Groupe Spéciale Móbile e teve
seu início na Europa, década de 80. O objetivo era ter um novo padrão que
substituísse padrões usados na época. Lançado em 1991, seu nome mudou para
Global System for Mobile Communication. Atualmente se utiliza a nomenclatura de
2.5G, 3G e 4G, que correspondem às recentes implantações do padrão GSM.
A rede de telefonia celular é composta de diversos dispositivos interligados através
de canais de comunicação. Cada dispositivo é responsável por determinadas
funções como enviar um sinal de Rádio Frequência - RF até um telefone celular ou
buscar em uma base de dados informações sobre um usuário.
A arquitetura da rede GSM se subdivide em três subsistemas: Base Station
Subsystem - BSS, que é visto como o sistema da estação rádio base; Network and
Switching Subsystem - NSS, responsável pelo gerenciamento e comutação da rede;
Operations and Maintenance System - OMS que é o subsistema de suporte e
operação.
A comunicação com a rede GSM é feita através de uma estação móvel ou Mobile
station - MS, podendo ser atualmente um celular ou equipamento que suporte a
utilização da rede.
1.8.A Redes GPRS
Com a popularização da telefonia celular, novas necessidades começaram a surgir
como o tráfego de dados através da rede da telefonia celular. A rede ou serviço
GPRS foi implementada para suportar o tráfego de dados utilizando recursos da
rede GSM. Com um acréscimo de equipamentos na rede GSM, o GPRS, além de
permitir a troca de dados e acesso à internet, permitiu que as operadoras de
telefonia móvel utilizassem esta rede para testar e implementar novos serviços, que
seriam aproveitados na implementação da rede 3G (SVERZUT, 2005).
As principais modificações acrescidas na rede GSM foram a unidade de controle de
pacote, que provê as interfaces lógica e física para o tráfego de dados na rede
GPRS, o servidor do nó de suporte GPRS ou Serving GPRS Support Node - SGSN,
que prevê o acesso dos terminais GPRS à rede GPRS e o Gateway GPRS Support
Node - GGSN que têm como principais funções a manutenção das informações de
roteamento, mapeamento de endereços de rede e assinantes e mapeamento de
classes de qualidade de serviços. A Figura 1 demonstra a rede GSM acrescida da
rede GPRS.
Figura 1 – Rede GSM acrescida da rede GPRSFonte: Pirotti e Zuccolotto (2009, p. 84).
Os terminais GPRS são equipamentos capazes de utilizar os serviços da rede
GPRS. Eles possuem o hardware para a comunicação de rádio frequência, além de
suporte à rede GSM.
Uma das características da rede GPRS é que a cobrança deste serviço é feita por
pacotes de dados transmitidos e não por tempo de conexão e seu custo varia de
acordo com a operadora de telefonia utilizada e o plano escolhido.
3 DESENVOLVIMENTO DO SISTEMA
Neste capitulo serão informadas características técnicas do sistema proposto, suas
descrições, apresentação dos requisitos funcionais e não funcionais, diagramas de
classe e casos de uso, bem como seu modelo de entidade relacionamento.
No decorrer do desenvolvimento deste trabalho, será usada a metodologia de
desenvolvimento Praxis para melhor compreensão das etapas. A sigla Praxis
significa processo para aplicativos extensíveis interativos, refletindo uma ênfase no
desenvolvimento de aplicativos gráficos interativos, baseados na tecnologia
orientada a objetos (FILHO, 2005). O Praxis vem propor um ciclo de vida composto
por fases que produzem um conjunto precisamente de artefatos, como modelos,
códigos, testes, planos e relatórios.
2.1 LEVANTAMENTO DE INFORMAÇÕES
Este trabalho contempla aspectos que visam melhorar o planejamento e
gerenciamento do transporte público através de uma ferramenta móvel de
rastreamento e monitorização de ônibus que utilize as tecnologias GPS e GPRS.
O sistema, inicialmente, tem funcionalidades de efetuar a localização de ônibus
durante seu trajeto. Ele utiliza a tecnologia GPS para localização de cada veículo e a
tecnologia GPRS para o envio de dados. O GPS é instalado através de um aparelho
que suporta as tecnologias GPS, GPRS. Este aparelho (dispositivo com sistema
Android como S.O.) permite o envio da localização, dando como resposta a sua
latitude, longitude e código do veículo. O sistema de envio é feito através do uso da
tecnologia GPRS que utiliza um SIM Card para se conectar à internet. Tais
funcionalidades são programadas em Java para plataforma Android. Conforme cada
aparelho ligado ao ônibus envia a sua localização de minuto a minuto ao servidor, o
sistema recebe esses dados e atualiza seu banco sempre que novas informações
chegam. O sistema montará um mapa indicando a localização de cada veículo em
seu trajeto, mostrando inclusive uma média de tempo para sua chegada ao ponto
que o usuário se encontra. Também é possível ao administrador do sistema
consultar informações sobre o cadastro de ônibus como por exemplo tempo médio
de atraso de casa veículo.
Com este sistema se espera uma melhora no planejamento e conforto do usuário e
um aumento na utilização do transporte público.
2.2 ESPECIFICAÇÃO
A seguir serão representados os Requisitos Funcionais - REQF, os Não Funcionais -
REQNF, casos de uso – CU, diagrama de casos de uso, fluxo de atividades, Modelo
de Entidade Relacionamento- MER e o diagrama de classes do módulo de
recebimento de dados Android (celular ou tablet do usuário).
2.2.1 Requisitos Funcionais
Requisitos Funcionais Principais Caso de Uso
REQF01: A aplicação permite ao
usuário, visualizar todos os veículos
cadastrados no servidor.
CU01
REQF02: A aplicação permite ao
usuário verificar qual ponto de ônibus
mais próximo ao seu local atual para
determinado itinerário.
CU02
REQF03: A aplicação informa ao
usuário quando o veículo se encontra
nas proximidades do ponto escolhido
para embarque.
CU03
REQF04: A aplicação permite que o
usuário escolha qual veículo quer
rastrear.
CU04
REQF05: A aplicação requer permissão
do usuário para acessar dados do GPS
do aparelho.
CU05
REQF06: A aplicação permite receber a
localização do ônibus através de
sistema GPRS.
CU06
REQF07: A aplicação permite
rastreamento, mesmo se usuário não
possuir GPS próprio, porém CU2, CU3
ficam desativados.
CU07
REQF08: A aplicação utiliza API Google
Maps para mostrar dados no mapa
CU08
Figura 2 Requisitos funcionais principais.Fonte: PRÓPRIA. 2014
2.2.2 Requisitos Não Funcionais
Requisitos Não Funcionais (REQNF)
REQNF01: A aplicação deve utilizar a tecnologia GPS.
REQNF02: A aplicação deve utilizar tecnologia GPRS / GSM
REQNF03: A aplicação deve utilizar a linguagem Android Java
Figura 3 Requisitos Não funcionais.Fonte: PRÓPRIA. 2014
2.2.3 Diagrama de Casos de Uso
Na Figura 4, apresenta-se o diagrama de caso de uso de Rastreamento onde o ator
usuário possui o módulo Android de recepção de dados diretamente do servidor que,
por sua vez, é alimentado pelos aparelhos instalados em cada veículo. O usuário, ao
ter acesso à internet, verifica uma lista de ônibus disponíveis para o rastreamento e,
ao selecionar algum, é requerido o acesso ao GPS interno do seu aparelho celular.
Caso o usuário dê permissão, outras funções são mostradas. Caso contrário,
apenas poderá ver a posição do veículo e não terá acesso à funções de distância,
tempo médio de espera ou ponto de ônibus mais próximo à sua posição em relação
à do veículo.
Figura 4 – Caso de uso de rastreamentoFonte: PRÓPRIA. 2014
2.2.4 Diagrama de Atividades
A figura 5 contém o diagrama de atividades que representa o processo de
atualização da localização do veículo selecionado. O processo se inicia por obter e
enviar a localização do ônibus pelo aparelho GPS, através do GPRS até o servidor.
O módulo usuário então verifica junto ao servidor as novas coordenadas e atualiza a
tela do dispositivo com os novos dados. Isso é feito de minuto a minuto. Se o
aparelho do usuário possui GPS, funções que envolvem sua atual posição são
desbloqueadas.
Figura 5 – Diagrama de atividades de atualização de posiçãoFonte: PRÓPRIA. 2014
2.2.5 Modelo Entidade Relacionamento
A Figura 6 apresenta o modelo entidade-relacionamento no qual estão as tabelas
que são persistentes no banco de dados utilizado pela aplicação módulo cliente para
receber os dados e pelo módulo ônibus para gravar os dados.
Figura 6 – Modelo de entidade e relacionamentoFonte: PRÓPRIA. 2014
A seguir é apresentada uma breve descrição das entidades para o desenvolvimento
da aplicação:
a) Ônibus: entidade responsável por armazenar o código do veículo, bem como
a rota que ele faz diariamente, incluindo as latitudes e longitudes que são
atualizadas de minuto a minuto pelo módulo ônibus através de das
tecnologias GPRS/GSM e GPS. Um ônibus possui apenas uma rota.
b) Rotas: essa entidade armazena um código que serve de parâmetro para a
entidade ônibus na coluna rotas. Ela armazena ainda um índice para os
pontos de ônibus distribuídos em seu percurso. A entidade pode possuir
vários ou, no mínimo, um veículo que a perfaz e ainda possuir vários ou, no
mínimo, um ponto de ônibus em seu trajeto.
c) Pontos: entidade responsável pelo armazenamento das coordenadas
geográficas dos pontos de ônibus das rotas. Ela pode ter muitas ou, no
mínimo, uma rota.
2.3 IMPLEMENTAÇÃO
A seguir serão mostradas as técnicas e ferramentas utilizadas e a operacionalidade
da implementação.
2.3.1 Técnicas e ferramentas utilizadas
Para o desenvolvimento do sistema foi utilizada a ferramenta Eclipse adaptada com
Android Developer Tools -ADT em sua versão: v22.3.0-887826. O Eclipse
possibilitou codificar os módulos ônibus e usuário dando suporte a erros e sugestões
de solução na linguagem de programação. A figura 7 demonstra essa ferramenta.
Figura 7 – Tela da ferramenta Eclipse ADTFonte: PRÓPRIA. 2014
Como gerenciador de banco de dados foi utilizado o PHPMyAdmin, que permite
administrar dados do banco MySQL. A figura 8 demostra essa ferramenta.
Figura 8 – Tela da ferramenta PHPMyAdminFonte: PRÓPRIA. 2014
Para implementar o WebServer, que contém o banco de dados MySql, foi feito um
plano de hospedagem na empresa UolHost com servidor Linux, onde foram
desenvolvidas páginas Hypertext Preprocessor - PHP para receber e transmitir
informações do banco aos módulos ônibus e usuário. Estes módulos apenas
conseguem se comunicar com o banco através de retornos das páginas php, pois
Android até o momento da elaboração deste trabalho não suporta conexão com
outros bancos nativamente que não seja o SQLite. Devido a essa limitação optou-se
por esse tipo de transação de dados entre os módulos ônibus, usuário e o servidor
(GOOGLE, 2014).
Através do acesso e passagem de parâmetros por uma Uniform Resource Locator -
URL nesse servidor, o módulo ônibus informa seu código, latitude e longitudes
correntes. O servidor retorna ao módulo uma resposta string positiva (caso a
inserção ao banco tenha sido realizada com sucesso) ou negativa (caso contrário).
Na figura 9 é mostrado um trecho do código PHP do servidor que é responsável pelo
cadastramento das coordenadas.
Figura 9 – Trecho de código PHP. Cadastro de CoordenadasFonte: PRÓPRIA. 2014
O aparelho utilizado para enviar os dados referentes ao veículo foi um celular da
marca Samsung modelo Galaxy Ace modelo S5830 com sistema Android Froyo
versão 2.3.6 que possui sistema GPS integrado, além de tecnologia GPRS que é
requisito para a implementação do sistema. Neste aparelho foi instalado o módulo
ônibus que, como já mencionado, é responsável pelo envio de coordenadas
geográficas para um webser através da passagem de paramentos ao acessar
determinada url presente no servidor.
O módulo usuário foi instalado em um tablet da marca Motorola modelo Xoom II
Media Edition MZ608 com sistema Android versão 4.0.4 que também possui serviço
embutido de GPS, GPRS e Wifi. As APIs do Google Maps, elaboradas para esta
plataforma, também foram utilizadas para desenhar na tela o local, em tempo real,
onde o veículo se encontra, no mapa.
2.4 OPERACIONALIDADE DA IMPLEMENTAÇÃO
Na tela inicial exibida pela aplicação módulo usuário são exibidos 4 botões, dos
quais nos atentaremos a falar sobre as principais funcionalidades. Logo destaca-se
o botão Buscar Ônibus. A figura 10 demostra essa tela.
Figura 10 – Tela inicial módulo usuário.Fonte: PRÓPRIA. 2014
Ao selecionar o botão Buscar Ônibus a aplicação verifica se o usuário possui acesso
à internet e, caso retorne verdade, será redirecionado para uma segunda tela onde,
através do acesso a uma url é retornada pelo servidor a lista de veículos
cadastrados. Na figura 11 podemos ver um trecho do código Java, responsável pela
requisição, junto ao servidor, de todos os ônibus cadastrados.
Figura 11 – Trecho de código que faz requisição ao servidorFonte: PRÓPRIA. 2014
Como se pode observar, é passado um paramento string contendo a url, que retorna
uma lista com os códigos dos ônibus cadastrados para uma classe chamada
HttpGetAsync. Esta classe estende outra classe denominada AsyncTask que
contém métodos e rotinas que efetuam todo o processo em segundo plano,
prevenindo o travamento de tela do telefone, o que causa desconforto ao usuário
tendo em vista que, quando se trata de requisições HTTP, muitos problemas podem
ocorrer como demora na resposta do servidor, serviço indisponível, etc. Ao receber a
resposta do servidor ela deve ser tratada pois foi incluída nela algumas estruturas
para divisão dos dados no momento da consulta ao banco. Por exemplo,
suponhamos que o sistema tenha 3 ônibus cadastrados. Em retorno a essa consulta
por url, o servidor envia o seguinte formato de resposta: 0001#0002#0003#^. Isso foi
necessário diante da incapacidade do Android promover consultas a bancos remotos
como foi dito antes. Assim, tivemos que tratar a resposta de forma a poder trabalhar
com elas separadamente dentro de uma estrutura de lista como o código mostrou
em um laço de repetição. Com a lista pronta podemos preencher uma tabela visível
ao usuário denominada ListView e adicionamos um evento OnToutch nesta lista que
dispara um método onde serão requisitadas as coordenadas geográficas do veículo
selecionado e, enfim, mostrar na tela, juntamente com API do Google Maps, um
ícone caracterizando a real posição daquele ônibus no intervalo de tempo de 1
minuto. A figura 12 demonstra a tela de escolha do veículo.
Figura 12 – Tela de escolha do veículo a ser rastreadoFonte: PRÓPRIA. 2014
Ao escolher o veículo desejado por toque na lista ou por busca no campo indicado
acima da lista, um método é disparado, o qual chama uma nova activity contendo a
API Google Maps e a chamada de uma outra url que busca no servidor as
respectivas coordenadas do ônibus. Manipulando os objetos ofertados por essa API
é possível desenhar um ícone na exata posição geográfica que será retornada por
essa nova consulta ao servidor. A seguir, na figura 13, um trecho do código
demostra como é feito o desenho deste ícone a partir das coordenadas retornadas.
Figura 13 – Código que busca as coordenadas e desenha na tela.Fonte: PRÓPRIA. 2014
Em posse dos pontos cardeais retornados a figura 13 demonstrou como marcar um
ponto no mapa ao mesmo tempo em que aplica um zoom e um movimento da
câmera para sempre acompanhar o veículo a medida que se move pela sua rota. Foi
usado uma thread para executar essas funções que, de 5 em 5 segundos, atualiza
as informações do veículo caso essas estiverem sendo atualizadas naquele
momento. Em seguida a figura 14 é demonstrada tela que mostra o ônibus
desenhado no mapa.
Figura 14 – Demonstração de desenho do veículo no mapaFonte: PRÓPRIA. 2014
Caso o módulo usuário possua sensor GPS integrado ao seu aparelho celular
Android, além de visualizar o ônibus no mapa, também é demonstrada a sua
posição. Na figura 14 isso é demostrado com o pequeno ícone próximo ao canto
inferior esquerdo (círculo em azul). Com base nessa informação, implementou-se
outra função que detecta quando o veículo desejado estra em um raio próximo ao
raio em que se encontra o usuário, alertando-o sobre a aproximação do ônibus
selecionado. A figura 15 exemplifica essa situação na qual simulamos um veículo
apenas para demostrar as possibilidades de implementação que essa API nos
proporciona. O procedimento é funcional e aqui iremos simular uma distância de 100
metros entre o usuário e o veículo.
Figura 15 – Demonstração de alerta de aproximação de veículo.Fonte: PRÓPRIA. 2014
Assim que o raio de 100 metros do ponto de origem do ícone “ÔnibusSimulado”
entrou em contato com o ícone que representa a posição atual do usuário, um alerta
foi disparado, informando que o veículo simulado está próximo. O raio aqui foi
definido em 100 metros mas o usuário pode definir sob medida, dependendo de
suas necessidades, como por exemplo 1 quilômetro ou 100 quilômetros. Essa
técnica foi desenvolvida de modo que funcione mesmo que o aparelho esteja em
modo de espera, livrando o usuário de verificar constantemente seu celular para
conhecer a posição do veículo esperado. Para avisá-lo, foram implementados avisos
sonoros e vibratórios, além da total execução, em segundo plano, por meio de
threads e services.
4 CONSIDERAÇÕES FINAIS
O aumento significativo da população fomenta problemas conhecidos atualmente,
tais como congestionamentos de veículo, falta de infraestrutura apropriada ao
tráfego constante, além dos atrasos nos serviços de transporte público. Uma cidade
inteligente deve utilizar, de forma eficiente, tecnologias para tentar diminuir ou sanar
esses problemas.
Por esse motivo, neste trabalho foi realizado um estudo de viabilidade tecnológica e
bibliográfica para a elaboração de um sistema para plataformas móveis que seja
capaz de monitorar, em tempo real, a posição geográfica dos ônibus do transporte
coletivo. Com isso, tenta incentivar, de forma indireta, o uso de ônibus para a
locomoção em cidades de médio porte pois, para tanto, deve-se melhorar a
experiência dos usuários neste sistema de locomoção.
Para cumprir este objetivo, são utilizados sistemas GPS, GPRS e tablets ou
smarthphones, em que, através do GPS, um banco de dados é povoado
constantemente com as posições geográficas de cada veículo em transito. Esse
povoamento é feito utilizando-se a tecnologia GPRS, que faz a comunicação entre
os sistemas instalados nos ônibus e o servidor de banco que, por sua vez,
disponibiliza os dados recebidos para os dispositivos móveis dos usuários que,
através da API do Google Maps, visualizam em tempo real a posição dos veículos e
o tempo médio para sua chegada até determinado ponto.
Os estudos mostraram que realmente é possível o desenvolvimento de sistema de
monitoração e, ainda, a um baixo custo sendo que, para sua implementação, não
seria necessária a distribuição de redes ou sensores por toda a cidade, tendo em
vista que, apenas os veículos a serem monitorados é que devem conter um módulo
que resgate sua posição GPS e transmita via GPRS, tecnologia que já está bem
disseminada em um grande número de cidades.
A documentação das APIs do Google Maps e Android disponibilizada pelo Google
para desenvolvedores oferece grande facilidade para implementação da ferramenta,
ainda que em inglês, sempre está atualizada e serve de suporte aos programadores.
Utilizando as tecnologias atuais de GPRS e com o GPS notou-se que é possível
manter um banco de dados atualizado sobre as reais posições dos veículos nas
cidades. Porém, na cidade onde testamos a aplicação (Montes Claros-MG), a
performance da rede GSM da operadora contratada mostrou-se ineficaz com vários
pontos sem acesso à rede, o que culminou na não atualização dos dados. Porém,
com uma simples substituição de operadora o problema foi sanado.
Os servidores que prestaram serviços para a aplicação em vários momentos
demonstraram atrasos para exibição dos dados e, com relação a este quesito,
recomenda-se uma pesquisa a fim de determinar quais os servidores mais eficientes
para a realização deste tráfego de dados, uma vez que, para este trabalho não
foram utilizados serviços mais dedicados. Recomenda-se ainda a verificação da
possibilidade de implementação deste trabalho não apenas para plataformas
móveis, mas também a construção de um website com as mesmas ou até mais
funcionalidades do módulo usuário, descrito no capítulo anterior, tendo em vista que
ainda existe uma grande parcela de potenciais clientes para o sistema que ainda
não possui computadores móveis.
Do ponto de vista acadêmico, esse trabalho se mostrou de suma importância para a
formação do autor, tanto pelo lado do conhecimento quanto profissional, pois a
programação para plataformas móveis está em ascensão e a junção das tecnologias
de sensores eletrônicos como sensor GPS, sensor de gases, luminosidade, etc.,
com essas plataformas constitui um grande leque de opções para o
desenvolvimento de outros projetos ou trabalhos científicos com os mais variados
focos, sejam eles de cunho ambiental, acadêmico, econômico etc.
REFERÊNCIAS BIBLIOGRÁFICAS
ABC71, Perspectiva (Org.). Da guerra ao cotidiano: conheça a história do GPS. Disponível em: <http://www.abc71.com.br/boletim/2009/02/materia_03.html>. Acesso em: 08 abr. 2014.
DEPARTAMENT OF DEFENCE, United States of America, Global Positioning System Standard Positioning Service (2008), 4th ed.
EDUARDO JÚNIOR,; SEGUNDO, Alonso. Histórico dos Bancos de Dados. Disponível em: <http://disciplinas.dcc.ufba.br/svn/MATA60/tarefa1/historico/historico.pdf?revision=21> Acesso em: 20 abr. 2014.
FILHO, Wilson de Pádua Paula. Engenharia de Software: Fundamentos, Métodos e Padrões. 2 Ed. Rio de Janeiro: LTC, 2003.
GONÇALVES, Eduardo Corrêa. SQLite, Muito Prazer! Disponível em: <http://www.devmedia.com.br/SQLite-Muito-Prazer/7100>. Acesso em: 08 abr. 2014.
GOOGLE INC.. What is Android? Disponível em: <http://developer.android.com/guide/basics/what-is-android.html>. Acesso em: 08 abr. 2014.
GOOGLE INC.. Android 4.1 – Jelly Bean. Disponível em: <http://www.android.com/about/jelly-bean>. Acesso em: 18 abr. 2014.
GIL, Antônio Carlos. Como elaborar projetos de pesquisa. 4. ed. São Paulo: Atlas, 2008
MONICO, J.F.G. Posicionamento Pelo GNSS: Descrição, Fundamentos e Aplicações (Unesp, São Paulo, 2008).
MORIMOTO, Carlos E.. Smartphones: Guia Pratico. São Paulo: Gdh Press e Sul Editores, 2009. 432 p.
ORACLE. The History of Java Technology. Disponível em: <http://www.oracle.com/technetwork/java/javase/overview/javahistory-index-198355.html>. Acesso em: 10 abr. 2014. ORACLE. About the Java Technology. Disponível em: <http://docs.oracle.com/javase/tutorial/getStarted/intro/definition.html>. Acesso em: 10 abr. 2014. ORACLE. The Java Virtual Machine. Disponível em: <http://docs.oracle.com/javase/specs/jvms/se7/html/jvms-1.html>. Acesso em: 10 abr. 2014.
PIKE, John E. (Ed.). Navigation Technology Satellite. Disponível em: <http://www.globalsecurity.org/space/systems/timation.htm>. Acesso em: 11 abr. 2014.
PIROTTI, Rodolfo, P.; ZUCCOLOTTO, Marcos. Transmissão de dados através da telefonia celular: arquitetura das redes GSM e GPRS. Revista Liberato. v.10. n.13. p.81-89. Novo Hamburgo. jun. 2009. Disponível em: <http://www.liberato.com.br/upload/arquivos/0116070910470919.pdf>. Acesso em: 17 abr. 2014.
PRADO, Jean. A História do Android. Disponível em: <http://diariodoandroid.com.br/infografico/infografico-historia-android/7812/> Acesso em: 22 abr 2014.
THE WHITE HOUSE, Global Positioning System Policy, Office of Science and Technology Policy. National Security Council Embargoed for Release on March 29, 1996. Disponível em: <http://www.navcenter.org/gps/geninfo/default.htm >. Acesso em: 15 Abr 2014.
TAURION, CEZAR. Tecnologia, uma opção inteligente para melhorar a vida urbana. Disponível em: <http://www.portal2014.org.br >. Acesso em: 15 Nov 2013.
VORGEL, Lars. Android SQLite Database and ContentProvider – Tutorial. Disponível em <http://www.vogella.com/articles/AndroidSQLite/article.httml>. Acesso em: 18 Abr. 2014.
SVERZUT, José Umberto. Rede GSM, GPRS, EDGE e UMTS. São Paulo: Editora Afiliada, 2005.