Trabalho de Graduação apresentado em 2012 na FATEC de São José dos Campos

1. FACULDADE DE TECNOLOGIA DE SÃO JOSÉ DOS CAMPOS
FATEC PROFESSOR JESSEN VIDAL
PEDRO HENRIQUE DE OLIVEIRA SILVA
GOV2GO UM APLICATIVO ANDROID PARA PREFEITURAS
UTILIZANDO O CONCEITO DE M-GOVERNMENT
São José dos Campos
2012

2. PEDRO HENRIQUE DE OLIVEIRA SILVA
GOV2GO UM APLICATIVO ANDROID PARA PREFEITURAS
UTILIZANDO O CONCEITO DE M-GOVERNMENT
Trabalho de Graduação apresentado à
Faculdade de Tecnologia São José dos
Campos, como parte dos requisitos
necessários para a obtenção do título de
Tecnólogo em Banco de Dados.
Orientador: Ms. Eduardo Sakaue
São José dos Campos
2012

3. Dados Internacionais de Catalogação-na-Publicação (CIP)
Divisão de Informação e Documentação
SILVA, Pedro Henrique de Oliveira
Gov2Go Um Aplicativo Android para Prefeituras Aplicando o Conceito de M-Government
São José dos Campos, 20012.
56f.
Trabalho de Graduação – Curso de Tecnologia em Informática com
Ênfase em Banco de Dados, FATEC de São José dos Campos: Professor Jessen Vidal, 2012.
Orientador: Titulação Eduardo Sakaue.
1. Áreas de conhecimento. I. Faculdade de Tecnologia. FATEC de São José dos Campos:
Professor Jessen Vidal. Divisão de Informação e Documentação. II. Título
REFERÊNCIA BIBLIOGRÁFICA –
Silva, Pedro Henrique de Oliveira. Gov2go Um Aplicativo Android Para Prefeituras
Aplicando o Conceito de M-Government. 2012. 56f. Trabalho de Graduação - FATEC de
São José dos Campos: Professor Jessen Vidal.
CESSÃO DE DIREITOS –
NOME DO AUTOR: Pedro Henrique de Oliveira Silva
TÍTULO DO TRABALHO: Gov2Go Um Aplicativo Android para Prefeituras Aplicando o
Conceito de M-Government
TIPO DO TRABALHO/ANO: Trabalho de Graduação / 2012.
É concedida à FATEC de São José dos Campos: Professor Jessen Vidal permissão para
reproduzir cópias deste Trabalho e para emprestar ou vender cópias somente para propósitos
acadêmicos e científicos. O autor reserva outros direitos de publicação e nenhuma parte deste
Trabalho pode ser reproduzida sem a autorização do autor.
______________________________________________
Pedro Henrique de Oliveira Silva
Rua Rosário, 66, Jardim América
CEP 12.236-420 – São José dos Campos – São Paulo

4. 4
Pedro Henrique de Oliveira Silva
GOV2GO UM APLICATIVO ANDROID PARA PREFEITURAS
APLICANDO O CONCEITO DE M-GOVERNMENT
Trabalho de Graduação apresentado à
Faculdade de Tecnologia São José dos
Campos, como parte dos requisitos
necessários para a obtenção do título de
Tecnólogo em Banco de Dados.
___________________________________________________________________
Antônio Egydio São Thiago Graça, Ms. FATEC Jessen Vidal São José dos Campos
__________________________________________________________________
Reinaldo Gen Ichiro Arakaki, Dr., FATEC Jessen Vidal São José dos Campos
__________________________________________________________________
Eduardo Sakaue, Prof. Ms. FATEC Jessen Vidal São José dos Campos
_____/_____/_____
DATA DA APROVAÇÃO

5. 5
Aos meus Pais, Carlos Noel da Silva e
Rosângela Cristina de Oliveira Silva que
contribuíram muito para minha formação e
educação.

6. 6
AGRADECIMENTOS
Agradeço ao professor e orientador Eduardo Sakaue, pelo apoio e encorajamento
contínuos na pesquisa, aos demais professores, pelos conhecimentos transmitidos ao longo
do curso, a minha família, Carlos Noel da Silva, Rosângela Cristina de Oliveira Silva e Paulo
Caio de Oliveira Silva, pela contribuição na minha formação. A minha noiva Tais Monique
Vieira Gonçalves, por estar ao meu lado em todos os momentos desde o início do curso.
Aos colegas, Jonatas Zanin, Paulo Luan e Leandro Evaristo pela cobrança e por
compartilhar seus conhecimentos ao longo desta jornada.
Agradeço ainda a todos que contribuíram de forma direta ou indireta para a conclusão
deste trabalho e do curso como um todo. Muito Obrigado.

7. 7
“Don’t Panic - Não entre em Pânico”. Douglas
Adams

8. 8
RESUMO
Em cidades com um grande contingente de população e uma área demasiadamente grande, a
detecção de problemas se torna algo muito custoso. Hoje muitos municípios ainda enfrentam
o problema de comunicação e de contato com os moradores, uma vez que existem muitos
munícipes em uma cidade, tornando a detecção de problemas algo muitas vezes difícil e que
demanda um grande tempo dos empregados responsáveis pela fiscalização. Por tais motivos
este trabalho visa melhorar o contato dos cidadãos com seus governantes e buscar garantir que
os problemas encontrados sejam solucionados de uma maneira mais rápida e dinâmica,
utilizando para tal de métodos do M-Government aplicado a dispositivos móveis.
Palavras-Chave: Governo Móvel; M-Government; Android; Dispositivos Móveis.

9. 9
ABSTRACT
In cities with a great number of people and whose area is too large, the detection of problems
gets very hard. Nowadays many cities still face communication and contact problems with its
locals since they have many residents. Therefore, detecting problems becomes something
difficult and that requires a lot of time from the responsible ones for the monitoring. For these
reasons, this paper aims to improve the contact between citizens and their government, and it
also has the objective of ensuring that the problems that were found can be solved in a faster
and more dynamic way by using M-Government methods for mobile devices.
Keywords: M-Government; Android; Mobile Devices.

10. 10
SUMÁRIO
1- INTRODUÇÃO 11
1.1-Motivação 11
1.2- Objetivos 12
1.2.1- Objetivo Geral 12
1.2.2- Objetivos Específicos 12
1.3- Metodologia 13
1.4- Organização do Trabalho 14
2- FUNDAMENTAÇÃO TEÓRICA 15
2.1- Evolução dos dispositivos móveis 15
2.2- Sistemas Operacionais de Dispositivos Móveis 16
2.2.1- O Android 18
2.3- Tomcat 22
2.4- RESTful 22
2.5- JSON 22
2.6- Web Services 23
2.7- Cliente x Servidor 23
2.8- JSF – JavaServer Faces 24
2.9- Hibernate 25
2.10- M-Government 25
3- PROPOSTA DE SOLUÇÃO 30
3.1- Arquitetura Global 30
3.2- Cliente Móvel 32
3.2.1- Segurança do Cliente Móvel 34
3.3- Cliente Web 34
3.4- Servidor 36
3.4.1- Comunicação Cliente X Servidor 36
3.5- Arquitetura de Banco de Dados e Persistência de Objetos 37
4- ESTUDO DE CASO E RESULTADOS: GOV2GO 39
4.1- Cenário Atual 39
4.2- Proposta de Solução 42
4.2.1- Interface Móvel 43
4.2.2- Interface Web 46
4.2.3- Servidor 48
5- CONSIDERAÇÕES FINAIS 50
5.1- Contribuições e Conclusões 50
5.2- Trabalhos Futuros 50
6- REFERÊNCIAS 52

11. 11
1- INTRODUÇÃO
1.1- Motivação
A participação do cidadão é a parte mais importante na construção de uma sociedade
mais democrática e atuante sobre os poderes políticos, onde existe a integração em ambas as
partes, ou seja, governantes e governados trabalhando de uma forma uníssona para o
desenvolvimento exponencial de um povo.
Dada a importância do cidadão trabalhar em conjunto com o governo para o
desenvolvimento de um sociedade mais democrática, nasce o Gov2Go. A proposta do
Gov2Go é colocar o cidadão para fiscalizar o seu governo, o processo é simples, quando uma
irregularidade é encontrada, a pessoa pode por meio de seu dispositivo móvel enviar uma
foto, a localização e uma descrição do ocorrido para a prefeitura ou órgão fiscalizador.
Outro fator motivador para o desenvolvimento do projeto é o crescimento demasiado
dos centros urbanos e da população de uma forma geral, podemos destacar como exemplo a
cidade de São José dos Campos/SP, que possui cerca de 630 mil de habitantes (Censo, 2010),
e uma área total de aproximadamente 1,100 km2 tornando o trabalho de fiscalização para a
prefeitura e empresas terceirizadas, de certa forma árdua e lenta, já que existe uma grande
área de cobertura para fiscalizar.
Para ajudar nesta fiscalização, podemos utilizar de dispositivos móveis. Os
dispositivos móveis são equipamentos que podem funcionar como um computador compacto,
que pode ser levado dentro de um bolso ou de uma bolsa. Temos como exemplos de
dispositivos móveis: Smartphones, Telefones Celulares, Televisão portátil, PDAs, Tablets
entre outros.
Estima-se que hoje existam mais de 19 milhões de Brasileiros que possuem
dispositivos móveis, e que desses 19 milhões, 40,8% fazem uso da internet pelos celulares.
Estima-se ainda que, 35% dos aparelhos são da empresa de telefonia móvel Nokia, 17,8% são
aparelhos da Samsung, e apenas 9,8% dos brasileiros usam aparelho advindos do sistema
operacional da Apple, o iPhone. (Instituto Ipsos Mediact, 2011).

12. 12
Figura 1 – Crescimento anual de assinaturas de celulares (ITU, 2011)
Fonte: ITU World Telecommunication /ICT Indicators database (2011)
Conforme ilustra a figura 1, a assinatura de dispositivos móveis cresce
exponencialmente ano a ano, tendo um crescimento de cerca de 600 milhões de novas
assinaturas por ano.
Unindo as questões sociais, governamentais e de fiscalização, com as novas
tecnologias mobile emergentes surge o conceito do M-Government.
M-Government surge como um conceito novo, sendo ele uma vertente do chamado E-Government
(Eletronic Government), que são os serviços e utilidades públicas
disponibilizadas aos cidadãos por meio eletrônicos, como telefones, computadores conectados
a internet, rádios entre outros dispositivos eletrônicos.
Em contra partida temos o conceito de M-Government do inglês Mobile Government,
que partilha dos mesmos objetivos do E-Government, porém utilizando dispositivos mobile
para tal, como Smartphones, Tablets, celulares entre outros.
1.2- Objetivos
Serão mostrados a seguir o objetivo geral e específico do projeto.
1.2.1- Objetivo Geral
Este trabalho propõe apresentar novos paradigmas e conceitos emergentes de E-Government
e M-Government com a finalidade de mostrar os benefícios que a tecnologia
mobile tem a oferecer, para que os setores públicos e a população possam trabalhar de uma
forma conjunta, desenvolver um ambiente web para controle das ocorrências e também

13. 13
desenvolver um ambiente para dispositivos móveis com a finalidade de fiscalização para
municípios, seguindo os princípios do M-Government.
1.2.2- Objetivos Específicos
O desenvolvimento deste projeto possui os seguintes objetivos específicos:
a. Apresentar os ambientes e ferramentas utilizados;
b. Pesquisar trabalhos relacionados à M-Government;
c. Realizar um estudo sobre o local que será aplicado o ambiente
desenvolvido;
d. Desenvolver um ambiente web básico, para controle de ocorrências.
e. Desenvolver um aplicativo para dispositivos móveis com a
finalidade de fiscalização;
1.3- Metodologia
Foram adotados como padrões para o desenvolvimento desta pesquisa as seguintes
metodologias:
A princípio apresentar para o leitor os conceitos básicos e avançados sobre toda a
gama que envolve os dispositivos móveis e ferramentas que serão utilizados na realização do
trabalho de graduação, desde o seu conceito fundamental, passando por sua arquitetura e por
suas especificações técnicas.
Logo em seguida realizar-se-á uma pesquisa sobre os trabalhos relacionados a este, e
também relacionados a M-Government com a finalidade de apresentar seus conceitos e as
vantagens e possíveis desvantagens de seu uso. Demonstrar também, os cases de sucesso de
projetos com o mesmo conceito.
O passo seguinte será o levantamento dos requisitos necessários para a realização do
trabalho, visando analisar os problemas enfrentados hoje pela sociedade ao entrar em contato
com o governo para reportar uma infração. Também se realizará um estudo do local em que
será aplicado o ambiente desenvolvido.
Após a definição dos requisitos, será projetado o modelo de software para atender as
necessidades e pontos fracos demonstrados durante a definição. Utilizando ferramentas e
metodologias próprias para o desenvolvimento de aplicações para dispositivos móveis serão
criada a estrutura do ambiente proposto.
Por fim o aplicativo será desenvolvido tendo como alicerce o projeto detalhado
anteriormente para que possa ser implantado no local definido, com a finalidade de testar
efetivamente a solução desenvolvida, e se realizar uma conclusão concreta quanto a sua
eficiência, ou seja, se atendeu todos os requisitos necessários.

14. 14
1.4- Organização do Trabalho
Os demais capítulos desse trabalho são:
a) Capítulo 2: Nesta seção serão detalhadas todas as ferramentas utilizadas na
confecção do projeto, o surgimento dos ambientes de dispositivos móveis,
serão mostrado os sistemas operacionais mobiles usados atualmente, dando
ênfase ao sistema operacional mobile Android, e uma introdução ao M-Government.
b) Capítulo 3: O capítulo irá conter as definições do software, bem como as
ferramentas utilizadas para confecção do mesmo, e a arquitetura do projeto.
Aqui será demonstrado a forma que o software será aplicado no local
escolhido.
c) Capítulo 4: Neste capitulo serão analisados os resultados obtidos no decorrer
do trabalho
d) Capítulo 5: O capítulo 6 apresentará as considerações finais do trabalho
realizado.

15. 15
2- FUNDAMENTAÇÃO TEÓRICA
Este Capítulo apresenta os conceitos e ferramentas que serão usados durante todo o
trabalho, desde a evolução da comunicação móvel, passando por Graham Bell, inventor do
telefone em 1876, até os dias atuais, com a modernização do aparelho telefônico, mostrando
também os sistemas operacionais mobiles presentes hoje. Ainda neste capítulo será feito uma
abordagem mais superficial sobre M-Government apresentando para o leitor seus principais
pontos e características.
2.1- EVOLUÇÃO DOS DISPOSITIVOS MÓVEIS
A necessidade de se comunicar mais eficientemente faz com que o ser humano
desenvolva novas tecnologias e técnicas para chegar a esse objetivo, podemos citar como
exemplo, a forma mais antiga de se comunicar: As pinturas rupestres, gravuras feitas em
cavernas no período pré-histórico com a finalidade de representar uma caça, ou o que quer
que seja em forma de desenho, com o intuito de comunicar o ocorrido a seus companheiros.
Dando um salto maior na história, por volta de 1870 nos Estados Unidos, o telégrafo
era a forma mais usada para se comunicar, toda via, apesar de cumprir com seus objetivos, o
telégrafo não era utilizado por grande parte da sociedade, talvez por ser um aparelho com um
nível muito complexo de utilização. (Pampanelli, 2004)
O aparelho telefônico, desde sua criação com Bell, vem sofrendo constantes melhorias
e adaptações para atender a demanda da sociedade ao longo dos anos. Seguindo a história, por
volta de 1940 começou-se o desenvolvimento do primeiro telefone móvel pelas companhias
américa Bell e AT&T. Porém, devido ao seu alto nível de complexidade, esta primeira linha
de celulares só foi colocado em prática de fato no ano de 1983 (AKAIWA, 1997).
Outro meio comumente usado em comunicação e que vem evoluindo juntamente com
o telefone, são os microcomputadores e a internet. Assim como no telefone, viu-se a
necessidade de trazer a mobilidade para os computadores, tornando-os mais flexíveis para
serem usados no dia-a-dia. Partindo deste pressuposto, veio o conceito dos notebooks,
desenvolvidos inicialmente em 1981 por Adam Osborne tinha uma tela de 5” e pesavam cerca
de 12 kg, em contraste com os de hoje que pesam cerca de 2 a 3 kg (TONON, 2006).
As primeiras linhas de computadores portáteis surgiram em 1991 com a empresa HP
(Hewlett-Packard), o modelo lançado na época foi o HP-951 X Palmtop PC. Foi nos anos 90
que houve também a popularização de outros dois tipos de portáteis, o handheld que pode ser
comparados à mini notebooks com teclados e que podem ser facilmente carregados já os
PDAs (Persnonal Digital Assistent) são ainda mais compactos que os handheld mas não
possuem teclados (TONON, 2006).
Até pouco tempo atrás, toda mobilidade que podíamos ter era provindo de notebooks e
PDAs, hoje temos os smartphones e dispositivos móveis de uma maneira geral, como Tablet
entre outros (Oliver, 2009).
A evolução constante da tecnologia móvel cresceu de uma maneira tão rápida que hoje
temos também o conceito dos dispositivos móveis. São considerados dispositivos móveis
todos os aparelhos do universo mobile, tais como SmartPhones, Tablets, PDAs, Celulares,

16. 16
Palmtops, handheld etc. Esses dispositivos possuem uma gama de sistemas operacionais
específicos para ambientes móveis, dentre eles destacam-se: o Android, o iOS, o Windows
Phone, o Symbiam, o Meego entre outros. Esses sistemas serão abordados com mais
profundidade na seção seguinte.
Figura 2 – Sistemas Operacionais Móveis
Fonte: http://npossibilidades.blog.br/w/wp-content/uploads/2009/07/mobile-oss.png (2009)
2.2- Sistemas Operacionais de Dispositivos Móveis
Sistema Operacional faz a ligação entre o hardware e os aplicativos existentes no
computador. É o único programa que esta sempre em execução (SILBERSHARTZ, 2004).
Assim como nos microcomputadores, os dispositivos móveis possuem um sistema
operacional, que basicamente possui as mesmas funções dos Sistemas Operacionais dos
computadores, ou seja, eles fazem essa intermediação entre o usuário e a máquina, tornando o
ambiente de certa forma mais amigável para ele.
Segundo Martins (2009), existem hoje no mercado um grande número de sistemas
operacionais mobile, como por exemplo o iOS, da empresa americana Apple, Windows
Mobile, da também empresa americana Windows, o Symbian da Nokia, BlackBerry OS da
empresa RIM e o WebOS das empresas HP/PALM.
Podemos observar os números da Tabela 1, que indica a quantidade de Smartphones
vendidos por sistema Operacional segundo a CANALYS (2011).

17. 17
Tabela 1 – Mercado de Smartphones em todo o mundo, por Sistema Operacional,
em 2011: Vendas Globais de Acordo com a Canalys
Sistema
Operacional
Vendas
2011
(Milhões)
Vendas
2011
(%)
Android 237.7 48.8%
iOS 93.1 19.1%
Symbian 80.1 16.4%
BlackBerry 51.4 10.5%
Bada 13.2 2.7%
Windows Phone 6.8 1.4%
Outros 5.4 1.1%
Total 487.7 100%
Fonte: Canalys (2011)
Gráfico 1 – Mercado de Smartphones em todo o mundo, por Sistema Operacional
em 2011 (Baseado nas informações da Tabela 1)
O gráfico 1, nos mostra que hoje a grande parte dos dispositivos móveis possuem
como sistema operacional o Android com aproximadamente 49% do mercado, seguido do iOS
que tem cerca de 20% de participação no mercado mobile. Isso ocorre devido ao fato do
Android estar disponível em diversos aparelhos móveis, como a empresa Samsung e LG por
exemplo, já os aparelhos com iOS estão presentes em aparelhos fabricados exclusivamente
pela americana Apple.
Em suma o mercado mobile está recheado com uma gama enorme de sistemas
operacionais que podem ser usados para o desenvolvimento de qualquer aplicativo para tais,
cabe a cada um escolher o que melhor lhe serve. Hoje existem aplicativos para todos esses
sistemas, aplicativos estes relacionados a toda e qualquer área, seja ela médica,
entretenimento como jogos, música e filmes, esportes etc.

18. 18
2.2.1- O Android
O Android é um sistema operacional para dispositivos móveis, inicialmente
desenvolvida pela empresa americana Google. Em 2007 a Google tornou pública a primeira
plataforma Open Source para de desenvolvimento de dispositivos móveis, baseado na
linguagem de programação Java e tendo como base o Kernel Linux. A plataforma é o
principal produto do grupo OHA (Open Handset Alliance), um grupo formado por cerca de 40
empresas de diferentes seguimentos, que se uniram com o objetivo de estabelecer padrões
para a indústria de dispositivos móbiles. (ACKER, 2010)
Figura 3 – Arquitetura do Android
Fonte: http://developer.android.com/images/system-architecture.jpg
A arquitetura do ambiente Android é mostrada na figura 3 [DEV GUIDE, 2012] e suas
camadas são detalhadas a seguir:
• Linux Kernel: O sistema operacional Android tem como base a versão 2.6 do
Kernel Linux. Responsável por gerenciar memória e processos, pilha de rede e
drives. O Kernel também funciona como uma camada de abstração entre o
hardware do dispositivo e o restante de softwares que o compõe;
• Android Runtime: Cada aplicação Android roda em um processo
independente e cada um desses processos possuem uma instancia própria da
máquina virtual Dalvik. O Dalvik nada mais é que uma JVM (Java Virtual
Machine) que foi projeta para consumir a menor parcela de memória possível a

19. 19
fim de que se possa tornar mais eficiente e manter uma boa performance. É
nesta camada que está contida a maior parte das funcionalidades das principais
bibliotecas do JAVA (Core Libraries);
• Libraries: O Android possui uma gama de bibliotecas desenvolvidas em
C/C++ usados para diversos componentes do sistema. Elas permitem trabalhar
com alguns arquivos de mídia como MPEG4, H.264, MP3, AAC, AMR, JPG e
PNG. Possui também a capacidade de trabalhar com imagens tanto 2D como
3D, cuja implementação foi baseada na biblioteca OpenGL. E permite também
trabalhar com componentes de banco de dados, no caso o SQLite, um banco de
dados relacional;
• Application Framework: Nesta camada está as APIs (Application
Programming Interface) do Android que tem por finalidade simplificar a
reutilização de alguns componentes como, por exemplo:
a) Content Provider, que são provedores de conteúdo que permitem
que aplicativos acessem dados de outros aplicativos, como contatos;
b) Notification Manager proveem diferentes tipos de notificações e
alertas para as aplicações;
c) Activity Manager gerencia o ciclo de vida das aplicações dentro do
sistema operacional.
• Applications: Camada que contem todas as aplicações feitas em linguagem
Java, como cliente de e-mail, SMS (Short Message Service), calendário,
mapas, contatos entre outras.
Os aplicativos desenvolvidos para o sistema operacional Android para serem instalado
dentro de um dispositivo móvel é necessário ser compilado e empacotado em um arquivo cuja
extensão é a .apk. No momento que é executado, essa aplicação é descompactada e está
pronta para ser usada pelo usuário.
As aplicações em Android podem ser requisitadas de muitas maneiras, sempre
utilizando componentes (Activity, Services, Content Provider e Broadcast Receivers) que são
instanciados no momento que são requisitados. Os Activity, Services e Broadcast Receivers
funcionam de uma forma assíncrona, ou seja, não são acionadas em um tempo previsto. As
mensagens enviadas por meio desses componentes são denominadas Intents que nada mais é
que as intenções de uma ação requisitada, ou seja uma mensagem enviada no momento em
que se deseja realizar algo dentro do sistema. (DEV GUIDE, 2012)
A tabela 2 dispõem alguns exemplos de Intents nativas do próprio Android. Estas
Intents podem ser usadas para realizar diversas ações em uma aplicação, como por exemplo
ACTION_BATTERY_LOW que emite uma chamada quanto a bateria atinge uma
determinada porcentagem. Com essa constante pode-se por exemplo para uma aplicação
quando receber essa mensagem.

20. 20
Tabela 2 – Exemplo de Intents Nativas do Android
Fonte: DEV GUIDE, 2012.
As Intents são classificadas em duas categorias distintas:
a) Os implícitos: Nas Intents implícitas é o próprio sistema operacional que
escolhe qual o componente que atenderá melhor aquela Intent;
b) Os explícitos: Nas explicitas o componente que será ativado é informado pelo
programador, com antecedência.
As Intents explícitas são usadas apenas para as interações entre os componentes de
uma mesma aplicação, uma vez que se conhece a aplicação facilitando assim o seu uso,
enquanto as implícitas são usadas para usar componentes de outras aplicações, fornecendo
informações para que o Android localize o melhor componente para ser usado.
A Figura 4 ilustra o ciclo de vida de uma Activity no Android, ela segue um ciclo pré-definido
que é executado rigorosamente. Uma Activity é requisitada, criada, executa o que lhe
é pedida e por fim é destruída. Toda Activity passa pelo mesmo ciclo sempre que é
requisitada.

21. 21
Figura 4 – Ciclo de Vida da Activity
Fonte: http://developer.android.com/images/activity_lifecycle.png
2.3- TomCat
O Tomcat foi desenvolvido usando a linguagem de programação JAVA, é um servidor
de aplicações JEE open source, e em seu contexto faz a troca de mensagens entre os clientes,
ou seja, ele faz o recebimento e envio de mensagens nos clientes. O Tomcat fornece suporte à
implementações Java Servlet e JavaServer Pages. (TOMCAT, 2012)

22. 22
2.4- RESTful
O termo REST, representation State Transfer, foi definido pela primeira vez no ano
2000, na tese de doutorado de Roy Fielding. REST é um estilo de arquitetura de software para
mídias distribuídas. Os serviços REST trabalham da seguinte forma: Um serviço REST recebe
uma requisição que diz o processamento que deve ser executado, e retorna uma resposta para
aquela requisição. (FIELDING, 2000)
Em uma arquitetura cliente x servidor, o serviço REST funciona da seguinte forma: O
cliente manda uma requisição para o servidor, este então recebe a requisição e faz o que lhe é
pedido, para logo em seguida enviar uma resposta para o que foi requisitado. A requisição e a
resposta são as representações de um recurso. (FIELDING, 2000) “Um recurso é uma
abstração ou conceito relevante que existe no domínio tratado pelo serviço em questão.”
(Filho; Ferreira, 2009) Os recursos podem receber uma infinidade de requisições e diversos
clientes podem acessá-lo.
O cliente deve conhecer o apenas o formato de retorno da resposta pelo servidor e
também o endereço do recurso, e não o recurso propriamente dito com os detalhes do
processamento. Os formatos de retorno podem ser: XML, XHTML, JSON, RDF, entre outros.
As ações a serem executadas são definidas pelo protocolo HTTP, este protocolo
oferece cinco métodos principais, são eles: GET, HEAD, POST, PUT e DELETE. Todos os
métodos são aplicados nos recursos.
Hoje existe no mercado uma infinidade de ferramentas que ajudam a implementar o
RESTful em JAVA, como Jersey (JERSEY, 2012) e RESTEasy da JBOSS. (JBOSS, 2012)
Temos também grandes empresas que oferecem seus serviços usando RESTful, como as
empresas Google, Yahoo e o Twitter.
2.5- JSON
JSON, acrônimo para JavaScript Object Notation, é um formato leve para troca de
informações em computação. O JSON foi descrito pela primeira vez por Douglas Crockford e
é descrito no rfc4627. (RFC4627, 2006)
Uma das grandes vantagens do JSON é ser fácil de ler e escrever para humanos e fácil
de interpretar e gerar, para as máquinas. JSON é em formato texto e completamente
independente de qualquer linguagem, já que usa convenções que são familiares a todas as
linguagens. (JSON, 2012)
Um objeto JSON pode ser construído de duas maneiras:
1. Uma coleção de pares nome/valor, como no exemplo: { “idade”: 19, “sexo”:
“masculino” }
2. Uma lista ordenada de valores, também conhecido como vetor. Podemos ver
um exemplo: { “Aluno” : [ { “nome” : “Pedro”, “idade”: 21 }, { “nome” :
“Paulo”, “idade”: 22 } ] }

23. 23
Para converter objetos Java em objetos JSON existe um grande número de bibliotecas,
na qual se destaca o GSON da empresa Google. O GSON possui métodos que permitem
converter objetos Java em JSON e objetos JSON em objetos Java. (GSON, 2012)
2.6- Web Services
Os web services, ou serviços web é uma arquitetura que permite troca de mensagens
entre aplicações, independentemente de sistemas operacionais ou linguagens de programação.
(BOOTH et al., 2004) As tecnologias web services, são baseadas em XML, eXtensible
Markup Language, (BRAY, 2000), que permite que serviços web possam ser usados com essa
independência.
A figura 5 mostra essa independência, onde temos uma máquina rodando o sistema
operacional MAC OS X, com uma aplicação Java, e outra rodando Python em uma
plataforma Linux, ambas fazendo troca de mensagem por meio de um serviço web baseado
em XML.
Figura 5 – Funcionamento de um Serviço Web
2.7- Cliente x Servidor
A arquitetura Cliente/Servidor é dividido em duas partes, bem definidas, uma o
Cliente e outra o Servidor. Normalmente o servidor é uma máquina robusta e suas principais
funções são: Receber uma requisição do cliente, centralizar os dados, se necessário, fazer a
persistência dos dados em um Banco de Dados e por fim devolver uma resposta para o cliente.
Um servidor pode também se comunicar com outros servidores para atender a uma requisição
do cliente. (MENDES, 2002)
Já os clientes, desempenham um papel mais simples dentro de uma arquitetura
Cliente/Servidor: O cliente apenas inicia um pedido para o servidor e aguarda uma resposta
dele. Normalmente o cliente possui uma interface, que permite uma iteração direta com o
servidor. (MENDES, 2002)
Normalmente o cliente e o servidor estão conectados um ao outro mediante uma rede,
em hardwares separados, mas podem também estar em um mesmo sistema. A figura 6 ilustra
este modelo.

24. 24
Figura 6 – Modelo de uma arquitetura Cliente/Servidor
Existe hoje uma grande variedade de servidores que podem ser usados na linguagem
de programação Java, como o Apache Tomcat, o GlassFish, o JBoss, entre outros, cada um
com suas características.
2.8- JSF – JavaServer Faces
JSF acrônimo para JavaServer Faces, é um framework Java que visa simplificar o
desenvolvimento de interfaces web. Projetado para ser flexível, a tecnologia JavaServer Faces
utiliza conceitos existentes, padrão de interface do usuário e web sem limitar aos
desenvolvedores uma linguagem de marcação especial, protocolo ou dispositivo cliente.
(ORACLE, 2012)
A facilidade de uso é o principal objetivo do JSF. Hoje existe um grande número de
suítes de componentes, como por exemplo o PrimeFaces, RichFaces entre outras.
O PrimeFaces é uma suíte de componentes para agilizar o desenvolvimento da
interface. A suíte conta com um conjunto de componentes de mapas, utilizando o Google
Mapas. O PrimeFaces conta com diversos clientes, entre eles, Cisco, FORD, NVIDIA entre
outros. (PRIMEFACES, 2012)
2.9- Hibernate
O Hibernate é um framework desenvolvido em Java para fazer o mapeamento
Objeto/Relacional e manter a independência entre os banco de dados. O framework foi

25. 25
desenvolvido por diversos programadores Java e liderado por Gavin King, hoje o Hibernate
pertence a empresa JBoss/RedHat. (HIBERNATE, 2012)
O Hibernate facilita o mapeamento objeto – relacional, este mapeamento pode ser
feito através de XML ou através de anotações Java (anotations). Outra característica do
framework é que ele possui sua própria linguagem SQL, o HQL, Hibernate Query Language.
2.10- M-Government
A importância de um cidadão atuante sobre o governo aliada com a crescente demanda
de compra de dispositivos móveis, como smartphones, Tablets, celulares entre outros
possibilita o desenvolvimento do Mobile Govemment ou ainda M-Government. Este conceito
de aplicação é uma ramificação do Eletronic Govemment (E-Govemment) que utiliza de meios
eletrônicos, como televisão, rádios entre outros para integrar a sociedade e os governos.
Segundo Penteado Filho, 1998, o E-Govemment é a interação entre o governo e a
população realizada por meio de tecnologias da informação, cujo objetivo é facilitar a
comunicação, acesso aos dados, facilitando o acesso aos serviços. O conceito visa colocar a
população como um meio atuante dentro do governo.
Assim como a decisão de implantar o E-Govemment foi um passo importante dado por
muitos governos em todo o mundo décadas atrás, a adoção do M-Government para apoiar e
melhorar o desempenho do governo e uma sociedade mais conectada é inevitável. O M-Government
será a próxima grande onda de informação e comunicação usando a tecnologia
mobile no setor público. (OECD/ITU, 2011)
O M-Government tem por objetivo manter o cidadão mais próximo de seus governos
utilizando aplicativos para dispositivos móveis, estas aplicações agilizariam e melhorariam
este contato, tornando-a mais eficiente ao contatar os setores de saúde, educação, financeiro,
transporte e trânsito de um governo. Como tal, o governo mobile pode ajudar a melhorar as
condições sociais e econômicas em todo o mundo e também desempenhar um papel
importante no apoio do cidadão no desenvolvimento de uma sociedade sustentável.
O M-Government pode ser classificado em três tipos de relação:
1. Governo para Governo (G2G) : É a relação entre governos, troca de
informações;
2. Governo para Empresas (G2B) : É a relação do Governo com as empresas, por
exemplo um prestador de serviço com a empresa
3. Governo para cidadão (G2C) : É a relação do Governo com os cidadãos e vice-versa,
um exemplo é o um aplicativo que faça o registro de ocorrências dentro
de uma cidade.

26. 26
Figura 7 – Relação entre Governos, Cidadãos e Empresas
Este conceito pode ser aplicado em diversos setores e de diversas maneiras dentro de
um governo, como por exemplo pode-se ter uma aplicação que mostra os gastos de um
determinado governo, esse tipo de aplicação teria como principal objetivo tornar de uma
forma transparente os gastos de seu governo local, ou ainda uma aplicação onde o usuário
reportaria uma fraude, um infração, um buraco na rua, muro pichado ou grama alta em um
determinado local. Como visto o M-Government proporciona uma grande variedade de
aplicações, tanto tendo o usuário participando efetivamente em algo, como apenas para
informar algo para população.
Segundo Trimi e Sheng, 2008, O M-Government tem demonstrado grande potencial e
mostra um futuro promissor. Podemos ver esse potencial em diversos aplicativos que aplicam
este conceito de governo móvel, em que todos somos partes atuantes dentro do governo e
ajudamos a fiscalizar os poderes.
A figura 8 mostra um exemplo de uma aplicação desenvolvida para que o usuário
possa reportar danos nas cidades dos Estados Unidos. Além deste mostrado, existem um
grande número de aplicativos com essa finalidade que estão surgindo.

27. 27
Figura 8 – City Sourced
Fonte: http://itunes.apple.com/us/app/citysourced/id336854714?mt=8
As figuras 09 e 10 mostram outro exemplo de aplicação desenvolvida pela cidade do
Rio de Janeiro, Brasil. O sistema também conta com um sistema on-line aplicando os
conceitos de E-Government, e pode ser visualizado pelo site http://www.1746.rio.gov.br/, o
site possibilita que ocorrências sejam realizadas. O aplicativo está disponível nos sistemas
operacionais móveis: iOS, Android, Blackbarry, Nokia e Windows Mobile.
Figura 09 – Rio 1746 iOS
Fonte: https://itunes.apple.com/br/app/1746-rio/id425739340?mt=8

28. 28
Figura 10 – Rio 1746 Android
Fonte: https://play.google.com/store/apps/details?id=br.com.golmobile.canal746
Segundo pesquisa realizada em 2012 pela United Nations Public Administration
Programme (UNPAN) que mede
a
capacidade
do
setor
público
para
a
utilização
de
Tecnologias
de
Informação
e
Comunicação
para
servir
os
cidadãos,
com
base
em
uma
análise
de
sites
governamentais,
o país com o melhor índice de E-Government é a Republica
da Coréia, com média de 0.9283 pontos, sendo o máximo 1, seguido da Holanda com índice
de 0.9125. (UNPAN, 2012) A tabela a seguir mostra o top 20 dos países com melhor índice
de E-Government.
Tabela 3 – Top 20 Países E-Government
País
Índice
Republica
Corea
0.9283
Holanda
0.9125
Reino
Unido
e
Irlanda
do
Norte
0.8960
Dinamarca
0.8889
Estados
Unidos
0.8687
França
0.8635
Suécia
0.8599
Noruega
0.8593
Finlândia
0.8505
Cingapura
0.8474

29. 29
Canada
0.8430
Australia
0.8390
Nova
Zelândia
0.8381
Principado
de
Liechtenstein
0.8264
Suiça
0.8134
Israel
0.8100
Alemanha
0.8079
Japão
0.8019
Luxemburgo
0.8014
Estonia
0.7987
Fonte: http://www2.unpan.org/egovkb/global_reports/12report.htm

30. 30
3- PROPOSTA DE SOLUÇÃO: GOV2GO
Neste capítulo será apresentada a arquitetura em que o software, bem como o
desenvolvimento do sistema e suas principais características.
3.1- Arquitetura Global
O sistema denominado Gov2Go é composto de três partes, uma mobile, em que seu
cliente final é o cidadão, um sistema web, utilizado para as prefeituras fazerem o tratamento
das informações e o servidor, que um concentrador dos dados.
Na implementação do sistema foi usando como base a arquitetura de Cliente X
Servidor. A principal função do servidor é realizar a persistência e centralização dos dados
que vem do cliente, e também disponibilizar esses dados para os mesmos.
O Servidor utilizado, tanto mobile quanto web foi o Web Server da Apache, o Tomcat,
em sua versão 6.0.
Os sistemas, tanto mobile como web, foram estruturado usando MVC, (Model, View,
Controller). O modelo são as classes que representam o negócio, dentro do model fica as
classes POJOS. O controller faz acesso ao banco de dados, aplicam as regras de negócio e
retornam os dados para a view. A view é a interface com o usuário. (FREEMAN, 2007)
Para o cliente mobile, foi usado o sistema operacional ANDROID SDK versão 2.2,
logo seu desenvolvimento deu-se em JAVA, sua linguagem padrão, e este foi um dos motivos
de sua escolha, outro motivo, deve-se ao fato que este sistema operacional ser open source.
(ANDROID, 2012)
Está parte da aplicação é responsável por fornecer o formulário de cadastro de usuário,
e também coletar os dados da ocorrência denunciada, como a latitude e longitude do local,
uma foto tirada pelo usuário do sistema bem como uma pequena descrição do ocorrido. Outra
função desta aplicação é enviar os dados coletados para o Servidor fazer a persistência dos
dados.
Já o cliente web foi desenvolvido usando JSF (JavaServer Faces), esta parte da
aplicação tem um objetivo simples: Mostrar todas as ocorrências reportadas, e permitir uma
visualização no mapa do local dos problemas reportados, com a figura enviada pelo cidadão.
E também fazer o tratamento destas ocorrências, mudando o status para ocorrência tratada.
Para o ambiente de desenvolvimento de todos os softwares foram utilizados as
ferramentas de desenvolvimento Eclipse (ECLIPSE, 2012) e o JDK (Java Development Kit)
versão 7 (ORACLE, 2012).
Já para o Cliente Mobile foi utilizado o Android SDK em sua versão 2.2 (ANDROID,
2012), está versão foi escolhida por ser a versão disponível para testes.
A figura a seguir mostra a arquitetura da aplicação de uma forma geral.

31. 31
Figura 11 – Arquitetura da Aplicação
Na figura 11, podemos ver o funcionamento da aplicação como um todo. Na parte
superior da ilustração temos o Cliente Mobile, ou o cliente mobile, esta parte do sistema tem
como principal função fornecer ao usuário a possibilidade de registrar e enviar uma
ocorrência, tais ocorrências podem ser: Semáforo com defeito, buraco em vias publicas e ruas,
sinalização de trânsito em mal estado, etc.
Após o registro da ocorrência os dados são enviados para o servidor por meio de
RESTful, utilizando JSON como linguagem de comunicação, esta comunicação foi
desenvolvida para ser segura, de modo que se um invasor tentar acessar a informação ele não
conseguirá compreender a mensagem. Esta comunicação será melhor explicada e detalhada na
seção 3.2.

32. 32
Ao chegar no servidor, os dados são armazenados em um banco de dados MySQL, e
então é enviado uma mensagem de sucesso ou de não sucesso para o cliente mobile. Esses
dados estão em um banco de dados e poderão ser acessados pelas Prefeituras ou órgãos de
fiscalização, no caso os dados estão disponíveis para o cliente web do sistema.
3.2 – Cliente Móvel
O cliente mobile se comporta da seguinte maneira: As ações são iniciadas a partir de
uma interação do usuário com a tela do dispositivo móvel. Quando ocorre um processamento
de informação no cliente, como a realização do cadastro ou o login, é enviado ao servidor na
internet uma requisição RESTful por meio de JSON. Esta comunicação entre CLIENTE X
SERVIDOR será melhor apresentada na seção 3.4.1 deste trabalho.
Após o envio da requisição o sistema retorna uma mensagem de sucesso ou de erro
para o usuário, esta mensagem foi tratada a fim de ser mais amigável ao usuário final. Um
exemplo de mensagem é quando existe alguma falha na conexão, impedindo o cadastro de um
novo usuário, outro exemplo é quando ocorre uma falha no login.
Figura 12 – Exemplo de Mensagem de Erro na Aplicação
Os dados enviados para o servidor são, a localização do usuário, esta localização é
obtida automaticamente no momento que a ocorrência é enviada, além da localização é
enviado também uma foto do que está sendo reportado e um texto contendo uma descrição da
ocorrência.
A figura 13 mostra o trecho de código que obtém a latitude e a longitude usando a API
do Android: locationManager. Este código consegue pegar a latitude e longitude do local da
ocorrência por meio do GPS.

33. 33
Figura 13 – Código para pegar a localização da ocorrência
Para garantir a segurança da informação e também conseguir transitar imagens com
JSON, uma vez que o JSON não tem a capacidade de enviar imagens, apenas tipos primitivos,
como inteiros e strings por exemplo, foi utilizado o método de codificação conhecido como
Base64 e SHA-256.
3.2.1 – Segurança do Cliente Mobile
A segurança neste tipo de aplicação é de extrema importância, uma vez que as
informações que são transmitidas são de caráter confidencial. Essas ocorrências podem conter
dados que comprometam outras pessoas e instituições e se usadas de maneira indevida ou
ficarem disponíveis para qualquer cidadão podem comprometer a segurança do usuário que
gera a ocorrência. Existe também a necessidade das ocorrências serem feitas apenas pelo
cliente desenvolvido.
O processo para o envio da figura foi o seguinte: O cliente mobile converte a figura
para um array de Bytes, esse array de Bytes é convertido para Base64 para poder ser enviado

34. 34
para o servidor, via JSON. Quando esse texto (Base64) chega no servidor ela é convertida
novamente para um array de Bytes que é salvo em um campo tipo Blob no banco de dados.
3.3 – Cliente Web
A principal função deste cliente é prover uma interface amigável para o usuário, que
neste caso seriam as prefeituras ou empresas terceirizadas, que delegam as ocorrências para os
setores responsáveis. A página web recebe as informações do servidor. Estas informações são
exibidas em uma tabela, que nos mostra a data da ocorrência, a descrição enviada pelo
cidadão, data/hora que o problema foi solucionado e também a possibilidade de mudar o
status da ocorrência utilizando o botão “Mudar Status”, conforme apresentado a seguir na
figura 14.
Figura 14 – Exemplo da tabela com a lista das ocorrências
Aqui também são mostradas as ocorrências em um mapa, foi usado o Google mapas
que está disponível na suíte de componentes do PrimeFaces. Neste mapa estão disponíveis
todas as ocorrências que não foram tratadas. Essa etapa é possível porque no momento que o
cidadão reporta um erro (pelo cliente mobile) as informações de latitude e longitude são
extraídas, com estes dados torna-se possível mostrar em um mapa os pontos da infração, ao
clicar nestes pontos é possível visualizar a foto que foi enviada. Podemos ver com detalhes o
que foi exposto nas figuras 15 e 16.

35. 35
Figura 15 – Exemplo mapa com os pontos plotados
Figura 16 – Exemplo mapa com os pontos plotados e uma figura
3.4 - Servidor
Já modelagem de software no lado servidor da aplicação mobile foi desenvolvida em
Java e funciona da seguinte maneira: O servidor recebe a requisição enviada pelo cliente por
meio de comunicação RESTful, usando JSON, esta comunicação terá um detalhamento
melhor na seção 3.6. No momento que esta requisição chega, o software atente de acordo com
o que foi requisitado e retorna um resultado e o envia por meio de um objeto JSON. Caso haja
necessidade de acessar o banco de dados por meio de um framework denominado Hibernate, a
arquitetura do banco de dados e a persistência dos dados serão visto na próxima seção.

36. 36
Para o sistema mobile, obtemos a seguinte estrutura, mostrada na figura 17.
Figura 17 – Modelagem Cliente X Servidor da Aplicação Mobile
3.4.1 - Comunicação Cliente X Servidor
A comunicação entre Cliente e Servidor é dado por meio de um WebService RESTful
que deixa o serviço disponível. Para usar esta arquitetura RESTful foi usado uma API
denominada Jersey em sua versão 1.2, que implementa o padrão SUN para disponibilização
de serviços. O Jersey faz uso de anotations para construção e disponibilização de serviço.
(JERSEY, 2012)
A figura a seguir nos mostra um exemplo prático de anotação com a API de
disponibilização de serviços Jersey.
Figura 18 – Anotação com JERSEY

37. 37
Ainda na comunicação entre Cliente e Servidor foi usado o framework JSON, um
acrônimo de JavaScript Object Notation, que será o modo que os dados serão transitados
entre o cliente e servidor. Este framework foi escolhido por ser fácil de interpretar e escrever
por humanos e analisadas e geradas de uma forma simples pela máquina, além de ser
relativamente leve, tornando a troca de informação mais rápida e dinâmica. (JSON, 2012)
A estrutura de um objeto JSON pode ser observada na figura abaixo.
Figura 19 – Exemplo JSON
Para converter os objetos Java, tanto no Android como no web service, para objetos
JSON, foi utilizado o GSON, uma biblioteca desenvolvida pela empresa Google. A biblioteca
fornece uma interface simples para ler e converter objetos em JSON, além de fornecer um
amplo suporte aos Generics do Java, permitir representação de objetos personalizados e
suporte a tipos complexos de objetos. (GSON, 2012)
3.5- Arquitetura de Banco de Dados e Persistência de Objetos
O banco de dados deverá conter os dados dos usuários, os dados das ocorrências, bem
como uma tabela de login, e uma tabela de status, que contém todos os possíveis estados de
uma ocorrência. Para o desenvolvimento do protótipo usaremos o banco de dados relacional
MySQL, ele é de código aberto, gratuito e escalável, por estes motivos foi escolhido para ser
usado no sistema. (MYSQL, 2012)
Para a persistência de dados, na aplicação web foi usado o framework Hibernate
versão 3. O Hibernate nos permite fazer persistência de dados e mapeamento com ORM, que
significa Object-Relational Mapping, que tem por objetivo persistir objetos em base de dados
relacionais. (HEJLSBERG, 2012)
O Hibernate nos permite fazer o mapeamento por meio de annotations no código Java,
com as annotations é possível identificar as classes e as tabelas do banco em uma classe, ou
seja é possível fazer o ORM sem usar XML. (HIBERNATE, 2012) Para persistir esses
objetos usamos as classes POJOS com as devidas annotations. A figura a seguir mostra um
pedaço de classe POJO implementada no sistema.

38. 38
Figura 20 – Classe POJO login com anotações

39. 39
4- ESTUDO DE CASO E RESULTADOS: GOV2GO
Neste capitulo será apresentado os o estudo de caso e os resultados obtidos no
desenvolvimento da aplicação mobile Gov2Go. O desenvolvimento da aplicação ocorre em
conjunto com a Secretaria de Transportes da Cidade de São José dos Campos, São Paulo, logo
os requisitos do sistema atende as necessidades reais encontradas.
Este capítulo está dividido nos seguintes subcapítulos:
• 4.1 – Neste capítulo será mostrado os motivos para a realização do pesquisa e
implementação do sistema;
• 4.2 – O capítulo 4.2 descreve os requisitos do sistema, e quais funcionalidades
foram implantadas, bem como as telas que compõe o sistema;
4.1 – Cenário Atual
Atualmente as ocorrências são cadastradas por meio do site da Prefeitura Municipal de
São José dos Campos, pelo link: http://www.central156sjc.ipplan.org.br/index2.asp ou pelo
telefone, discando para o número 156, e são administradas por uma empresa terceirizada, a
ICI, Instituto Curitiba de Informática (http://www.ici.curitiba.org.br/) .
Para criar uma nova solicitação, o usuário deve entrar no site e preencher um
formulário que é subdividido em três blocos:
• Dados do Cidadão;
• Dados do Assunto;
• Dados para contato.
Para os dados do cidadão são necessários preencher os seguintes campos:
• Para pessoa física e Jurídica:
o Manter Sigilo dos Dados;
o Nome Pessoal;
o CPF;
o Tipo do logradouro;
o Logradouro;
o Número;
o Complemento;
o Bairro;
o Estado;
o Cidade;
o CEP.
o Local do assunto é igual ao Endereço do Solicitante?
• Apenas para pessoa jurídica:
o Razão Social;
o Nome Fantasia;
o Nome do Contato;
o CNPJ;
o Inscrição Estadual

40. 40
A figura a seguir mostra o formulário para os dados pessoais presentes no site
da Prefeitura Municipal de São José dos Campos.
Figura 21 – Site 156: Dados Pessoais
Fonte: http://www.sjc.sp.gov.br/servicos/atendimento156.aspx
Para os dados do assunto são necessários preencher os seguintes campos:

41. 41
• Assunto;
• Descrição detalhada;
• Tipo do logradouro;
• Logradouro;
• Número;
• Complemento;
• Cidade;
• Bairro;
• 1º Transversal;
• 2º Transversal;
• Ponto de referência
A figura 22 mostra os campos para serem preenchidos no bloco: Dados do Assunto:

42. 42
Figura 22 – Site 156: Dados do Assunto
Fonte: http://www.sjc.sp.gov.br/servicos/atendimento156.aspx
A figura 23 mostra os campos para serem preenchidos para os Dados para Contato e
os campos a serem preenchidos são:
• Telefones:
o Residencial;
o Celular;
o Comercial;
o Recado
 Recado com
• E-mail;
• Meio para Resposta;

43. 43
• Como você ficou sabendo do 156 na Internet.
Figura 23 – Site 156: Dados Para Contato
Fonte: http://www.sjc.sp.gov.br/servicos/atendimento156.aspx
Por fim, após preencher todos os dados no site e enviar, é gerado um protocolo no qual
é possível acompanhar o andamento da solicitação feita. Esses dados são inseridos em um
banco de dados e são distribuídos para os setores responsáveis que dão prosseguimento ao
processo.
4.2- Proposta de solução
O sistema desenvolvido foi dividido em três componentes:
1. Interface visual mobile, Cliente mobile ,para o usuário;
2. Interface visual web, Cliente Web , para a prefeitura ou órgão de fiscalização;
3. Servidor, para persistir os dados vindos do cliente mobile.
4.2.1- Interface Móvel
Este componente do sistema foi desenvolvido em Android, versão 2.2, a ferramenta de
desenvolvimento foi o Eclipse. O aplicativo poderá ser baixado a partir do site Google play

44. 44
(https://play.google.com/store). O Google play é um concentrador de aplicativos Android, no
qual é possível fazer downloads e instalar aplicativos direto no seu aparelho móvel.
Esta parte da aplicação tem como requisitos:
• Apresentar uma interface visual para o usuário;
• Prover um tela de login que dê acesso ao sistema;
• Dispor de um sistema de cadastro para novos usuários
• O cadastro deve conter os campos:
o Nome;
o E-mail;
o CPF;
o Telefone;
o Senha;
• Conter um sistema de registro de ocorrências:
• O registro das ocorrências deve possibilitar:
o Pegar a localização do usuário de uma forma automática;
o Permitir que o usuário tire uma foto da ocorrência;
o Possuir um campo para registro da descrição da ocorrência;
• Esta aplicação, ainda tem a função de mandar as informações para o servidor;
• Mostrar a resposta do servidor para aquela requisição.
Após ter o aplicativo instalado o usuário, pode fazer o login, caso já possua uma conta
no sistema, ou realizar o cadastro, caso não possua uma conta. A figura 25 mostra a tela
principal do aplicativo, contendo um login e um botão que direciona o novo usuário para o
cadastro.

45. 45
Figura 24– Login Sistema Móvel
A figura 25 mostra a tela que permite o cadastro de um novo usuário, contendo os
campos, nome, e-mail, CPF, telefone e senha.

46. 46
Figura 25– Cadastro de Novo Usuário Sistema Móvel
A figura a seguir mostra a tela principal do sistema, em que se é possível enviar uma nova
ocorrência, com o campo descrição, o botão que permite pegar uma figura da galeria ou tirar
uma foto naquele momento e um botão para enviar a ocorrência reportada.

47. 47
Figura 26– Tela principal do sistema
4.2.2- Interface Web
A interface web foi desenvolvida em Java, também utilizando o Eclipse como
ferramenta de desenvolvimento, foi utilizado o framework JSF, JavaServer Faces, e a suíte de
componentes PrimeFaces. Este sistema estará disponível para as Prefeituras que aderirem o
sistema mobile.
Os requisitos para este módulo são:
• Prover uma interface visual para o controle das ocorrências registradas;
• Possuir um sistema de login;
• Possibilitar a visualização da ocorrência, bem como a data, a descrição, a
localização, a data de que a ocorrência foi efetivamente resolvida e um botão
que possibilita mudar o estado da ocorrência, de pendente para resolvido;

48. 48
• Um mapa que mostre todas as ocorrências junto com a figura enviada pelo
cidadão.
A figura 27 mostra o sistema de Login do cliente web que foi desenvolvido para
controle das ocorrências.
Figura 27 – Tela de Login Sistema Web
A figura 28 mostra a tabela das ocorrências, com o id da ocorrência, descrição, data de
registro da ocorrência, data que a mesma foi resolvida, status, 1 para não resolvido e 0 para
resolvido e o botão para mudar o status.
Figura 28 – Lista de Ocorrências Cadastradas
A figura 29 mostra um mapa com os pontos nos locais das ocorrências, ao clicar no
balão azul uma figura é mostrada, a figura 30 ilustra essa etapa.

49. 49
Figura 29 – Mapa com os pontos de ocorrência
Figura 30 – Mapa com os pontos de ocorrência e figura
4.2.3- Servidor
Esta parte da aplicação não possui nenhuma interface visual e foi desenvolvida em
Java, utilizando a ferramenta de desenvolvimento Eclipse. O web service basicamente recebe

50. 50
uma requisição vinda do cliente mobile, faz a persistência dos dados em uma banco de dados
MySQL e retorna uma resposta para o cliente mobile, se atendeu ou não atendeu esta
requisição.
Logo, os requisitos para esta parte da aplicação são:
• Receber uma requisição do cliente mobile;
• Atender está requisição, persistindo os dados se necessário;
• Retornar uma resposta para o cliente

51. 51
5- CONSIDERAÇÕES FINAIS
Este trabalho apresentou o desenvolvimento de um ambiente que utiliza os conceitos
de M-Government e E-Government. Para propiciar o uso deste ambiente também foi
desenvolvido um aplicativo para dispositivos móveis, desenvolvido na plataforma Android.
Este capítulo esta dividido como segue:
• 5.1 – Apresenta as conclusões e contribuições do trabalho;
• 5.2 – Apresenta os trabalhos futuros que podem ser desenvolvidos junto ao
tema.
5.1- Contribuições e Conclusões
As contribuições para este trabalho são:
A. Apresentação dos conceitos de M-Government e E-Government;
B. Avaliação das tecnologias existentes que aplicam o conceito;
C. Estudo das tecnologias que viabilizam a implementação e o uso de forma
adequada do conceito
D. Desenvolvimento de um ambiente que aplica os conceitos de M-Government e
E-Government para oferecer serviços de setores públicos em dispositivos
móveis;
E. Implementação de um protótipo mobile aplicando o M-Government;
F. Implementação de um site para controle de ocorrências aplicando E-Government.
G. Testar e exibir os resultados provenientes do sistema.
Podemos concluir que existem hoje, sistemas de M-Government em outros países e
mesmo no Brasil que realizam a tarefa com destreza. Existe também o interesse de implantar
o M-Government e E-Government nas prefeituras e órgãos fiscalizadores nas cidades. Há,
hoje no mercado ferramentas e softwares que possibilitam o desenvolvimento de aplicações
para o M-Government. Por fim a arquitetura proposta no Gov2Go, bem como o aplicativo está
apto para ser utilizado e implantado nas cidades.
5.2- Trabalhos Futuros
As contribuições alcançadas com este Trabalho não encerram as pesquisas
relacionadas à área de M-Government, podemos citar como trabalhos futuros:
I. Implantar o M-Government em vários setores, não somente para o transporte e
transito de uma cidade;
II. Desenvolver a aplicação em outras plataformas;
III. Desenvolver a aplicação utilizando ferramentas híbridas, bem como:
a. Sencha Touch: http://www.sencha.com/products/touch/
b. Phonegap: http://www.phonegap.com
c. Jo: http://joapp.com
d. JQTouch: http://jqtouch.com
e. Entre outras ferramentas de desenvolvimento híbrido.
IV. Estudar outras formas de transitar as imagens entre o Cliente e o Servidor;

52. 52
V. Aplicar criptografia de chave pública para garantir a segurança dos dados, a
integridade e o não repudio.

53. 53
REFERÊNCIAS
ACKER, Eduardo, V.; Weber, Taisy, S.; Cechin, Sérgio, L. Injeção de Falhas para Validar
Aplicações em Ambientes Móveis. Universidade Federal do Rio Grande do Sul, 11, 2010,
Porto Alegre, Rio Grande do Sul. XI Workshop de Testes e Tolerância a Falhas. Porto Alegre:
Universidade Federal do Rio Grande do Sul, 2010. p. 61 - 74.
AKAIWA, YOSHIHIKO. Introduction to Digital Mobile Communication. 1st. ed. Canada:
Wiley-Interscience, 1997. ISBN 0471175455.
ANTOVSKI, Ljupco; GUSEV, Marjan. M-Government Framework. Disponível em:
mgov.cn/lab/Archives/EuromGov2005/PDF/5_R368AL.pdf Acesso em: 23/04/2012
BOOTH, David; HAAS, Hugo; et al. Web Services Architecture. Disponível em:
www.w3.org/TR/ws-arch/ Acesso em: 04/08/2012
BRAY, T.; PAOLI, J.; SPERBERG-MCQUEEN, C. M. and MALER, E. eXtensível Markup
Language (XML) 1.0. Disponível em: www.w3.org/TR/2000/REC-xml-20001006. Acesso
em: 08/09/2012
BURNETT, Steve, PAINE, Stephen. Criptografia e segurança: O guia oficial RSA, 1. ed.
Rio de Janeiro: Campus. ISBN 85-352-1009-1, 2002.
CANALYS. Smart Phones overtake Client PCs in 2011. Disponível em:
www.canalys.com/newsroom/smart-phones-overtake-client-pcs-2011 Acesso em: 02/03/2012
CASTELLÓ, Thiago; VAZ, Verônica. Tipos de Criptografia. Disponível em:
www.gta.ufrj.br/grad/07_1/ass-dig/TiposdeCriptografia.html Aceso em: 24/05/2012
CENSO. Disponível em: www.ibge.gov.br/home/ Acesso em: 21/03/2012
CERAMI, Ethan. Web Services Essentials - Distributed Applications with XML-RPC,
SOAP, UDDI & WSDL. Editora: O'Reilly, 2002, 500pgs, ISBN: 0596002246
CERT. Cartilha de Segurança para Internet. Disponível em: cartilha.cert.br/ Acesso em
14/05/2012
DA SILVA FILHO, Antônio Mendes. Segurança da informação: Sobre a necessidade de
proteção de sistemas de informações Online. Disponível em:
espacoacademico.com.br/042/42amsf.htm Acesso em: 26/04/2012
DEV GUIDE. What is Android? Disponível em: developer.android.com/guide/basics/what-is-
android.html Acesso em: 08/05/2012.
ECLIPSE. Disponível em: www.eclipse.org Acesso em 13/09/2012
ERKUL, R. Erdem. M-Government Around The World. Disponível em: digital-government.
net Acesso em: 15/04/2012

54. 54
FIELDING, Roy Thomas. Architectural Styles and the Design of Network-based Software
Architectures. Ph.D. Thesis, University da California, Irvine, California EUA, 2000.
FILHO, Otávio Freitas; FERREIRA, Maria A. G. V. Serviços Semânticos: Uma
Abordagem RESTful. Conferencia IADIS Ibero-Americana 2009. ISBN 978–972–8924–90-
4
FREEMAN, Eric. Use a Cabeça: Padrões de Projeto segunda edição. Alta Books, 2007.
ISBN 9788576081746.
GHYASI, A. Farshid; KUSHCHU, Ibrahim. M-Government: Cases of Developing
Countries. Disponível em: mgovlab.org Acesso em: 22/03/2012
GSON. Disponível em: code.google.com/p/google-gson/ Acesso em: 09/10/2012
HEJLSBERG, Anders. Object-Relational Mapping. Disponível em: artima.com Acesso em:
05/09/2012
HIBERNATE. Disponível em: www.hibernate.org/ Acesso em 22/10/2012
Instituto Ipsos Mediact. Números de Usuários de Smartphones no Brasil. Disponível em
http://www.ipsos.com/ Acesso em: 23/02/2012.
ITU International Telecommunication Union. Assinaturas globais de dispositivos móveis.
Disponível em www.itu.int/ITU-D/ict/statistics/ Acesso em: 06/04/2012.
JBOSS. Disponível em: www.jboss.org/resteasy Acesso em 17/09/ 2012
JERSEY. Disponível em: http://jersey.java.net/ Acesso em 19/09/2012
JSON. Disponível em: www.json.org/ Acesso em: 23/09/2012
KUSHCHU, Ibrahim; KUSCU, M. Halid. From E-Government to M-Government: Facing
the Inevitable. Disponível em www.mgovlab.org Acesso em 18/05/2012
MACIEL, J. Teles; SIQUEIRA, William A. Desenvolvimento de uma Arquitetura de
Integração entre Serviços Web para Criação de Aplicações Híbridas e Sociais. 2009. 87
f. Tese Graduação em Tecnologia em Banco de Dados. FATEC – Faculdade de Tecnologia de
São José dos Campos, São José dos Campos, 2009
MARTINS, Rafael J. W. de A. Desenvolvimento de Aplicativo para Smartphone com a
Plataforma Android. 2009. 50 f. Graduação em Engenharia de Computação - Pontifica
Universidade Católica do Rio de Janeiro, Rio de Janeiro. 2009
MENDES, Antônio. Arquitetura de Software: Desenvolvimento Orientado para
Arquitetura. Editora Campus. Rio de Janeiro - RJ, 2002.
MURUKAMI, Alexandre; KOBAYASHI, Luiz O. M.; TACHINARDI, Umberto.;
GUTIERREZ, Marco A.; FURUIE, Sergio S.; PIRES, Fábio Antero. Acesso a Informações

55. 55
Médicas através do Uso de Sistemas de Computação Móvel. 2004. 5 f. Dissertação. USP –
Universidade de São Paulo, São Paulo, 2004
MYSQL. Disponível em: www.mysql.com/ Acesso em 30/08/2012
OECD/ITU. M-Government: Mobile Technologies for Responsive Governments and
Connected Societies 2011. Disponível em: dx.doi.org/10.1787/9789264118706-en Acesso
em: 13/06/2012
OHA, Open Handset Alliance. Disponível em: www.openhandsetalliance.com Acesso em:
03/03/2012
OLIVER, Earl. A Survey of Platforms for Mobile Networks Research. Disponível em:
trac.assembla.com/thesis_rug/export/107/Sources/p56-oliver.pdf Acesso em 27/10/2012
ORACLE. Disponível em: www.oracle.com/technetwork/java/javaee/overview-140548.html
Acesso em: 21/10/2012
PAMPANELLI, GIOVANA AZEVEDO. A Evolução do Telefone e Uma Nova Forma de
Sociabilidade: O Flash Mob. Disponível em: razonypalabra.org.mx/anteriores/
n41/gazevedo.html Acesso em 25/03/2012
PENTEADO FILHO, P. A. Desafios e oportunidades da Reforma do Estado no Brasil: a
questão das organizações sociais. Organizações & Sociedade, Salvador, v. 5, n. 11, p. 153-
168, 1998.
PESSOA, Carlos A. C.; RAMALHO, Geber Lisboa; BATTAIOLA, André Luiz. wGEN: Um
Framework de Desenvolvimento de Jogos para Dispositivos Móveis. 2002. 10 f.
PRIMEFACES. Disponível em: primefaces.org/ Acesso em 12/10/2012
RFC4627. Disponível em: ietf.org/rfc/rfc4627.txt?number=4627 Acesso em 19/10/2012
SILBERSHARTZ, ABRAHAM.; GAGNE, GREG. E GALVIN, PETER B. Sistemas
Operacionais com Java – 6ed. Editora Elsevier, 2004, ISBN: 8535214852.
SILVA, Ana Paula; COELHO, Juliana Hohara de Souza. Uma Arquitetura Semântica para
Interoperabilidade de Sistemas de E-Saúde. 2010. 142 f. Tese Graduação em Tecnologia
de Banco de Dados. FATEC – Faculdade de Tecnologia de São José dos Campos, São José
dos Campos, 2010
TOMCAT. Disponível em: tomcat.apache.org/ Acesso em: 17/09/2012
TONON, UÉLITON SANDRO. “Medic Mobile”. Aplicação Móvel para Acesso Remoto de
Dados Clínicos de Pacientes Hospitalizados. 2006. 62 f. Graduação de Engenharia Elétrica -
Universidade Federal do Espírito Santo, Vitória. 2006
TRIMI, Silvana; SHENG, Hong. Emerging Trends in M-Government.
COMMUNICATIONS OF THE ACM Vol. 51, No. 5, p. 53-58, 2008

56. 56
UNPAN. United Nations E-Government Survey 2012. Disponível em: unpan.org/e-government
Acesso em: 05/03/2012