O trabalho de Eduardo Carrara de Araujo propõe uma solução de sensoriamento participativo para avaliar a qualidade da pavimentação viária em São Paulo, utilizando uma arquitetura de software cliente-servidor. A pesquisa analisa normas de gestão de pavimentos e investiga como tecnologias móveis podem contribuir para a coleta de dados sobre a condição das vias. Os resultados demonstraram que é viável identificar defeitos e mensurar a qualidade da pavimentação com dispositivos simples, como smartphones.

1. Eduardo Carrara de Araujo
Implementação de uma Aplicação de
Sensoriamento Participativo para Coleta de
Informações Sobre a Qualidade da
Pavimentação Viária
São Paulo
2013

2. Eduardo Carrara de Araujo
Implementação de uma Aplicação de Sensoriamento
Participativo para Coleta de Informações Sobre a
Qualidade da Pavimentação Viária
Trabalho de conclusão de curso apresentado
ao Centro Universitário Senac - Campus
Santo Amaro, como exigência parcial para
a conclusão do curso de Pós-Graduação em
Tecnologias e Arquiteturas na Construção de
Software.
Centro Universitário Senac
Orientador: Prof. Msc Daniel Paz de Araujo
São Paulo
2013

3. Ficha catalográfica elaborada pela Biblioteca do Centro Universitário Senac
A663i Araujo, Eduardo Carrara
Implementação de uma aplicação de sensoriamento participativo
para coleta de informações sobre a qualidade da pavimentação viária /
Eduardo Carrara de Araujo – São Paulo, 2013.
93 p. : il. color.
Orientador: Prof. Daniel Paz de Araujo
Trabalho de Conclusão de Curso (Pós-Graduação em Tecnologias e
Arquiteturas na Construção de Software) – Centro Universitário Senac,
São Paulo, 2013.
1. Sensoriamento participativo 2. Qualidade da pavimentação
viária 3. Tecnologias em mobilidade 4. Arquitetura de software 5.
Arquitetura cliente servidor I. Araujo, Daniel Paz de (Orient.) II.
Título
CDD 005.1

4. Eduardo Carrara de Araujo
Implementação de uma aplicação de sensoriamento participa-
tivo para coleta de informações sobre a qualidade da pavi-
mentação viária
Trabalho de conclusão de curso apresentado ao Centro Univer-
sitário Senac - Campus Santo Amaro, como exigência parcial
para a conclusão do curso de Pós-Graduação em Tecnologias
e Arquiteturas na Construção de Software.
Orientador Prof. Msc Daniel Paz de Araujo
A banca examinadora dos Trabalhos de Conclusão, em sessão pública realizada em
___/___/____, considerou o(a) candidato(a):
1. Examinador(a)
2. Examinador(a)
3. Presidente

5. Este projeto é dedicado à todas as pessoas que acreditam que o trabalho coletivo é
capaz de revolucionar a maneira de solucionar problemas, buscar o bem estar e a
melhoria da sociedade em geral.

6. Agradecimentos
À todos os meus amigos que colaboraram na criação e elaboração da ideia. Além
de proporcionar discussões sem fim sobre as infinitas possibilidades de desenvolvimento e
requisitos da solução.
Ao meu orientador Prof. Msc Daniel Paz de Araujo pelas conversas, suporte e
críticas tão valiosas à construção deste trabalho.
À minha noiva pelas infinitas revisões, infinita paciência e inabalável confiança de
que seria possível chegar ao fim de mais este caminho.
À minha família por todo o incondicional apoio em todas as situações.

7. "We can’t solve problems by using the same kind of thinking we used when we created
them."
Albert Einstein

8. Resumo
O foco deste trabalho é o desenvolvimento de uma proposta alternativa para avaliar
a condição da pavimentação viária de uma cidade utilizando uma solução de senso-
riamento participativo. Para fundamentar o projeto foram investigadas as propostas
e normas na área de gestão de pavimentos, como é realizada a avaliação da pavi-
mentação e os efeitos de uma qualidade de pavimentação ruim sobre os passageiros
em veículos. Também foram realizadas pesquisas em sensoriamento participativo,
tecnologias em mobilidade e engenharia de software de maneira à determinar como
a relação destes temas pode colaborar com a solução do problema. Com esta fun-
damentação foi possível realizar o projeto, análise e desenvolvimento de uma prova
de conceito na forma de uma solução de software com arquitetura cliente servidor,
na qual a aplicação cliente é utilizada na coleta dos dados e a aplicação servidor
em seu armazenamento e disponibilização. A análise das informações quantitativas
coletadas mostrou que é possível determinar a presença de defeitos e estimar a quali-
dade da pavimentação mesmo com dispositivos de coleta simples como smartphones,
além de viabilizar a coleta de medidas qualitativas que podem ajudar a mensurar o
impacto da qualidade da pavimentação na opinião dos usuários das vias.
Palavras-chave: 1. Sensoriamento Participativo. 2. Qualidade da Pavimentação
Viária. 3. Tecnologias em Mobilidade. 4. Arquitetura de Software. 5. Arquitetura
Cliente Servidor.

9. Abstract
The focus of this work is the development of an alternative proposition to evaluate
the pavement conditions for a given city using a participatory sensing solution.
To substantiate the project the following areas had to be investigated: proposals
and standards in pavement management, how the pavement evaluation is done and
the effects of a bad quality pavement on the vehicle’s passengers. Research in the
areas of participatory sensing, tecnologies in mobility and software engineering were
done to ascertain how the relationship between these topics could collaborate in the
problem’s solution. With this elements in place it was possible to design, analysis and
develop a proof of concept as a software solution based in a client server architecture,
in which the client application collects data and the server application handles the
data storage and availability. The collected quantitative information analysis showed
that it is possible to determine the presence of defects and assess the pavement
quality even using simple collection devices like a smartphone, and also enable the
collection of qualitative information that could help measure the pavement quality
impact in the perspective of its users.
Keywords: 1. Participatory Sensing. 2. Pavement Quality. 3. Mobility Technologies.
4. Software Architecture. 5. Client Server Architecture.

10. Lista de ilustrações
Figura 1 – Estrutura de um Sistema de Gerência de Pavimentos . . . . . . . . . . 19
Figura 2 – Processo para um Sistema de Gerência de Pavimentos . . . . . . . . . 20
Figura 3 – Variação da serventia com o tráfego ou com o tempo decorrido de uti-
lização da via . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
Figura 4 – Diversas faixas de variação do IRI . . . . . . . . . . . . . . . . . . . . . 23
Figura 5 – Sistema de coordenadas relativas ao dispositivo . . . . . . . . . . . . . 28
Figura 6 – Arquitetura cliente servidor para um sistema bancário de caixas eletrô-
nicos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
Figura 7 – GIS: Abrangência . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
Figura 8 – Proposta: Visão geral . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
Figura 9 – Diagrama de casos de uso . . . . . . . . . . . . . . . . . . . . . . . . . 48
Figura 10 –Diagrama de implantação . . . . . . . . . . . . . . . . . . . . . . . . . 56
Figura 11 –Fluxo de interação com as interfaces para os usuários da aplicação cliente 58
Figura 12 –Diagrama de componentes da aplicação Buraqueira . . . . . . . . . . . 59
Figura 13 –Diagrama de classes da aplicação Buraqueira . . . . . . . . . . . . . . . 61
Figura 14 –Diagrama de classes dos elementos de dados da aplicação Buraqueira . 62
Figura 15 –Diagrama de classes dos elementos GeoJSON . . . . . . . . . . . . . . 63
Figura 16 –Diagrama de sequência - Coleta bem sucedida da opinião do usuário
sobre uma via . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65
Figura 17 –Diagrama de sequência - Coleta bem sucedida da opinião do usuário
sobre um defeito específico . . . . . . . . . . . . . . . . . . . . . . . . . 66
Figura 18 –Diagrama de sequência - Coleta bem sucedida dos dados sobre a su-
perfície do trajeto realizado pelo usuário . . . . . . . . . . . . . . . . . 67
Figura 19 –Diagrama de sequência - Visualização e re-envio de dados não trans-
mitidos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67
Figura 20 –Diagrama de componentes da aplicação Buraqueira . . . . . . . . . . . 69
Figura 21 –Diagrama de classes da aplicação Buraqueira Server . . . . . . . . . . . 70
Figura 22 –Diagrama de sequência - Armazenamento de Dados . . . . . . . . . . . 73
Figura 23 –Diagrama de sequência - Obtenção de Dados . . . . . . . . . . . . . . . 73
Figura 24 –Testes - Coleta da avaliação de uma via . . . . . . . . . . . . . . . . . 74
Figura 25 –Testes - Obtenção dos dados de avaliação de vias utilizando um navegador 75
Figura 26 –Testes - Coleta da avaliação de um defeito . . . . . . . . . . . . . . . . 76
Figura 27 –Testes - Obtenção dos dados de avaliação de defeitos utilizando um
navegador . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76
Figura 28 –Testes - Posicionamento do dispositivo no interior do veículo . . . . . . 77

11. Figura 29 –Testes - Trajeto percorrido durante a coleta . . . . . . . . . . . . . . . 78
Figura 30 –Testes - Obtenção dos dados coletados em percursos utilizando um
navegador . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79
Figura 31 –Trajeto classificado como Bom pelo condutor . . . . . . . . . . . . . . 80
Figura 32 –Dados obtidos durante o trajeto com classificação Bom . . . . . . . . . 80
Figura 33 –Trajeto classificado como Regular pelo condutor . . . . . . . . . . . . 81
Figura 34 –Dados obtidos durante o trajeto com classificação Regular . . . . . . . 81
Figura 35 –Trajeto classificado como Ruim pelo condutor . . . . . . . . . . . . . . 82
Figura 36 –Dados obtidos durante o trajeto com classificação Ruim . . . . . . . . 82

12. Lista de tabelas
Tabela 1 – Níveis de serventia . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
Tabela 2 – Condições Inaceitáveis às Vibrações Verticais . . . . . . . . . . . . . . 25
Tabela 3 – Estatística de Percurso . . . . . . . . . . . . . . . . . . . . . . . . . . . 79

13. Lista de abreviaturas e siglas
API Application Programming Interfaces
DETRAN Departamento de Trânsito
DNER Departamento Nacional de Estradas e Rodagem
DNIT Departamento Nacional de Infraestrutura em Transportes
GIS Geographic Information Systems
GPS Global Positioning System (Sistema de Posicionamento Global)
HTTP HyperText Transfer Protocol
IRI International Roughness Index (Índice de Irregularidade Internacional)
JVM Java Virtual Machine
NFC Near Field Communications
PoC Proof of Concept (Prova de Conceito)
QI Quoeficiente de Irregularidade
SDK Software Development Kit
SGP Sistema de Gestão de Pavimentos
SP Estado de São Paulo localizado no Brasil
UML Unified Modeling Language
URL Uniform Resource Locator
UTC Universal Time Coordinated
VSA Valor de Serventia Atual
XML eXtensible Markup Language

14. Lista de símbolos
∑︀
Letra grega Sigma
Hz Hertz
g Medida de aceleração

15. Sumário
1 Introdução . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
2 Estado da Arte . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
2.1 Sistemas de Gerenciamento de Pavimentos (SGP) . . . . . . . . . . . . . . 19
2.1.1 Avaliação da Condição de Pavimentos . . . . . . . . . . . . . . . . . 20
2.1.2 Valor de Serventia Atual (VSA) . . . . . . . . . . . . . . . . . . . . 21
2.1.3 Índice Internacional de Rugosidade (International Roughness Index
- IRI) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
2.2 Vibração e o Conforto em Veículos . . . . . . . . . . . . . . . . . . . . . . 24
2.3 Tecnologias em Mobilidade . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
2.3.1 Telefones Móveis Inteligentes (Smartphones) . . . . . . . . . . . . . 25
2.3.2 Sistema Operacional Android . . . . . . . . . . . . . . . . . . . . . 26
2.3.3 Acelerômetros . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
2.3.4 Sistema de Posicionamento Global . . . . . . . . . . . . . . . . . . 28
2.4 Sensoriamento Participativo . . . . . . . . . . . . . . . . . . . . . . . . . . 29
2.5 Tecnologias em Engenharia de Software . . . . . . . . . . . . . . . . . . . . 30
2.5.1 Arquitetura de Software . . . . . . . . . . . . . . . . . . . . . . . . 30
2.5.2 Arquitetura Cliente - Servidor . . . . . . . . . . . . . . . . . . . . . 33
2.5.3 Sistemas de Informações Geográficas . . . . . . . . . . . . . . . . . 34
2.5.4 Linguagem de Modelagem Unificada (UML) . . . . . . . . . . . . . 35
2.6 Tecnologias em Desenvolvimento de Software . . . . . . . . . . . . . . . . . 36
2.6.1 Java . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
2.6.2 Spring Framework . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
2.6.3 Javascript Objects Notation (JSON) . . . . . . . . . . . . . . . . . . 38
3 Oportunidade . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
4 Proposta . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
4.1 Escopo e Requisitos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
4.1.1 Dados quantitativos e qualitativos sobre a pavimentação . . . . . . 44
4.1.2 Coleta de dados durante um trajeto . . . . . . . . . . . . . . . . . . 44
4.1.3 Coleta de dados sobre uma via específica . . . . . . . . . . . . . . . 45
4.1.4 Coleta de dados sobre um defeito específico . . . . . . . . . . . . . . 45
4.1.5 Visualização de dados coletados . . . . . . . . . . . . . . . . . . . . 45
4.1.6 Disponibilização de dados através de serviços Web . . . . . . . . . . 46
4.1.7 Otimização do uso de conexão de dados . . . . . . . . . . . . . . . . 46

16. 4.1.8 Sistema operacional do smartphone . . . . . . . . . . . . . . . . . . 46
4.1.9 Uso de ferramentas e serviços livres e/ou gratuitos . . . . . . . . . . 47
4.1.10 Restrições . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
4.2 Especificação . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
4.2.1 Coletar dados sobre um defeito . . . . . . . . . . . . . . . . . . . . 49
4.2.2 Coletar dados sobre uma via . . . . . . . . . . . . . . . . . . . . . . 50
4.2.3 Coletar dados em um trajeto . . . . . . . . . . . . . . . . . . . . . . 51
4.2.4 Transmitir dados . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
4.2.5 Visualizar dados . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
4.2.6 Visualizar dados não transmitidos . . . . . . . . . . . . . . . . . . . 53
4.2.7 Consultar dados . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
4.2.8 Armazenar dados . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
4.3 Arquitetura . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
4.3.1 Aplicação Cliente . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
4.3.1.1 Interfaces para o Usuário . . . . . . . . . . . . . . . . . . 57
4.3.1.2 Visão estrutural . . . . . . . . . . . . . . . . . . . . . . . 58
4.3.1.3 Visão dos dados . . . . . . . . . . . . . . . . . . . . . . . 62
4.3.1.4 Visão de tempo de execução . . . . . . . . . . . . . . . . . 65
4.3.2 Aplicação Servidor . . . . . . . . . . . . . . . . . . . . . . . . . . . 68
4.3.2.1 Visão estrutural . . . . . . . . . . . . . . . . . . . . . . . 68
4.3.2.2 Interfaces . . . . . . . . . . . . . . . . . . . . . . . . . . . 71
4.3.2.3 Visão dos dados . . . . . . . . . . . . . . . . . . . . . . . 71
4.3.2.4 Visão de tempo de execução . . . . . . . . . . . . . . . . . 72
4.4 Testes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73
4.4.1 Coleta de avaliação de uma via . . . . . . . . . . . . . . . . . . . . 74
4.4.2 Coleta de avaliação de um defeito específico . . . . . . . . . . . . . 75
4.4.3 Coleta de dados em um trajeto . . . . . . . . . . . . . . . . . . . . 77
5 Considerações Finais . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84
5.1 Resultados e Conclusões . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84
5.2 Sugestões para Trabalhos Futuros . . . . . . . . . . . . . . . . . . . . . . . 85
5.3 Trabalhos Relacionados . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85
Referências . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87
Apêndices 90
APÊNDICE A Documento GeoJSON: Exemplo de Coleta de Dados Sobre
uma Via . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91

17. APÊNDICE B Documento GeoJSON: Exemplo de Coleta de Dados Sobre
um Defeito . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92
APÊNDICE C Documento GeoJSON: Exemplo de Coleta de Dados Sobre a
Superfície de uma Via . . . . . . . . . . . . . . . . . . . . . . . 93

18. 17
1 Introdução
A infraestrutura das cidades, na forma de serviços e equipamentos, colabora com o
funcionamento e execução das diversas atividades sociais e econômicas que movimentam
as vidas de seus moradores. É uma peça fundamental na garantia da qualidade de vida
dos cidadãos e qualquer problema relacionado tem impacto direto na sociedade.
As vias públicas da cidade são parte desta infraestrutura e colaboram na sua lo-
gística proporcionando a conexão terrestre entre bairros, vilas, casas e outras cidades.
Possibilitam a circulação adequada dos diversos meios de transporte como: públicos, de
carga, coletivos, individuais etc. Observando-se sua extensão em uma grande capital bra-
sileira, como São Paulo, é possível ter uma ideia de sua representatividade e influência no
dia-a-dia dos cidadãos, segundo dados da Prefeitura de São Paulo (2004) estima-se a exis-
tência de mais de 17 mil quilômetros de vias públicas por onde, segundo o Departamento
de Trânsito de São Paulo (2013), circulam diariamente mais de 7 milhões de veículos.
Causim (2001 apud PREUSSLER, 1995, p. 53) exemplifica os impactos da manutenção
tardia e da mudança da qualidade do pavimento da via do conceito bom para o mau: au-
mento de até 58% no consumo de combustível; aumento de até 38% no custo operacional
dos veículos; aumento de até 100% no tempo de percurso; aumento de até 50% no índice
de acidentes.
Portanto desenvolver formas de monitorar e melhorar a qualidade da pavimenta-
ção das vias públicas é um fator importante para aliviar o impacto de seu desate na vida
dos cidadãos. Uma das formas propostas para sistematizar essa atividade é o uso do SGP
(Sistema de Gestão de Pavimentos), que, segundo Causim (2001), tem por objetivo garan-
tir o nível de conforto, segurança e economia dos pavimentos já construídos otimizando o
uso de recursos disponíveis e organizando o processo de manutenção.
Causim (2001 apud HAAS; HUDSON; ZANIEWSKI, 1994), Shahin (1994) e a
norma brasileira DNIT (2011) documentam que uma parte relevante do processo de SGP
consiste na coleta contínua de informações sobre as vias e condição de seus pavimentos, é
com base nestes dados que todo o processo decisório esta baseado. No entanto, a pesquisa
de Lima, Ramos e Junior (2006) mostra que, em cidades médias brasileiras, 60% das
prefeituras faz avaliações somente quando necessário e menos de 50% trabalha com algum
método específico de seleção de ruas para manutenção.
Sendo assim, a proposta deste projeto é a criação de uma ferramenta de software
que auxilie a coleta contínua da avaliação subjetiva dos usuários e informações quantita-
tivas sobre a qualidade das vias por onde trafegam diariamente, disponibilizando-as em
uma base de dados aberta que possa ser aproveitada pela sociedade como parte do critério

19. 18
de avaliação no planejamento da manutenção e evolução da malha viária das cidades.
Entende-se que o crescente interesse da população por smartphones, segundo o
IDC (2013) espera-se que sejam embarcados para o mercado brasileiro mais de 28 milhões
de unidades em 2013, pode prover as ferramentas necessárias para coleta de informações
já que estes dispositivos possuem variados recursos de hardware e software, como acelerô-
metros e conexão com a Internet. Outro fator que argumenta a favor da criação de tal
ferramenta é o surgimento e o crescimento da participação da população em iniciativas
que aproveitam o engajamento social eletrônico para exercitar a cidadania, ferramentas
como o My Fun City (2012), Fix My Street Brasil (2013), Colab (2013) e Waze (2006)
tem se destacado por disponibilizar funcionalidades e serviços que permitem aos usuá-
rios publicar sua opinião sobre o que está acontecendo em suas cidades, o impacto destes
acontecimentos em suas vidas e até mesmo utilizar essas informações para melhorar a
qualidade dos serviços prestados pelos governos de sua cidade e consequentemente de
suas vidas.
Portanto, o escopo deste projeto compreende a engenharia e desenvolvimento de
uma PoC (Proof of Concept) para um sistema baseado em arquitetura cliente-servidor
onde: uma aplicação Android será utilizada pelos usuários para coletar informações dos
acelerômetros e GPS (Global Positioning System) do smartphone e as enviar a um ser-
vidor, que por sua vez será responsável por armazenar os dados brutos dos sensores e
disponibilizá-los através de serviços web. Espera-se que com a utilização da prova de
conceito seja possível validar a possibilidade de aplicação do conceito de sensoriamento
participativo à este tipo de problema e efetuar uma análise inicial dos dados obtidos
durante os testes e experimentos.
O presente trabalho está estruturado da seguinte forma: no Capítulo 1 é feita a
contextualização do problema e o entendimento da relevância da proposta na melhoria
da pavimentação viária; os conceitos teóricos sobre a gestão da pavimentação viária, tec-
nologias em mobilidade e sensoriamento participativo são apresentados no Capítulo 2; o
detalhamento da oportunidade de melhoria na coleta de informações sobre a pavimen-
tação viária é feita no Capítulo 3; no Capítulo 4 é apresentada a proposta, projeto e
os testes realizados com a prova de conceito desenvolvida; finalmente no Capítulo 5 são
documentadas as conclusões e sugestões para trabalhos futuros.

20. 19
2 Estado da Arte
2.1 Sistemas de Gerenciamento de Pavimentos (SGP)
A pavimentação viária representa um recurso valioso para sociedade, sua preserva-
ção é essencial para garantir custos operacionais adequados a usuários e administradores.
A interrupção ou diminuição dos serviços de manutenção desta infraestrutura resultam
no aumento dos custos de utilização e exigem investimentos maiores para sua recuperação
(DNIT, 2011).
Becker (2012 apud HAAS; HUDSON; ZANIEWSKI, 1994) apresenta o SGP como
um conjunto de atividades coordenadas para o planejamento, projeto, construção, manu-
tenção, avaliação e pesquisa de pavimentos. Seu objetivo principal é determinar a siste-
mática que possibilite o retorno máximo sobre o investimento dos recursos aplicados para
a construção e manutenção de pavimentos a partir de uma base de informações confiáveis
sobre o estado da malha viária.
A implementação de um SGP pode ser estruturada de maneiras diferentes, é apre-
sentada na Figura 1 a estrutura e as atividades para um SGP conforme Causim (2001 apud
HAAS; HUDSON; ZANIEWSKI, 1994, p.26), já Shahin (1994) propõe uma organização
na forma de processos e fases como representado na Figura 2.
Figura 1 – Estrutura de um Sistema de Gerência de Pavimentos
Fonte: Causim (2001 apud HAAS; HUDSON; ZANIEWSKI, 1994, p.26)

21. 20
Figura 2 – Processo para um Sistema de Gerência de Pavimentos
Fonte: Shahin (1994, p. 340)
No Brasil, o Departamento Nacional de Infraestrutura em Transportes (DNIT)
é responsável pela normatização das atividades relacionadas a pavimentação. Na norma
DNIT (2011) define-se quatro grandes atividades básicas para este tipo de sistema:
1. Estabelecimento do Sistema de referência;
2. Avaliação dos pavimentos;
3. Determinação das Prioridades;
4. Elaboração de programa plurianual de investimentos.
2.1.1 Avaliação da Condição de Pavimentos
Nas estruturas apresentadas é possível observar que a avaliação, coleta e orga-
nização de informações sobre a condição das vias é um ponto em comum. Sobre estas

22. 21
atividades, o DNIT (2011) ressalta sua importância como insumo para o processo deci-
sório do sistema, sua execução possibilita determinar as condições funcionais, estruturais
e operacionais da malha viária em um determinado momento, além da obtenção e atu-
alização de dados que alimentam periodicamente o SGP, possibilitando sua operação de
maneira mais eficiente. Uma das funcionalidades mais relevantes de um SGP, segundo
Shahin (1994) é sua habilidade de determinar o estado atual e futuro da pavimentação
das vias, para garantir a confiabilidade e capacidade do sistema em cumprir esse objetivo
é necessário estabelecer um método contínuo de avaliação.
Para análise da degradação dos pavimentos e posterior tomada de decisão sobre
as ações a serem realizadas, a norma DNIT (2011) esclarece que três fatores devem ser
observados:
1. Desempenho funcional: Capacidade do pavimento em exercer sua função principal,
que é o fornecimento de uma superfície adequada ao rolamento;
2. Desempenho estrutural: Capacidade do pavimento em manter sua integridade es-
trutural durante e após sua utilização;
3. Desempenho operacional e da segurança: Refere-se à aspectos da via que influenciam
diretamente sua segurança e utilização pelos usuários, como sinalização, aderência
do veículo à via, resistência à derrapagem, comportamento dos motoristas etc.
Os defeitos presentes na superfície das vias e como seu estado atual afeta o rola-
mento dos veículos estão diretamente relacionados ao desempenho funcional, sua avaliação
pode ser feita através do Valor de Serventia Atual (VSA) e do International Roughness
Index (Índice de Irregularidade Internacional - IRI). (DNIT, 2011)
2.1.2 Valor de Serventia Atual (VSA)
Uma medida subjetiva da superfície do pavimento que mede a capacidade da via
proporcionar, na opinião do usuário, rolamento suave e confortável em um momento
sob qualquer condição de tráfego. A avaliação é realizada por uma equipe composta de
membros especialistas na avaliação deste tipo de infraestrutura. (DNIT, 2003)
O processo de avaliação normatizado pela DNIT (2003) estabelece que os avaliado-
res devem percorrer as vias utilizando veículos em uma velocidade próxima a velocidade
máxima da via; devem ser atribuídas notas a trechos da via, estas notas devem variar
entre 0,0 e 5,0 (indicando, respectivamente, pavimentos de péssimo a ótimo); deve-se ter
em mente critérios como o quanto o pavimento atende no momento o propósito ao qual
foi construído e se o conforto proporcionado é adequado.

23. 22
Após a coleta das avaliações, o VSA é calculado para cada trecho da via de acordo
com a fórmula (2.1) abaixo:
𝑉 𝑆𝐴 =
∑︀
𝑋
𝑛
(2.1)
Onde:
∙ VSA: Valor de Serventia Atual;
∙ X: Avaliação de serventia atual atribuída por cada membro da equipe avaliadora;
∙ n: número de membros do grupo de avaliação.
Os cinco níveis de serventia da escala podem ser expressos como na tabela 1. Em
geral, após a construção ou reforma da superfície da via o índice VSA é elevado já que
esta se apresenta suave e sem irregularidades. (DNIT, 2011)
Tabela 1 – Níveis de serventia
Padrão de Conforto ao Rolamento Avaliação (faixa de notas)
Excelente 4 a 5
Bom 3 a 4
Regular 2 a 3
Ruim 1 a 2
Péssimo 0 a 1
Fonte: DNIT (2003, p. 46)
No entanto, o VSA pode diminuir por conta do tráfego e das intempéries. É possível
estabelecer dois limites relacionados à degradação da via: de aceitabilidade e trafegabi-
lidade. Abaixo do nível de aceitabilidade o conforto proporcionado pela via aos usuários
passa a ser inadequado (o limite depende do tipo de via e tráfego, variando de uma VSA
de 2 a 2,5). Quando este nível é atingido deve ser feita a manutenção corretiva da via para
restaurar sua condição, antes disso apenas a manutenção preventiva periódica é suficiente
para manter níveis aceitáveis. Caso não haja manutenção o pavimento pode atingir o
limite de trafegabilidade, no qual a circulação de veículos é extremamente prejudicada e
torna-se necessária a reconstrução da via. A evolução da curva de serventia é apresentada
na Figura 3. (DNIT, 2011)

24. 23
Figura 3 – Variação da serventia com o tráfego ou com o tempo decorrido de utilização da via
Fonte: DNIT (2011, p.47)
2.1.3 Índice Internacional de Rugosidade (International Roughness Index -
IRI)
O IRI é um índice utilizado para quantificar a quantidade de irregularidades em
trechos de uma determinada via. A irregularidade longitudinal refere-se ao somatório dos
desvios detectados na superfície de um pavimento em relação a um plano de referência
ideal, que impactam em características como qualidade ao rolamento, dinâmica das cargas
e a drenagem superficial. Suas faixas de variação são mostradas na Figura 4. (DNIT, 2011)
Figura 4 – Diversas faixas de variação do IRI
Fonte: DNIT (2011, p.49)
As irregularidades afetam diretamente a interação das vias com os veículos, os
efeitos são perceptíveis nos passageiros, cargas e nos próprios veículos. A importância em

25. 24
entender e mensurar as irregularidades está em sua correlação com os custos e qualidade
de serviço entregue aos usuários. (DNIT, 2011)
No Brasil, o DNIT (2011) recomenda que o levantamento das irregularidades seja
feito de acordo com a norma DNER (1994b) que especifica a utilização de sistemas do
tipo resposta e também lista a classificação de alguns equipamentos de medição:
∙ Sistemas de medidas diretas de perfil: Método de nível e mira;
∙ Sistemas de medida indireta do perfil: Perfilômetro de superfície GMR, Perfilômetro
AASHTO, Perfilômetro CHLOE, Merlin do TRRL;
∙ Sistemas do tipo resposta: Rugosímetro BPR, Bump Integrator, Maysmeter, Inte-
grador IPR/USP;
∙ Sistemas de medida com sonda sem contato – Perfilômetro Laser, Perfilômetro Acús-
tico da Universidade FELT.
O procedimento proposto pela norma DNER (1994b) especifica a realização das
medições utilizando um veículo de passeio em conjunto com um instrumento tipo resposta.
As leituras devem fornecer os valores absolutos dos deslocamentos verticais do eixo traseiro
do veículo em relação à carroceria e devem ser relacionadas às informações de localização
do trecho da via onde foi realizada a leitura.
O valor final do IRI é calculado através de uma das equações para o coeficiente de
irregularidade (QI) conforme especificado na norma DNER (1994a):
𝑄𝐼 = 𝑎 + 𝑏𝐿 (2.2)
𝑄𝐼 = 𝑎 + 𝑏𝐿 + 𝑐𝐿2
(2.3)
Onde:
∙ a, b e c: determinados pelo método dos mínimos quadrados;
∙ L: leitura do instrumento de medição.
2.2 Vibração e o Conforto em Veículos
O desempenho funcional refere-se a capacidade dos pavimentos em fornecer uma
superfície adequada à utilização pelos usuários, sua avaliação é associada a diversos fatores
entre eles o conforto resultante da utilização da via. (DNIT, 2011)

26. 25
As irregularidades presentes nas superfícies das vias são transmitidas aos passa-
geiros na forma de vibrações através dos diversos componentes do veículo. (MAIA, 2002)
A norma ISO (1997) estabelece diretrizes para a análise de vibrações ao corpo
inteiro, principalmente em circunstâncias em que a vibração é transmitida através de uma
superfície de sustentação como pés de uma pessoa em pé, nádegas de uma pessoa sentada
ou área de sustentação onde se recosta. Esta norma ainda recomenda que a quantidade a
ser utilizada para medir a intensidade da vibração é a aceleração, normalmente expressa
em metros por segundo ao quadrado.
Segundo Franchini (2007 apud SELL, 2002, p. 48), frequência, deslocamento, velo-
cidade e aceleração são as principais características físicas na geração de vibrações verticais
que podem afetar o corpo humano. Algumas diferentes faixas de vibração e aceleração
que tornam as condições inaceitáveis ao corpo humano estão compiladas na tabela 2.
Tabela 2 – Condições Inaceitáveis às Vibrações Verticais
Frequências inferiores a 2Hz e aceleração de 3g a 4g
Frequências entre 4Hz e 14Hz e aceleração entre 1,2g e 3,2g
Frequências acima de 14Hz e aceleração entre 5g e 9g
Com aceleração de 1,5g a vibração se torna perigosa e insuportável
A aceleração mais crítica em relação ao incômodo é de 1g, cerca de 10𝑚/𝑠2
À 2,5𝑚/𝑠2
a incidência de erros é tão grave que as vibrações devem ser consideradas
perigosas
Com aceleração de 0,5𝑚/𝑠2
no assento, os erros do motorista aumentam significati-
vamente
De 1Hz a 4Hz, há dificuldade para respirar
De 2Hz a 16 Hz, o desempenho do motorista diminui muito e os efeitos pioram com
o aumento da aceleração
De 4Hz e 8 Hz, há maior sensação de incômodo
De 4Hz a 10 Hz começam dores no peito, na barriga, reação na musculatura, resso-
nância no maxilar inferior
De 8Hz a 12 Hz, dores nas costas
De 10Hz a 20 Hz, tensão muscular, dor de cabeça, perturbações visuais, dores na
traqueia, perturbações na fala
Fonte: Adaptado de Franchini (2007 apud SELL, 2002, p. 48)
2.3 Tecnologias em Mobilidade
2.3.1 Telefones Móveis Inteligentes (Smartphones)
Zheng e Ni (2006) define smartphone, ou telefone móvel inteligente, como uma
nova classe de aparelhos celulares, dotada de um aumento significativo no poder de pro-

27. 26
cessamento computacional e facilidades no acesso a dados. Além das tradicionais funcio-
nalidades de comunicação por voz e mensagens de texto, esta nova classe de dispositivos
oferece uma ampla gama de aplicações como calendários, agendas, calculadoras, jogos,
execução e gravação de áudio e vídeo, câmera integrada, mensagens instantâneas, acesso
à internet, comércio eletrônico, pagamentos eletrônicos, aplicativos empresariais, serviços
baseados em localização entre outras.
Com o aumento da capacidade de processamento e da variedade de funcionali-
dades disponíveis é possível olhar para o smartphone como o resultado da convergência
de diversos dispositivos e fica clara sua importância como agente de inovação nas mais
diversas áreas do entretenimento ao meio corporativo, e até mesmo na área acadêmica.
Zheng e Ni (2006)
2.3.2 Sistema Operacional Android
Segundo a Open Handset Alliance (2013) e o Android Open Source Project (2013),
a plataforma Android é um conjunto de softwares composto por sistema operacional,
middleware, ferramentas de desenvolvimento (software development kit (SDK)) e algu-
mas aplicações chave para dispositivos móveis. Este conjunto pode ser incorporado a uma
ampla variedade de dispositivos para possibilitar aos desenvolvedores a criação de apli-
cativos capazes de utilizar todo o potencial dos dispositivos nos quais serão embarcados
(usualmente tablets e smartphones) e entregar aos usuários uma experiência única.
Uma das principais vantagens da plataforma Android é proporcionar um ambiente
unificado e aberto para o desenvolvimento de aplicações. O código da plataforma é open-
source e todas as funcionalidades do dispositivo podem ser acessadas via API (application
programming interfaces). Open Handset Alliance (2013)
As principais funcionalidades são encontradas em Google (2013a), abaixo segue
uma lista com algumas delas:
∙ funcionalidades de áudio e video;
∙ comunicação via voz e texto;
∙ diversas formas de acesso à dados e internet;
∙ localização e navegação;
∙ gráficos avançados;
∙ internacionalização e localização;
∙ segurança: perfis, desbloqueio biométrico e via senha etc;

28. 27
∙ acessibilidade: voz para texto, texto para voz, tamanho de fonte, recursos de resposta
etc;
∙ aplicações: agenda, câmera, galeria multimídia, relógio, navegador para internet,
teclado na tela, aplicativo para troca de mensagens de texto, notícias e clima etc;
∙ recursos de hardware: acelerômetros, compasso eletrônico, GPS (Global Positioning
System), NFC (Near Field Communications), câmera, sensor de proximidade, sensor
de luminosidade, sensor de temperatura, sensor de pressão atmosférica, giroscópio
etc.
2.3.3 Acelerômetros
Sensores de aceleração, ou acelerômetros, são componentes eletro-mecânicos capa-
zes de medir a aceleração aplicada ao corpo do sensor, inclusive a aceleração da gravidade.
Comumente fornecido em circuitos integrados compostos de três sensores preparados para
medir a aceleração em diferentes dimensões. Sua disponibilidade e utilização tem se tor-
nado cada vez mais comum em smartphones para proporcionar novas formas de interação
e melhorar a usabilidade para o usuário. (SCHERZ, 2013; GOOGLE, 2013c)
A documentação em Google (2013c) especifica o funcionamento do acelerômetro
na plataforma Android, cujo sensor mede a aceleração aplicada ao dispositivo derivando-a
da medição das forças aplicadas ao próprio sensor. Nesta medição está inclusa a aceleração
da gravidade, que precisa ser removida para se obter a aceleração real do dispositivo.
Conforme apresentado em Google (2013d) o acelerômetro utiliza o sistema de
coordenadas padrão para sensores em dispositivos Android representado na Figura 5.
Em Google (2013c) descreve-se as seguintes condições com o dispositivo sobre uma
mesa em sua orientação natural:
∙ Se o dispositivo for empurrado para a esquerda, a aceleração no eixo x é positiva;
∙ Se o dispositivo for empurrado para cima, a aceleração no eixo y é positiva;
∙ Se o dispositivo for empurrado de encontro ao céu com uma aceleração de 𝐴𝑚/𝑠2
,
a aceleração no eixo z será de 𝐴𝑚/𝑠2
+ 9, 81, que corresponde a aceleração do
dispositivo (+𝐴𝑚/𝑠2
) subtraída da aceleração da gravidade (−9, 81𝑚/𝑠2
);
∙ Quando parado, a leitura será de uma aceleração de +9, 81𝑚/𝑠2
correspondente a
aceleração do dispositivo (0𝑚/𝑠2
) subtraída da aceleração da gravidade (−9, 81𝑚/𝑠2
).

29. 28
Figura 5 – Sistema de coordenadas relativas ao dispositivo
Fonte: Google (2013d)
2.3.4 Sistema de Posicionamento Global
O sistema de posicionamento global (do inglês Global Positioning System, ou ainda
GPS) é definido pelo National Coordination Office for Space-Based Positioning, Naviga-
tion, and Timing (2013) como um utilitário que fornece aos usuários serviços de posicio-
namento, navegação e ajuste de tempo. Sua implementação é divida em três segmentos:
∙ Segmento do Espaço: compreende vinte e quatro satélites que orbitam o planeta
Terra transmitindo continuamente sinais de rádio contendo informações de posicio-
namento e tempo;
∙ Segmento de Controle: conjunto de instalações distribuídas por diversos países que
monitoram e controlam as operações dos satélites GPS;
∙ Segmento de Usuário: consiste em um receptor de sinais GPS capaz de captar,
interpretar os dados e calcular informações de posicionamento a serem utilizadas
por uma aplicação específica.
O processo de utilização do sistema GPS inicia com a transmissão das informações
de posicionamento e tempo pelos satélites; os sinais de rádio são recebidos e interpretados
por um receptor GPS que utiliza os dados para calcular a distância do receptor até o
satélite; a partir da distância estimada até pelo menos quatro satélites o receptor uti-
liza cálculos de geometria para obter o posicionamento do receptor em relação à Terra.
(NATIONAL COORDINATION OFFICE FOR SPACE-BASED POSITIONING, NAVI-
GATION, AND TIMING, 2013)

30. 29
A integração de receptores GPS em dispositivos Android tem se tornado comum.
Conhecer o posicionamento do usuário do dispositivo permite o desenvolvimento de apli-
cações inteligentes capazes de entregar serviços e informações mais relevantes. As funci-
onalidades contidas nas classes do pacote android.location permitem acesso aos serviços
de sistema do Android que fornecem a localização do usuário. No entanto, é importante
ressaltar que, apesar do GPS ser o método mais preciso em ambientes externos, para esta
tarefa o receptor consome mais energia do que outras formas e não é tão rápido quanto
desejado pela maioria dos usuários, este problema é abordado na plataforma Android
utilizando uma técnica que mescla informações obtidas de diversos meios para estimar a
localização do usuário, como o sinal de Wi-Fi e de dados do smartphone.
2.4 Sensoriamento Participativo
A evolução das tecnologias móveis, com a criação de dispositivos como os smartpho-
nes com amplo acesso a dados e melhorada capacidade de processamento, aliada a sua
crescente adoção por grande parte das pessoas começam a possibilitar novas formas de
coleta de informações como o sensoriamento participativo (do inglês paticipatory sensing),
cuja ideia principal é disponibilizar aos cidadãos ferramentas que os tornem capazes de
coletar e compartilhar informações sobre seu meio ambiente utilizando os recursos dispo-
níveis em smartphones. (KANHERE, 2011; BURKE et al., 2006)
Aplicações que trabalham o conceito de sensoriamento participativo tipicamente
adotam o modelo cliente servidor no qual um software instalado no smartphone de um
voluntário, ativado manualmente, automaticamente ou através do contexto, coleta os da-
dos dos sensores e os envia a uma aplicação em um servidor, que por sua vez efetua o
processamento e disponibiliza as informações em formatos que podem variar de acordo
com as necessidades dos usuários. (KANHERE, 2011)
A versatilidade e variedade de recursos disponíveis nos dispositivos móveis atu-
ais possibilitam uma variedade de aplicações que, segundo Kanhere (2011) podem ser
divididas em duas categorias:
∙ Aplicações de sensoriamento orientadas às pessoas: utiliza os sensores do dispositivo
móvel para obter dados sobre o comportamento do usuário. São alguns exemplos:
monitoramento de saúde pessoal, cálculo de impacto ambiental, monitoramento e
documentação de experiências esportivas, melhorar o uso de mídias sociais, auditoria
de preços.
∙ Aplicações de sensoriamento orientadas ao ambiente: utiliza os sensores do dispo-
sitivo móvel, e possivelmente equipamentos adicionais, para obter dados sobre o
ambiente onde está o usuário. São alguns exemplos: monitoramento da qualidade

31. 30
do ar, monitoramento de níveis de ruído, monitoramento de pavimentos e condições
de tráfego.
Ainda segundo Kanhere (2011), o sensoriamento participativo oferece algumas
vantagens sobre redes de sensores distribuídos tradicionais como o uso da infraestrutura
já existente de smartphones e redes de dados (WiFi ou celular), o que permite um custo
de implementação mais baixo; a grande cobertura das operadoras de celular habilita uma
grande penetração no número de dispositivos e na área que pode ser coberta pela aplicação;
o uso smartphones como sensores intrinsecamente permite economia de escala; o uso de
plataformas móveis já existentes para desenvolvimento e distribuição das aplicações torna
o processo de implantação e implementação mais fácil; finalmente, ao incluir os cidadãos
ao processo de coleta é possível projetar soluções que realmente colaborem na melhoria
do dia a dia das comunidades.
2.5 Tecnologias em Engenharia de Software
De acordo com Sommerville (2003), a engenharia de software é uma disciplina que
trata de todas as particularidades e atividades relacionadas à produção de software du-
rante todo o ciclo de vida do projeto, desde a prospecção e especificação até a manutenção
do sistema. Os engenheiros de software trabalham de maneira sistemática e organizada
para identificar teorias, métodos e ferramentas que sejam mais adequadas para auxiliar
na solução dos problemas dentro das restrições organizacionais e financeiras que lhe são
impostas.
Esta seção aborda algumas questões relacionadas à engenharia de software que
guiam e fundamentam o projeto proposto neste trabalho, principalmente no que diz res-
peito a arquitetura de software e modelos de referência utilizados.
2.5.1 Arquitetura de Software
A arquitetura de software é uma descrição, constituída de um ou mais modelos,
que representa a visão estrutural do sistema possibilitando a identificação, a comunicação
e a compreensão dos diversos elementos, além de suas relações e propriedades, que podem
fazer parte do software. (SOMMERVILLE, 2003; BASS; CLEMENTS; KAZMAN, 2012)
O projeto de arquitetura é o processo pelo qual o sistema é decomposto em subsis-
temas e módulos, e as decisões sobre a estrutura, organização e relacionamento entre os
diversos elementos identificados são documentados. A arquitetura representa a conexão
entre os requisitos de software, as necessidades do negócio, e o sistema a ser construído.
(SOMMERVILLE, 2003)

32. 31
Bass, Clements e Kazman (2012) argumentam que a complexidade presente nos
software modernos frequentemente torna muito difícil sua compreensão com uma única
visão ou estrutura. O conjunto de todos os elementos de software e hardware que compõem
o sistema é chamado de estrutura; já a visão é uma representação de um subconjunto de
elementos estruturais organizados coerentemente e representados de forma a garantir a
compreensão por todos os envolvidos no projeto. As estruturas podem ser dividas em três
tipos:
∙ Estrutura de Módulos: uma representação estática do sistema composta pelas unida-
des de implementação (classes, camadas, ou divisões de funcionalidades); é estrutu-
rada como um conjunto de códigos ou unidades de dados que devem ser construídos
ou contratados. Se dedica a investigar as responsabilidades, dependências e relacio-
namentos entre os elementos;
∙ Estruturas Componentes-Conectores: incorpora decisões sobre a estrutura dos ele-
mentos que possuem comportamento em tempo de execução. Componentes são ele-
mentos que fazem parte da estrutura (serviços, clientes, servidores, filtros etc) e os
conectores representam os meios de comunicação entre os elementos (retornos de
chamada, meios de sincronização etc). Provê informações sobre o fluxo de dados no
sistema, paralelismo, dados compartilhados, interação entre componentes em tempo
de execução;
∙ Estruturas de Alocação: representam os relacionamentos do sistema com compo-
nentes que não fazem parte do software (como unidades de processamento, sistemas
de arquivos, redes, times de desenvolvimento etc). Colabora com informações sobre
interações com o ambiente externo como quais times de software irão desenvolver
cada componente, em qual unidade de processamento cada componente irá executar
etc.
Cada estrutura permite analisar e projetar perspectivas diferentes do sistema, no
entanto isso não as torna independentes. É importante estabelecer relações entre elementos
de diferentes estruturas para entender como essas interações podem afetar o comporta-
mento da aplicação em tempo de execução, é possível assim prever problemas e estabelecer
estratégias para prevenção. Apesar de colaborar na construção de visões diferentes sobre
o software nem todos os projetos justificam a utilização de muitos modelos estruturais,
quanto maior o sistema mais complexa e diferente é a relação entre as estruturas, por-
tanto, seu projeto e documentação devem ser realizados tendo em vista o retorno sobre
investimento proporcionado por estas atividades, geralmente representado em termos de
menor tempo de desenvolvimento e menores custos de manutenção. (SOMMERVILLE,
2003; BASS; CLEMENTS; KAZMAN, 2012)

33. 32
O papel do arquiteto é orientar o projeto da arquitetura do sistema, seu conheci-
mento técnico é essencial para colaborar na seleção dos modelos e estruturas mais ade-
quados para compreender e documentar o software abrangendo os requisitos e guiando
o desenvolvimento. No entanto, as habilidades que o arquiteto deve apresentar vão além
da perspectiva técnica, habilidades como comunicação, negociação e conhecimento das
regras do negócio são igualmente importantes uma vez que seu envolvimento não está
focado somente no desenvolvimento, mas também na interação com clientes e pessoas
não-técnicas que possuem grande interesse e influência no projeto. (BASS; CLEMENTS;
KAZMAN, 2012)
Projetar a arquitetura do sistema ajuda a garantir o cumprimento de seu papel
em relação aos objetivos estabelecidos pelo negócio. Do ponto de vista técnico, Bass,
Clements e Kazman (2012) enumeram algumas razões para a execução desta atividade:
∙ A arquitetura possibilitará ou não as características de qualidade do sistema;
∙ As decisões tomadas durante o projeto da arquitetura permitirão a reflexão e o
gerenciamento das mudanças conforme o sistema evolui;
∙ A análise da arquitetura permite a previsão das qualidades do sistema;
∙ A documentação melhora a comunicação sobre o projeto;
∙ Define as primeiras, que são as mais fundamentais e difíceis decisões de projeto;
∙ Define as restrições sobre as implementações subsequentes;
∙ Dita a estrutura da organização, ou vice-versa;
∙ Pode prover os fundamentos para prototipação evolucionária;
∙ Permite ao arquiteto e ao gerente de projetos refletir sobre custo e cronograma;
∙ Pode se tornar o núcleo de uma linha de produtos na forma de um modelo transfe-
rível e reutilizável;
∙ Foca a atenção do desenvolvimento na montagem dos componentes e não somente
na construção;
∙ Restringe alternativas de projeto, canalizando esforços e reduzindo a complexidade
do sistema e do projeto;
∙ Pode ser a fundação para o treinamento de um novo membro da equipe.

34. 33
2.5.2 Arquitetura Cliente - Servidor
Segundo Sommerville (2003), Bass, Clements e Kazman (2012), este é um modelo
de sistema distribuído em que os dados e o processamento estão em diversos processadores.
Composto por um grande número de clientes que desejam acessar recursos e serviços
compartilhados, que por sua vez são geridos por um ou mais servidores e acessados através
de uma rede.
A ideia principal é extrair serviços comuns e centralizá-los em um local, ou um
pequeno número de locais. Desta forma é possível melhorar a escalabilidade e a disponibi-
lidade através da gestão centralizada dos recursos e sua distribuição através de múltiplos
servidores físicos. Os componentes podem ainda ser organizados em camadas de funcio-
nalidades relacionadas. (BASS; CLEMENTS; KAZMAN, 2012)
Algumas desvantagens que devem ser consideradas ao adotar este tipo de modelo
como a centralização dos recursos que pode transformar o servidor em um gargalo de
performance ou em um ponto único de falha; a separação de funcionalidades entre cliente
e servidor que pode se tornar complexa e sua mudança pode ter um alto custo após a
implementação. (BASS; CLEMENTS; KAZMAN, 2012)
A adoção do modelo cliente-servidor pode ser considerada nas seguintes situações:
aplicações com centenas ou milhares de clientes; aplicações e dados altamente voláteis;
integração de dados de múltiplas fontes. São exemplos do uso de arquitetura cliente-
servidor aplicações web onde o browser é o cliente e o servidor são componentes de um site
de comércio eletrônico; sistemas de informação em redes locais cujos clientes são aplicações
com interfaces gráficas para o usuário e o servidor são sistemas de gerenciamento de banco
de dados; sistemas bancários nos quais os clientes são os caixas eletrônicos e os servidores
são os componentes que fornecem os serviços financeiros. (SOMMERVILLE, 2003; BASS;
CLEMENTS; KAZMAN, 2012)
Um exemplo de arquitetura cliente servidor para um sistema bancário de caixas
eletrônicos pode ser visto na Figura 6.

35. 34
Figura 6 – Arquitetura cliente servidor para um sistema bancário de caixas eletrônicos
Fonte: Bass, Clements e Kazman (2012)
2.5.3 Sistemas de Informações Geográficas
As novas tecnologias permitiram diversos avanços nas formas como nos comunica-
mos, analisamos e tomamos decisões sobre nossos entornos. Informações sobre o mundo
real podem ser coletadas, processadas e apresentadas de maneira simplificada para cumprir
necessidades específicas. Tomar decisões sobre nosso meio ambiente requer informações
sobre locais específicos na superfície da Terra. Informações geográficas são assim chama-
das pois ajudam a distinguir um local do outro e possibilitam tomar ações específicas de
acordo com as condições de cada local, são portanto essenciais ao planejamento e processo
de decisão efetivos na sociedade moderna. (BERNHARDSEN, 2002)
Sistemas de informações geográficas (do inglês Geographic Information Systems -
GIS) são compostos de hardwares e softwares capazes de manipular informações geográfi-
cas para criar produtos derivados de mapas e ligar diversos elementos relacionados a esses
dados. Todos os dados inseridos em um GIS são geo-referenciados, ou seja, estão atrelados
a um local específico na superfície da Terra através de um sistema de coordenadas, dos
quais o mais comum é o composto por latitude e longitude. (BERNHARDSEN, 2002)
Diversas qualidades e características podem ser relacionadas a localidades, estes
atributos podem ser parâmetros físicos, como elevação da terra e temperatura, ou classifi-
cações como dados de proprietários, zoneamento etc. Em alguns casos estas propriedades
são atreladas a pontos, mas é possível estabelecer um relacionamento mais complexo
com linhas ou áreas, exemplos comuns são o mapeamento de lagos, cidades, ruas e rios.
(BERNHARDSEN, 2002)

36. 35
Uma visão geral da abrangência de sistemas de informações geográficas é apresen-
tada na Figura 7.
Figura 7 – GIS: Abrangência
Fonte: Bernhardsen (2002)
A capacidade do GIS de armazenar, processar e apresentar informações sobre o
relacionamento entre características, atributos e locais são algumas de suas funcionali-
dades mais poderosas. Frequentemente dados são processados e sobrepostos na forma de
mapas, tabelas ou formatos especiais que fornecem informações vitais sobre localidades
geográficas. (BERNHARDSEN, 2002)
Bernhardsen (2002) lista algumas aplicações de sistemas de informações geográfi-
cas: visualização e produção de mapas; análise de dados para otimização de sistemas de
transporte; sistema de informações sobre propriedades; sistema de gerenciamento de dis-
tribuição de encanamentos e cabeamentos; sistemas de planejamento de rodovias; sistemas
de navegação em terra e mar.
2.5.4 Linguagem de Modelagem Unificada (UML)
Segundo Booch, Rumbaugh e Jacobson (2005), existem limites para a capacidade
humana em compreender complexidades, sendo assim criamos modelos como uma forma
de simplificar a realidade e compreender melhor o sistema que está sendo desenvolvido.

37. 36
A UML (Unified Modeling Language) é uma linguagem padrão de modelagem cri-
ada para visualizar, especificar, construir e documentar artefatos de um sistema complexo
de software. Esta ferramenta provê um conjunto de estruturas que permite a descrição de
características conceituais como processos de negócio, requisitos e casos de uso; e itens
concretos como estruturas de classes, módulos e componentes a serem implantados. Não
está entre os objetivos da UML especificar quais estruturas criar e quando criar, papel
este que deve ser cumprido pelo processo de desenvolvimento de software o que torna
esta uma linguagem flexível que pode ser utilizada com quaisquer tipos de processos.
(BOOCH; RUMBAUGH; JACOBSON, 2005)
De acordo com Booch, Rumbaugh e Jacobson (2005), são definidos basicamente
três tipos de blocos de construção:
∙ Itens: elementos básicos que permitem a criação de modelos de abstração unitários,
podem ser estruturais, comportamentais, de agrupamento ou anotacionais;
∙ Relacionamentos: componentes que permitem definir o significado da relação entre
os diversos itens, podem definir dependências, associações, generalizações ou reali-
zações;
∙ Diagramas: uma representação gráfica de um conjunto de itens e relacionamentos
que permite a visualização de perspectivas diferentes do projeto do sistema. São
ao todo treze diagramas: de classes, de objetos, de componentes, de estrutura com-
posta, de casos de uso, de sequência, de comunicação, de estado, de atividades, de
implantação, de pacotes, de temporização, de visão geral de interação.
2.6 Tecnologias em Desenvolvimento de Software
O desenvolvimento de software consiste na transformação das especificações do
projeto em um sistema funcional. Esta etapa envolve a programação dos componentes
de software por um desenvolvedor que traduz todas as diretrizes presentes no projeto
em instruções compreensíveis ao computador, a utilização de ferramentas e frameworks
auxiliares tornam o trabalho deste profissional mais rápido, produtivo e criativo. (SOM-
MERVILLE, 2003)
Esta seção trata das linguagens e frameworks que apoiam o desenvolvimento dos
componentes de software que fazem parte da solução proposta neste projeto.
2.6.1 Java
Linguagem de programação criada em meados dos anos 90 pela empresa Sun Mi-
crosystems (adquirida pela Oracle em 2009), originalmente chamava-se Oak e foi criada

38. 37
por Patrick Naughton, Mike Sheridan, e James Gosling. Se enquadra no paradigma de
linguagens orientadas à objetos, é independente de plataforma, sua estrutura sintática e
semântica foram adaptadas de outra linguagem a C++. (REESE, 2012)
Na época de seu lançamento, Java foi bastante inovador por prover funcionalidades
com alta qualidade e facilidade de uso diretamente no framework da linguagem como thre-
ading, comunicação por redes e segurança. Uma de suas características mais interessantes
é a utilização de uma linguagem de máquina para uma arquitetura própria (chamada de
bytecode Java) que é interpretada e executada pela Java Virtual Machine (JVM), essa
decisão de projeto teve como objetivo tornar as aplicações desenvolvidas em Java inde-
pendentes de plataforma, sendo que somente a implementação da máquina virtual varia
dependendo da arquitetura. (REESE, 2012)
A evolução da linguagem e de suas ferramentas de desenvolvimento permitiram a
criação de diferentes tipos de aplicação e contribuíram para sua utilização em diversas
áreas. Reese (2012) apresenta uma lista dos tipos de aplicação que podem ser desenvolvidas
em Java:
∙ Aplicações desktop para console e com interfaces gráficas;
∙ Aplicações web baseadas em servidores e suportadas por Servlets, Java Server Pages
Java Server Faces e outros padrões da Java Enterprise Edition (JEE);
∙ Applets que executam dentro do browser;
∙ Aplicações embarcadas;
∙ Componentes reutilizáveis com JavaBeans.
2.6.2 Spring Framework
Um modelo de programação e configuração, além de um framework de ferramentas,
para o desenvolvimento de aplicações Java Enterprise. Sua principal característica é seu
suporte estrutural para a construção da aplicação, seu foco é fornecer funcionalidades
de apoio de alta qualidade para que os times de desenvolvimento possam se preocupar
somente com a implementação das regras de negócio. Spring possui suporte a implantação
em diversos tipos de plataforma, possui projeto modular e pode ser adotado de maneira
incremental ou através da adoção de componentes individuais. (GOPIVOTAL INC., 2013)
Em GoPivotal Inc. (2013) é possível encontrar algumas de suas características:
∙ Sistema de injeção de dependência flexível com configuração via XML (eXtensible
Markup Language) ou anotações;

39. 38
∙ Suporte avançado a programação orientada a aspectos;
∙ Suporte à transações declarativas, caching declarativo, validação declarativa e for-
matação declarativa;
∙ Abstrações para utilizar frameworks JEE como Java Database Conector, Java Per-
sistence API, Java Transactions API e Java Messaging Services;
∙ Suporte a frameworks de código aberto como Hibernate e Quartz;
∙ Framework web flexível para a criação de aplicações e serviços baseados em RESTful
MVC (Representational State Tranfer Model-View-Controller);
∙ Facilidades e ferramentas para o desenvolvimento de testes unitários e de integração.
2.6.3 Javascript Objects Notation (JSON)
JSON é um formato leve de troca de dados, sua estrutura foi baseada em um
subconjunto da linguagem de programação JavaScript especificada pelo padrão ECMA
(2011). Seu formato é facilmente manipulável por seres humanos e máquinas, é baseado
em texto e completamente independente de linguagem de programação, apesar de utilizar
convenções parecidas com as presentes em linguagens da família C. (INTRODUCING. . . ,
2013)
Segundo a definição em Introducing. . . (2013), o formato é baseado em duas es-
truturas: coleções de pares de nome e valor; e listas ordenadas de valores. Estas estruturas
são definidas da seguinte forma:
∙ Objetos: conjunto desordenado de pares nome e valor. Iniciado com abertura de
chaves e finalizado com fechamento de chaves, nomes e valores são separados por
dois pontos e os pares separados por vírgulas;
∙ Arrays: coleção ordenada de valores. Iniciado com abertura de colchetes e finalizado
com fechamento de colchetes, valores são separados por vírgulas;
∙ Valores: podem ser texto entre aspas duplas, um número, true, false, null, um objeto
ou array.
∙ String: sequência de zero ou mais caracteres Unicode;
∙ Número: Representação numérica em formato decimal (octal e hexadecimal não são
utilizados);
∙ Espaços em branco: podem ser inseridos em qualquer ponto da notação, geralmente
utilizados para melhorar a legibilidade.

40. 39
Uma extensão ao JSON relevante para este trabalho é o Geospacial JSON. Segundo
sua especificação em Butler et al. (2008), este é um formato de troca de dados geoespaciais
que permite em seu formato a adição de estruturas de dados geográficos como pontos,
linhas, polígonos, coleções geométricas, e ainda propriedades que servem para enriquecer
o nível de informações sobre os dados geográficos.

41. 40
3 Oportunidade
Nos capítulos 1 e 2 foram apresentados os conceitos relacionados a gestão da pa-
vimentação viária e como a qualidade da superfície das vias pode impactar significativa-
mente o dia-a-dia e a saúde dos cidadãos. As técnicas de gerenciamento de pavimentos
e o estudo do conforto em veículos auxiliam a compreensão dos efeitos do desgaste das
vias sobre os veículos e seus passageiros, além de propor sistemáticas para que os gestores
desta infraestrutura possam planejar e atuar no momento mais adequado para prevenir
que o estado destas vias atinja um nível crítico e prejudicial.
Os métodos documentados por Causim (2001 apud HAAS; HUDSON; ZANI-
EWSKI, 1994), Shahin (1994) e a norma brasileira DNIT (2011) determinam que a coleta
contínua de informações sobre a condição atual da pavimentação viária é um procedimento
importante para garantir que o SGP possua dados atualizados. Desta forma, torna-se
possível estimar a qualidade de um determinado trecho de pavimento, planejar sua ma-
nutenção, otimizar o uso de recursos públicos e mitigar os efeitos causados pela aparição
de defeitos em sua superfície.
Apesar da importância da atividade de coleta, a pesquisa de Lima, Ramos e Junior
(2006) aponta que, em cidades médias brasileiras, 60% das prefeituras avalia as condições
da pavimentação somente quando há solicitação da população; 60% destas cidades utiliza
algum SGP e, no entanto, apenas 12% realiza a atualização dos levantamentos de campo
e avaliação dos pavimentos; menos da metade das prefeituras utiliza um método formal
específico para selecionar vias para a manutenção, sendo que apenas 20% delas utiliza a
análise da condição da pavimentação para este fim.
São diversas as dificuldades enfrentadas pela gestão pública para manter uma base
de informações atualizada sobre as vias sob sua gestão, ainda no trabalho de Lima, Ramos
e Junior (2006) conclui-se que a falta de recursos e a ausência de uma política formal para
gestão do sistema viário contribuem para o desperdício de recursos técnicos e financeiros.
Lima, Ramos e Junior (2006) ainda complementam que, apesar dos avanços tecnológicos,
na maioria das cidades brasileiras não são aplicados procedimentos específicos para avaliar
a necessidade de manutenção e restauração dos pavimentos; na maioria dos casos os órgãos
públicos municipais desconhecem a real condição dos pavimentos atuando reativamente
na solução de problemas; e finalmente, os recursos técnicos especializados são escassos
e utilizados com pouco, ou nenhum planejamento, geralmente para suprir necessidades
extremas de reparo.
Portanto a baixa taxa de uso da análise do estado da pavimentação viária, ali-
ada a sua relevância e restrições de recursos, no auxílio a efetiva gestão da condição e

42. 41
manutenção da capacidade funcional das vias públicas, abre espaço para o desenvolvi-
mento de uma solução que tenha como foco uma abordagem diferente das existentes, no
entanto complementar, que colabore na coleta de dados e por consequência na melhoria
do processo de gestão de pavimentos.

43. 42
4 Proposta
O processo para coleta de informações sobre o estado atual da pavimentação viária
está intimamente relacionado com o destino dos dados obtidos, e, como visto em capítulos
anteriores, à partir deles podem ser derivados indicadores que representem a capacidade
da via em exercer sua função. No Brasil as normas (DNIT, 2003) e DNER (1994b),
que descrevem os indicadores VSA e IRI apresentados no capítulo 2, detalham que os
procedimentos de coleta de dados devem ser executados por equipes especializadas com
equipamentos preparados e calibrados especificamente para este fim.
As restrições de recursos humanos e financeiros destacados por Lima, Ramos e
Junior (2006) tornam-se uma barreira às medições utilizando recursos especializados, uma
vez que se torna cada vez mais difícil disponibilizá-los e desenvolvê-los em quantidade
suficiente para abranger adequadamente, e com maior frequência, a quantidade de vias
nas cidades.
A proposta do presente trabalho utiliza os conceitos de sensoriamento participativo
no desenvolvimento de uma aplicação orientada ao ambiente para possibilitar a participa-
ção de pessoas não especialistas no processo de coleta. Com o aumento de participantes
nesta atividade pode-se aumentar a abrangência geográfica e a frequência das medições,
otimizando portanto o uso de recursos especializados reservando-os a momentos e locais
onde são mais necessários.
O conceito de sensoriamento participativo orientado ao ambiente foi escolhido pois
possibilita a simplificação dos equipamentos de medição com a sugestão do uso de uma
aplicação para um smartphone, pertencente a um usuário voluntário, capaz de utilizar os
recursos disponíveis neste dispositivo para monitorar informações relevantes do ambiente e
enviá-las a um servidor para serem processadas posteriormente; além de motivar o cidadão
comum a participar voluntariamente do processo de coleta, aumentando não somente o
volume e frequência dos dados mas também sua relevância em relação ao dia-a-dia dos
usuários da infraestrutura viária.
Uma visão de alto nível da solução proposta está representada na Figura 8, na
qual o procedimento de coleta está divido em três etapas:
1. Coleta de informações é o cumprimento das atividades de recolhimento de dados
pelos usuários voluntários. Pode ocorrer basicamente de duas formas:
a) Em um veículo, a solução pode ser ativada para obter dados quantitativos atra-
vés do registro da aceleração causada pelas imperfeições da via sobre o veículo e

44. 43
transmitidas aos sensores do smartphone. Além disso, podem ser obtidos dados
qualitativos, como a opinião do usuário sobre o trajeto percorrido;
b) A pé, a solução pode ser utilizada para recolher dados qualitativos como a
opinião do usuário sobre a via observada e imagens de irregularidades e buracos;
2. Transmissão de dados, na qual é realizada o envio das informações à próxima etapa
utilizando os recursos de conectividade disponíveis no smartphone;
3. Processamento e Armazenamento, que consiste no recebimento e persistência dos
dados para posterior disponibilização a outros serviços.
Figura 8 – Proposta: Visão geral
Nas próximas seções serão detalhadas as funcionalidades e a arquitetura utilizadas
como referência para a construção da solução.
4.1 Escopo e Requisitos
Compreende projeto e desenvolvimento do protótipo de uma solução de sensoria-
mento participativo orientada ao ambiente composta de duas aplicações:
∙ Aplicação cliente para smartphone: utilizada pelos usuários para coletar as informa-
ções sobre a pavimentação e enviá-las a um servidor;
∙ Aplicação servidor: responsável pelo recebimento, armazenamento e posterior dis-
ponibilização dos dados coletados.

45. 44
Para atingir o objetivo proposto a solução deverá realizar os requisitos abaixo
detalhados.
4.1.1 Dados quantitativos e qualitativos sobre a pavimentação
O objetivo principal da solução é coletar informações que possam ser utilizadas na
análise da condição do pavimento. Portanto é necessário definir a natureza dos dados a
serem coletados de maneira a guiar os requisitos funcionais que definem quando e como
a coleta será realizada.
Os dados qualitativos a serem coletados são:
∙ Opinião do usuário em relação a qualidade da pavimentação do percurso realizado,
possibilitando a atribuição de uma nota que deverá variar de 0 (péssimo) à 5 (exce-
lente). Essa informação permite a criação de indicadores como o VSA (apresentado
no capítulo 2);
∙ Fotografias do estado atual do pavimento ou de um defeito específico, para posterior
análise por um especialista em uma possível priorização de manutenção.
Já os dados quantitativos são extraídos da leitura da aceleração dos eixos X, Y e
Z obtidos do acelerômetro do dispositivo, em 𝑚/𝑠2
, durante um trajeto percorrido pelo
veículo do usuário. Estes dados são a informação bruta que pode ser utilizada na derivação
de indicadores como o IRI e índices de conforto (apresentados no capítulo 2);
Deve-se atentar também para os dados que permitem a contextualização e a loca-
lização das informações sobre o pavimento no tempo e espaço:
∙ Posicionamento informados pelo módulo de GPS do dispositivo expressos em lati-
tude e longitude;
∙ Dados temporais expressos em milissegundos à partir de 1 de Janeiro de 1970
00:00:00.0 UTC, para fácil conversão.
Essas definições devem ser utilizadas como referência em todo o projeto.
4.1.2 Coleta de dados durante um trajeto
Deverá ser possível ao usuário efetuar a coleta de dados durante um percurso com
seu veículo. Para isso o smartphone deverá ser posicionado sobre o painel do veículo com
a face voltada para cima, o usuário poderá então acionar um comando na aplicação para
iniciar a coleta de dados antes de começar seu trajeto, e ao final do percurso o usuário
deverá acionar um comando para interromper a coleta, armazenar e enviar os dados.

46. 45
Os dados a serem coletados são as leituras de aceleração durante todo o trajeto;
dados de posicionamento durante o trajeto, basicamente as variações de latitude e longi-
tude que ocorreram durante a movimentação; a opinião do usuário em relação a qualidade
da pavimentação do percurso realizado; e, dados temporais.
A coleta destas informações permite sua correlação e contextualização através da
criação de uma camada de dados que pode ser sobreposta a mapas que permitam a
análise de dados de regiões específicas, conforme proposto por sistemas de informações
geográficas. Por fim, a opinião do usuário serve como informação qualitativa que provê a
perspectiva e expectativa do usuário em relação à via durante o trajeto.
4.1.3 Coleta de dados sobre uma via específica
Deverá ser possível ao usuário informar sua opinião sobre a qualidade da pavi-
mentação de uma via específica. Ao ser selecionada esta opção o sistema deverá exibir
a localização atual do usuário e permitir que ele avalie a condição do pavimento. Serão
armazenadas as informações de posicionamento no momento da coleta, opinião do usuário
em relação a qualidade da pavimentação no local da coleta e dados temporais.
Entende-se que a manutenção ou restauração de uma via que tem mais avaliações
negativas por um número maior de usuários terá um impacto positivo muito maior. Dessa
forma, coletar a opinião do usuário possibilita estimar o impacto do estado atual da via
para usuário final, pretende-se desta forma disponibilizar mais uma ferramenta que auxilie
o processo de escolha de vias para manutenção.
4.1.4 Coleta de dados sobre um defeito específico
Deverá ser possível ao usuário registrar informações sobre um defeito específico
encontrado em uma via. Ao utilizar esta opção o sistema deverá exibir a localização atual
do usuário, permitir que seja obtida uma fotografia e a avaliação qualitativa do defeito. As
informações armazenadas são os dados de posicionamento no momento da coleta, opinião
do usuário em relação ao defeito em questão e dados temporais.
O registro de defeitos específicos permite a identificação de problemas de critici-
dade mais alta que possam necessitar de atenção imediata, além de possibilitar a análise
do problema por um especialista sem seu deslocamento até o local.
4.1.5 Visualização de dados coletados
O sistema deverá disponibilizar uma interface para o usuário visualizar as infor-
mações que já foram coletadas. Os dados deverão ser sobrepostos a um mapa da região
onde o usuário se encontra no momento. Cada tipo de informação poderá ser visualizada
de maneira diferente:

47. 46
∙ Defeitos específicos terão suas localizações apontadas no mapa por marcadores que
ao serem selecionados exibirão todos as informações referentes ao defeito;
∙ As avaliações qualitativas enviadas pelos usuários serão utilizadas para determinar
o índice VSA dos trechos de vias e sua representação gráfica deverá ser colorida
de acordo com o resultado: verde (Excelente), azul (Bom), amarelo (Regular), rosa
(Ruim) e vermelho (Péssimo);
∙ Os dados de aceleração coletados não deverão ser exibidos nesta interface pois exi-
gem um pós-processamento mais complexo para se derivar indicadores que sejam
mais relevantes aos usuários.
O principal objetivo deste requisito é propiciar transparência aos usuários sobre
as condições atuais das vias de sua localidade. As mesmas informações disponibilizadas
aos administradores estará visível aos cidadãos que colaboraram no processo de coleta,
possibilitando uma participação mais efetiva da população no processo de gestão das vias.
4.1.6 Disponibilização de dados através de serviços Web
Todos os dados coletados deverão ser disponibilizados através de serviços abertos
que deverão receber como parâmetro um endereço ou intervalo de coordenadas geográficas
(latitude e longitude inicial, e latitude e longitude final), o tipo de informação que deseja-
se obter (dados de aceleração, defeitos ou opiniões dos usuários) e um período de tempo
(data inicial e data final). A resposta da solicitação deverá conter todas as informações
coletadas que atendam aos parâmetros informados, deve-se considerar que quando um
parâmetro for informado em branco todas as informações relativas ao mesmo deverão ser
retornadas.
4.1.7 Otimização do uso de conexão de dados
É comum que, quando ao ar livre ou nas ruas, os usuários de smartphones estejam
conectados a redes de dados disponibilizadas pelas operadoras de celular que limitam a
velocidade e a quantidade de informação que podem ser utilizadas de acordo com o serviço
contratado pelo usuário. Esse tipo de dispositivo normalmente possui mais de um tipo de
conexão, é importante portanto que a aplicação transmita as informações aos servidores
somente quando um tipo de conexão mais adequada (como o Wi-Fi) estiver disponível de
maneira a preservar os recursos contratados pelo usuário.
4.1.8 Sistema operacional do smartphone
A aplicação cliente deverá ser desenvolvida para o sistema operacional Android
devido a sua grande presença no mercado de smartphones, disponibilidade de dispositivos

48. 47
em diversas faixas de preços e grande número de funcionalidades. Essas características
garantem uma grande abrangência geográfica e a disponibilidade dos recursos tecnológicos
necessários à aplicação.
4.1.9 Uso de ferramentas e serviços livres e/ou gratuitos
De maneira a otimizar os recursos financeiros na construção do protótipo deve-se
selecionar apenas ferramentas e serviços que sejam livres ou que possuam versões sem
custo.
4.1.10 Restrições
Durante o processo de análise de requisitos foram identificadas algumas restrições
que não poderão ser tratadas no decorrer deste trabalho devido as restrições de tempo e
escopo:
∙ Orientação do dispositivo: os dados de aceleração são coletados de todos os eixos,
mudanças de orientação podem causar um desalinhamento entre planos de coor-
denadas do dispositivo e do veículo. Seria necessário desenvolver e aplicar técnicas
para responder adequadamente a essas mudanças.
∙ Precisão dos dados coletados: é importante ressaltar que a precisão dos sensores
disponíveis é sensivelmente inferior a de equipamentos especiais calibrados em la-
boratório o que pode causar discrepâncias nos dados coletados.
∙ Coleta em diferentes tipos de veículos: podem causar distorções uma vez que cada
tipo de veículo possui componentes e estrutura diferentes, se faz necessário desen-
volver e aplicar métodos que permitam lidar com essas diferenças.
∙ Não serão abordadas neste projeto aplicações que façam a análise dos dados coleta-
dos, esta possibilidade pode ser exploradas em trabalhos posteriores.
4.2 Especificação
Os requisitos de software são apresentados de uma maneira mais abstrata, em
uma linguagem mais próxima e compreensível aos usuários. A especificação aprimora os
requisitos enriquecendo o nível de detalhes e os aproxima do projeto da arquitetura e da
implementação. Neste ponto é importante criar modelos que descrevam o que o sistema
deverá fazer e não como fazê-lo. (SOMMERVILLE, 2003)
Para a criação da especificação foi selecionado o modelo de casos de uso, que apre-
senta descrições de conjuntos de ações e interações entre o sistema e seus usuários que,

49. 48
quando executados, produzem algo de valor ao usuário final. Nesta forma de representa-
ção, os papéis desempenhados pelos usuários são apresentados na forma de atores e são
entidades externas ao sistema; já o caso de uso descreve todos os passos e atividades rea-
lizadas durante a interação entre sistema e ator. (BOOCH; RUMBAUGH; JACOBSON,
2005)
Sendo assim, na Figura 9 é apresentado o diagrama de casos de uso para a solução
proposta, e na sequência estão descritos os detalhes de cada um dos itens do diagrama.
Figura 9 – Diagrama de casos de uso

50. 49
4.2.1 Coletar dados sobre um defeito
Descrição:
Permite aos atores registrar dados qualitativos sobre um defeito de pavimentação
específico que se queira relatar.
Atores:
Pedestre, Motorista
Pré-Condições:
∙ O sistema de GPS do dispositivo deve estar ativo.
∙ Uma conexão de dados deve estar ativa.
∙ O dispositivo deve possuir câmera.
Resultados:
Os dados coletados devem estar registrados na base de dados e disponíveis para
consulta.
Descrição do processo:
1. O ator ativa a opção de registrar dados sobre um defeito.
2. O sistema obtém a localização do ator e a informa ao ator.
3. O sistema obtém as informações temporais da coleta.
4. O sistema solicita a entrada de uma fotografia e a avaliação.
5. O ator captura uma fotografia do defeito.
6. O ator seleciona uma nota entre 1 e 5 para avaliação.
7. O ator confirma a coleta.
8. O sistema executa o caso de uso Transmitir dados e informa o resultado ao
ator.
Exceções, erros e situações especiais:
∙ O ator poderá cancelar a operação a qualquer momento.
∙ Antes da confirmação do envio o ator poderá alterar sua avaliação e fotografia
captura a qualquer momento.
∙ Se não for possível obter localização, o sistema informa o usuário e encerra o
caso de uso sem efetuar a coleta.
∙ Caso o dispositivo não possua câmera, o sistema informa o usuário e encerra o
caso de uso sem efetuar a coleta.
∙ Se a conexão de dados estiver indisponível, o sistema informa o usuário e ar-
mazena as informações localmente para envio posterior.

51. 50
4.2.2 Coletar dados sobre uma via
Descrição:
Permite a avaliação qualitativa espontânea de uma via por qualquer ator do sistema.
Atores:
Pedestre, Motorista
Pré-Condições:
∙ O sistema de GPS do dispositivo deve estar ativo.
∙ Uma conexão de dados deve estar ativa.
Resultados:
Os dados coletados devem estar registrados na base de dados e disponíveis para
consulta.
Descrição do processo:
1. O ator ativa a opção de avaliar uma via.
2. O sistema obtém a localização do ator e a informa ao ator.
3. O sistema obtém as informações temporais da coleta.
4. O sistema solicita a entrada da avaliação.
5. O ator seleciona uma nota entre 1 e 5 para avaliação.
6. O ator confirma a coleta.
7. O sistema executa o caso de uso Transmitir dados e informa o resultado ao
ator.
Exceções, erros e situações especiais:
∙ O ator poderá cancelar a operação a qualquer momento.
∙ Antes da confirmação do envio o ator poderá alterar sua avaliação a qualquer
momento.
∙ Se não for possível obter localização, o sistema informa o usuário e encerra o
caso de uso sem efetuar a coleta.
∙ Se a conexão de dados estiver indisponível, o sistema informa o usuário e ar-
mazena as informações localmente para envio posterior.

52. 51
4.2.3 Coletar dados em um trajeto
Descrição:
Viabiliza a coleta de dados quantitativos sobre a superfície da pavimentação da via,
além da avaliação qualitativa do usuário sobre o trajeto.
Atores:
Motorista
Pré-Condições:
∙ O sistema de GPS do dispositivo deve estar ativo.
∙ Uma conexão de dados deve estar ativa.
∙ O dispositivo deve estar posicionado com a tela para cima sobre o console do
veículo.
Resultados:
Os dados coletados devem estar registrados na base de dados e disponíveis para
consulta.
Descrição do processo:
1. O ator solicita ao sistema que inicie a coleta.
2. Enquanto o ator não solicita o fim da coleta.
a) O sistema obtém uma atualização da posição.
b) O sistema informa ao ator o trajeto percorrido até o momento.
c) O sistema coleta as informações de aceleração dos eixo X, Y e Z do dispo-
sitivo.
d) O sistema obtém as informações temporais.
e) O sistema registra localmente todas as informações coletadas até o mo-
mento.
3. Ator solicita o fim da coleta.
4. O sistema solicita a avaliação do trajeto.
5. O ator seleciona uma nota entre 1 e 5 para avaliação.
6. O ator confirma a coleta.
7. O sistema executa o caso de uso Transmitir dados e informa o resultado ao
ator.
Exceções, erros e situações especiais:
∙ O ator poderá encerrar a operação a qualquer momento.

53. 52
∙ Se não for possível obter localização, o sistema informa o usuário e encerra o
caso de uso sem efetuar a coleta.
∙ Se a conexão de dados estiver indisponível, o sistema informa o usuário e ar-
mazena as informações localmente para envio posterior.
4.2.4 Transmitir dados
Descrição:
Envia os dados informados ao servidor.
Atores:
Outros casos de uso.
Pré-Condições:
∙ Uma conexão de dados deve estar ativa.
Resultados:
Os dados transmitidos devem ser recebidos e persistidos pela aplicação servidor.
Descrição do processo:
1. Monta a mensagem para envio ao servidor com as informações recebidas.
2. A aplicação cliente efetua uma chamada ao serviço de armazenagem da apli-
cação servidor informando a mensagem montada no passo 1.
3. A aplicação servidor executa o caso de uso Armazenar dados e informa o re-
sultado a aplicação cliente.
4. O caso de uso encerra com o envio do código de retorno (falha ou sucesso) ao
caso de uso ator.
Exceções, erros e situações especiais:
∙ Se a conexão de dados estiver indisponível, o sistema informa o usuário e ar-
mazena as informações localmente para envio posterior.
∙ Se houver perda de conexão durante a transmissão o caso de uso é encerrado
com erro.
∙ Se o serviço estiver indisponível o caso de uso é encerrado com erro.
4.2.5 Visualizar dados
Descrição:
Permite ao ator consultar os dados já coletados e submetidos ao sistema.

54. 53
Atores:
Pedestre, Motorista
Pré-Condições:
∙ Uma conexão de dados deve estar ativa.
Resultados:
Os dados devem ser exibidos ao ator.
Descrição do processo:
1. O ator solicita a visualização dos dados.
2. A aplicação cliente obtém a localização do ator e a informa ao ator.
3. A aplicação cliente solicita os dados já cadastrados à aplicação servidor pas-
sando como parâmetro a localização do ator.
4. A aplicação servidor executa o caso de uso Consultar dados e informa o resul-
tado à aplicação cliente.
5. A aplicação cliente disponibiliza os dados ao ator.
Exceções, erros e situações especiais:
∙ Se a conexão de dados estiver indisponível o sistema informa o ator e o caso
de uso é encerrado com erro.
∙ Se houver perda de conexão durante a transmissão o sistema informa o ator e
o caso de uso é encerrado com erro.
∙ Se o serviço estiver indisponível o sistema informa o ator e o caso de uso é
encerrado com erro.
4.2.6 Visualizar dados não transmitidos
Descrição:
Possibilita ao ator a consulta e re-transmissão de dados que por motivos de conec-
tividade não puderam ser enviados à aplicação servidor antes.
Atores:
Pedestre, Motorista
Pré-Condições:
∙ Uma conexão de dados deve estar ativa.
Resultados:

55. 54
∙ Exibição ao ator de uma lista com os dados coletados que ainda não foram
transmitidos.
∙ Em caso de re-transmissão os dados, estes devem estar registrados na base de
dados e disponíveis para consulta.
Descrição do processo:
1. O ator solicita a visualização de dados não transmitidos.
2. O sistema lista todas as coletas realizadas e não enviadas ao servidor em uma
lista.
3. Se o ator desejar re-enviar os dados:
a) O ator seleciona um ou mais itens que deseja reenviar.
b) O sistema recarrega os dados selecionados.
c) O sistema executa o caso de uso Transmitir dados e informa o resultado
ao ator.
Exceções, erros e situações especiais:
∙ O ator poderá encerrar a operação a qualquer momento.
∙ Se a conexão de dados estiver indisponível, o sistema informa o usuário e man-
tém as informações localmente para envio posterior.
4.2.7 Consultar dados
Descrição:
Fornece um serviço de consulta às informações já coletas pelos usuários.
Atores:
Aplicação Cliente, Sistemas de Gerenciamento de Pavimentos (SGP)
Pré-Condições:
1. Deve haver conexão com a internet.
2. Deve haver dados cadastrados na base de dados.
Resultados:
Os dados solicitados são retornados de acordo com os parâmetros informados.
Descrição do processo:
1. O ator solicita dados informando uma localização (latitude e longitude) e um
raio (em metros).
2. O sistema consulta a base de dados com os parâmetros informados.

56. 55
3. O sistema cria uma mensagem de retorno com os dados selecionados.
4. A mensagem de retorno é enviada ao ator.
Exceções, erros e situações especiais:
∙ Se não houver dados é retornada uma mensagem vazia.
∙ Em caso de perda de conexão a resposta a ser enviada é descartada.
∙ Em caso de parâmetros inválidos é retornada uma mensagem vazia.
4.2.8 Armazenar dados
Descrição:
Fornece um serviço para armazenamento de informações já coletas pelas instâncias
das aplicações cliente.
Atores:
Aplicação Cliente
Pré-Condições:
Deve haver conexão com a internet.
Resultados:
Os dados enviados são persistidos na base de dados.
Descrição do processo:
1. O ator envia uma mensagem contendo as informações coletadas.
2. O sistema cria um documento com base na mensagem recebida.
3. O sistema armazena o documento na base de dados.
4. É enviado um código de sucesso ao ator.
Exceções, erros e situações especiais:
∙ Se a mensagem recebida estiver vazia é retornado sucesso.
∙ Em caso de perda de conexão a resposta a ser enviada é descartada.
∙ Em caso de mensagem recebida inválida é retornado um código de erro.
4.3 Arquitetura
Conforme visto no capítulo 2, a arquitetura de software tem papel importante na
criação do vínculo entre a especificação funcional e as tecnologias a serem utilizadas na
implementação do sistema. Nesta etapa serão criados diversos modelos que representam

57. 56
visões diferentes da solução a ser desenvolvida, possibilitando a decomposição e organiza-
ção do sistema em módulos, a análise de aspectos dinâmicos e estruturais e o cumprimento
dos requisitos e casos de uso especificados na etapa anterior.
Para esta solução será adotada uma arquitetura cliente servidor, conforme sugerido
por Kanhere (2011), uma vez que para cumprir o objetivo proposto é necessário utilizar
uma aplicação para coletar as informações e outra para centralizar e servir os dados
coletados.
A estrutura cliente servidor adotada neste projeto está descrita no diagrama de
implantação representado na Figura 10 abaixo:
Figura 10 – Diagrama de implantação
A solução será composta por dois artefatos principais: a aplicação cliente Bura-
queira.apk e a aplicação servidor BuraqueiraServer.war, e ainda um terceiro artefato que
representa o repositório onde os dados coletados serão armazenados. Nas seções seguintes
a estrutura interna e os papéis de cada um destes componentes serão detalhados.
4.3.1 Aplicação Cliente
Batizada de Buraqueira, a aplicação cliente tem como principal objetivo fornecer
aos usuários as funcionalidades relacionadas à coleta de dados. Para tanto neste artefato
deverão ser implementados os casos de uso: Coletar dados sobre um defeito, Coletar dados
em um trajeto, Coletar dados sobre uma via, Transmitir dados e Visualizar dados não
transmitidos.
Para a implementação desta aplicação será utilizada a linguagem de programação

58. 57
Java em conjunto com as APIs da plataforma Android, além de alguns outros componen-
tes selecionados para acelerar o processo de desenvolvimento.
4.3.1.1 Interfaces para o Usuário
As interfaces para os usuários são responsáveis por fornecer formas de interação que
permitam ao usuário usufruir das funcionalidades da aplicação e do dispositivo em uso.
Para a prova de conceito proposta foi idealizado um conjunto de interfaces que permitam
que o usuário execute com poucos toques as atividades de coleta de informações. Na
Figura 11 esta representado o fluxo de navegação através das interfaces da aplicação
cliente.

59. 58
Figura 11 – Fluxo de interação com as interfaces para os usuários da aplicação cliente
4.3.1.2 Visão estrutural
Para melhor organizar e compreender os diversos elementos da aplicação Bura-
queira é apresentado o diagrama de componentes na Figura 12. Nele apresenta-se uma
visão de alto nível da aplicação na qual estão representadas suas dependências com outros
componentes, os serviços externos necessários a suas funcionalidades e sua organização
interna em pacotes.

60. 59
Figura 12 – Diagrama de componentes da aplicação Buraqueira
Os componentes externos foram escolhidos para acelerar o desenvolvimento adici-
onando funcionalidades essenciais:
∙ GSON: provê a funcionalidade de conversão de objetos Java em notação JSON e
vice versa;
∙ Spring Android REST e Core: facilitam a comunicação com a aplicação servidor
provendo formas de utilização simplificadas de chamadas a métodos HTTP que
permitem a transmissão dos dados coletados ao servidor;
∙ Google Play Services: contém diversas funcionalidades relacionadas aos serviços do
Google. Para a aplicação Buraqueira serão utilizas as funções de geolocalização do
serviço Google Mapas;
∙ Android Framework: com foco na plataforma Android, a aplicação deve ser cons-
truída de acordo com seus padrões, utilizando os controles e componentes disponibi-
lizados por sua API. As principais funcionalidades a serem acessadas são: construção
de interfaces para os usuários, acesso a sensores, acesso ao sistema de arquivos, com-
ponentes que permitem multitarefa e controle de permissões.

61. 60
No diagrama também especifica-se a necessidade de algumas interfaces externas.
Neste caso as interfaces definem funções que serão implementadas e providas pela aplica-
ção servidor. Espera-se que estas funcionalidades atendam às seguintes especificações:
∙ streetRatingHTTPPost: invocação de um método HTTP post no endereço streetRating
onde no corpo da mensagem HTTP será enviado um documento JSON no formato
GeoJSON contendo informações sobre a avaliação feita pelo usuário sobre uma via
específica.
∙ streetDefectRatingHTTPPost: invocação de um método HTTP post no endereço
streetDefectRating onde no corpo da mensagem HTTP será enviado um documento
JSON no formato GeoJSON contendo informações sobre a avaliação feita pelo usuá-
rio sobre um defeito encontrado em uma via.
∙ streetSurfaceDataHTTPPost: invocação de um método HTTP post no endereço
streetSurfaceData onde no corpo da mensagem HTTP será enviado um documento
JSON no formato GeoJSON contendo dados coletados pela aplicação durante o
trajeto realizado pelo usuário.
O detalhamento sobre os dados e formatos utilizados é feito na seção 4.3.1.3.
Nesta visão de componentes também optou-se por detalhar a organização interna
do artefato Buraqueira.apk representando os pacotes e componentes implementados para
a aplicação:
∙ buraqueira: pacote raiz contendo o ponto de entrada da aplicação.
∙ view: contém as implementações dos comportamentos das interfaces gráficas para
os usuários.
∙ utils: classes utilitárias.
∙ domain: implementações das classes que lidam com representações de dados rela-
cionados ao domínio da aplicação, como as avaliações coletadas dos usuários. Uma
característica importante é a utilização de um pacote interno para organização das
classes utilizadas na representação destas informações em formato GeoJSON.
∙ data: contém os serviços responsáveis pela coleta e transmissão de dados relevantes
para a aplicação como localização e aceleração do dispositivo.
Na Figura 13 está representada uma visão estrutural mais detalhada dos principais
componentes internos da aplicação Buraqueira.

62. 61
Figura 13 – Diagrama de classes da aplicação Buraqueira
De maneira geral as aplicações Android são centradas nas interações com usuários,
o tipo mais comum de componente é a Activity, ou atividade, na qual são implementadas
uma atividade unitária que pode ser realizada pelo usuário. No modelo estrutural acima
optou-se por utilizar uma atividade, a MainActivity como maneira de direcionar o usuário
para as ações que podem ser realizadas, este componente assume papel de ponto de en-
trada da aplicação o que o torna um bom candidato para inicializar os serviços executados
em segundo plano, nele ainda permite-se ao usuário iniciar a coleta de dados de acelera-
ção durante um trajeto. Outros componentes utilizados no controle da interface gráfica
são: CollectedDataToTransmitActivity responsável pela interface de listagem e re-envio
ao servidor de dados coletados, armazenados localmente e que ainda não foram trans-
mitidos ao servidor; DefectCollectionActivity controla a interface que permite ao usuário
coletar informações sobre um defeito específico na via; StreetRatingDialog disponibiliza
uma interface para classificação da via onde o usuário se encontra no momento.
Outro tipo de componente relevante na construção de aplicações em plataformas
Android é o Service, ou serviço, que permite a implementação de funcionalidades utilitárias
que são executadas em segundo plano. Este elemento da plataforma Android é utilizado
na aplicação Buraqueira para criar classes ativas que, uma vez iniciadas, controlam seu

63. 62
próprio fluxo de execução e possuem suas próprias Threads. Estes serviços são utilizados
para coleta, processamento e transmissão dos dados da aplicação. Algumas das razões
para o uso deste tipo de estrutura são: garantia da responsividade da interface gráfica
para o usuário, reduzir ao mínimo possível a perda de dados informados pelos sensores e
melhorar o aproveitamento da capacidade de processamento do dispositivo.
4.3.1.3 Visão dos dados
A aplicação Buraqueira lida com a coleta de dados e informações relevantes para a
solução, conforme definido anteriormente. Nesta seção será detalhada a modelagem destes
dados para utilização na aplicação cliente. O diagrama Figura 14 possui uma representação
da modelagem dos principais elementos.
Figura 14 – Diagrama de classes dos elementos de dados da aplicação Buraqueira
Com a utilização do formato GeoJSON para troca de informações entre a aplicação
cliente e servidor, optou-se por adotar um componente externo para efetuar a conversão
de objetos Java em notação JSON e vice versa. O processo, conhecido como marshalling e
unmarshalling, é feito utilizando o componente GSON. Para garantir a correta geração dos
dados em notação GeoJSON foi necessária a utilização de classes adicionais com variáveis
de classe que correspondessem ao formato de saída desejado. As classes adicionais foram
organizadas no pacote domain/gson e estão representadas no diagrama da Figura 15.

64. 63
Figura 15 – Diagrama de classes dos elementos GeoJSON
Identificou-se a necessidade de três documentos GeoJSON para atender aos requi-
sitos desta solução:
Avaliação de Vias específicas
Objeto em notação GeoJSON do tipo Feature utilizando um elemento Geometry
do tipo Point para armazenar o local onde foi feita a coleta da informação associado à
nota informada pelo usuário no campo userRating. A notação completa é definida como
abaixo:
1 {
2 " type " : " Feature " ,
3 " geometry " : {
4 " type " : " Point " ,
5 " coordinates " : [ ’ longitude ’ , ’ l a t i t u d e ’ ]
6 } ,
7 " pr op ert ie s " : {
8 " userRating " : ’ nota ’ ,
9 " timestamp " : ’ timestamp ’ ,
10 " dataType " : " street_rating "
11 }
12 }

65. 64
Avaliação de defeitos
Objeto em notação GeoJSON do tipo Feature utilizando um elemento Geometry
do tipo Point para armazenar o local onde o defeito foi encontrado e associá-lo à nota e
imagem informados pelo usuário. A notação completa é definida como abaixo:
1 {
2 " type " : " Feature " ,
3 " geometry " : {
4 " type " : " Point " ,
5 " coordinates " : [ ’ longitude ’ , ’ l a t i t u d e ’ ]
6 } ,
7 " pr op ert ie s " : {
8 " dataType " : " street_defect " ,
9 " userRating " : ’ nota ’ ,
10 " timestamp " : ’ timestamp ’ ,
11 " image " : "imagem em formato Base64 "
12 }
13 }
Dados de superfície de vias
Objeto em notação GeoJSON do tipo Feature utilizando um elemento Geometry
do tipo LineString para armazenar um trecho do trajeto percorrido em conjunto com as
informações coletadas do acelerômetro do dispositivo. Os dados de aceleração são arma-
zenados em um objeto especifico onde podem ser especificados os valores lidos em cada
eixo. Como em um único trecho são efetuadas diversas leituras os objetos com dados de
aceleração são armazenados em um array. A notação completa é definida como abaixo:
1 {
2 " type " : " Feature " ,
3 " geometry " : {
4 " type " : " LineString " ,
5 " coordinates " : [ [ ’ l o n g i t u d e I n i c i a l ’ , ’ l a t i t u d e I n i c i a l ’ ] , [
’ longitudeFinal ’ , ’ l a t i t u d e F i n a l ’ ] ]
6 } ,
7 " pr op ert ie s " : {
8 " dataType " : " street_surface_data " ,
9 " startTimestamp " : ’ timestamp ’ ,
10 " endTimestamp " : ’ timestamp ’ ,
11 " collectedSensorData " : [
12 {
13 " xAccel " : " valor da acel . no eixo X" ,
14 " yAccel " : " valor da acel . no eixo Y" ,
15 " zAccel " : " valor da acel . no eixo Z" ,
16 " timestamp " : ’ timestamp ’
17 }

66. 65
18 ]
19 }
20 }
Finalmente, para garantir que os dados não se percam, caso a transmissão ao
servidor não seja possível, foi necessário o uso de uma técnica de persistência. No caso
optou-se pela persistência simples dos documentos JSON em formato texto escritos em
arquivos na unidade de armazenamento do dispositivo. Entende-se que esta abordagem
é adequada ao protótipo por facilitar o desenvolvimento, no entanto no futuro seria in-
teressante a substituição por uma alternativa como bases de dados estruturada, base de
dados baseadas em documentos ou mesmo objetos serializados em arquivos.
4.3.1.4 Visão de tempo de execução
Este aspecto tem como objetivo explorar as características dinâmicas da aplicação
com modelos que representam a execução e a interação entre os principais componentes.
A principal ferramenta para esta análise é o diagrama de sequência da UML. Nesta visão
serão apresentados os fluxos principais de maneira à estabelecer uma relação com os casos
de uso propostos para esta solução e entender como são realizados pelos componentes da
aplicação.
O primeiro modelo na Figura 16 explora a execução bem sucedida do caso do uso
Coletar dados sobre uma via, no qual o usuário interage com a interface gráfica para
fornecer sua opinião sobre a via em que se encontra.
Figura 16 – Diagrama de sequência - Coleta bem sucedida da opinião do usuário sobre uma via
Na Figura 17 apresenta-se modelada a execução bem sucedida do caso de uso
Coletar dados sobre um defeito, no qual o usuário utiliza a câmera fotográfica disponível

67. 66
no dispositivo para coletar uma imagem e informar sua opinião sobre o defeito.
Figura 17 – Diagrama de sequência - Coleta bem sucedida da opinião do usuário sobre um defeito
específico
A execução do caso de uso mais complexo, Coletar dados em um trajeto, está
representada na Figura 18. Do ponto de vista do usuário a ativação desta funcionalidade é
simples, sua complexidade reside na interação com diversos elementos dinâmicos ao mesmo
tempo. Durante a execução temos a interação com dois serviços paralelos que coletam
de maneira independente a aceleração e a localização, após a sinalização do término da
coleta pelo usuário as informações são passadas à um terceiro serviço responsável pelo pós-
processamento e relacionamento dos trechos por onde o usuário passou e seus respectivos
dados de aceleração. Finalmente, o último serviço é utilizado para envio dos dados ao
servidor. O uso destes serviços em paralelo e em linhas de execução independentes é
importante para garantir a responsividade da interface gráfica e a recepção da leitura
informadas pelos sensores.

68. 67
Figura 18 – Diagrama de sequência - Coleta bem sucedida dos dados sobre a superfície do trajeto realizado
pelo usuário
Na Figura 19 apresenta-se a representação da execução do caso de uso Visuali-
zar dados não transmitidos que especifica o processo de disponibilização dos dados não
transmitidos e a tentativa de re-envio ao servidor.
Figura 19 – Diagrama de sequência - Visualização e re-envio de dados não transmitidos
Os modelos acima representados terminam com o envio dos dados ao servidor,
funcionalidade esta especifica no caso de uso Transmitir dados. Basicamente é utilizado um

69. 68
serviço em plano de fundo que se comunica com a aplicação servidor utilizando requisições
HTTP e tratando as respostas de acordo.
4.3.2 Aplicação Servidor
A aplicação Buraqueira Server exerce nesta solução o papel de software servidor
responsável por funcionalidades relacionadas à centralização, armazenamento e forneci-
mento dos dados já coletados. Portanto nela são implementadas os casos de uso: Arma-
zenar dados e Consultar dados.
Com o propósito de desenvolver a prova de conceito proposta para esta solução
será utilizada a linguagem de programação Java além de componentes selecionados que
colaborem na aceleração do processo de desenvolvimento.
4.3.2.1 Visão estrutural
Uma visão geral da organização estrutural da aplicação servidor é apresentada
no diagrama de componentes da Figura 20. Analogamente ao diagrama utilizado para a
aplicação cliente, neste também é possível identificar os principais pacotes, componentes
e interfaces fornecidas pela aplicação.

70. 69
Figura 20 – Diagrama de componentes da aplicação Buraqueira
Os componentes externos colaboram provendo funcionalidades complementares à
solução:
∙ GSON: O mesmo componente utilizado na aplicação cliente, provê a funcionalidade
de conversão de objetos Java em notação JSON e vice versa;
∙ Spring Framework: possui um conjunto de ferramentas e bibliotecas que permitem
o desenvolvimento rápido e robusto de aplicações Web em Java;
∙ Spring Data: provê funcionalidades para integração da aplicação com bases de dados,
no caso o MongoDB;
∙ MongoDB:base de dados de código aberto baseada no armazenamento de documen-
tos.
Na visão de componentes da Figura 20 também está representada a organização
interna da aplicação servidor com seus pacotes e componentes:

71. 70
∙ server: pacote raiz contendo os principais componentes da aplicação;
∙ config: classes de configuração do Spring Framework;
∙ gson: pacote com classes auxiliares utilizadas pelo Spring Framework para determi-
nar como deve ser realizado o processamento das mensagens HTTP recebidas pelo
servidor;
∙ domain: conjunto de classes análogo ao da aplicação cliente com implementações das
classes que lidam com representações de dados relacionados ao domínio da aplicação.
Neste pacote também são utilizadas classes para representar documentos GeoJSON,
uma vez que esses são os formatos dos documentos a serem armazenados na base
de dados;
∙ repository: contém as classes repositório responsáveis por prover os serviços de acesso
aos objetos de domínio armazenados na base de dados.
Na Figura 21 é apresentado um diagrama de classes com uma visão estrutural
detalhada dos componentes internos da aplicação servidor.
Figura 21 – Diagrama de classes da aplicação Buraqueira Server

72. 71
Comparada a aplicação cliente à estrutura da aplicação servidor é mais simples,
isso acontece principalmente por conta da utilização do Spring Framework que força a
adoção de seus modelos de desenvolvimento. Como resultado obtêm-se uma estrutura
simplificada e robusta baseada em padrões já implementados e validados pelo framework.
Nesta estrutura o componente BuraqueiraController serve como um ponto de en-
trada onde são mapeadas e recebidas as solicitações HTTP enviadas ao servidor. Para
executar as interações com as classes repositório optou-se por utilizar a classe Buraqueira
como um proxy que centraliza e distribui os acessos a cada um dos repositórios.
4.3.2.2 Interfaces
Na seção 4.3.1.2 foram descritas as interfaces necessárias pela aplicação cliente
para executar suas funcionalidades. No diagrama de componentes da Figura 20 são repre-
sentadas as interfaces fornecidas pela aplicação servidor que atendem às necessidades da
aplicação cliente:
∙ streetRatingHTTPPost: disponibiliza uma URL com endereço streetRating para in-
vocação de um método HTTP post, na qual no corpo da mensagem HTTP será
enviado um documento JSON no formato GeoJSON contendo informações sobre a
avaliação feita pelo usuário sobre uma via específica.
∙ streetDefectRatingHTTPPost: disponibiliza uma URL com endereço streetDefectRating
para invocação de um método HTTP post, na qual no corpo da mensagem HTTP
será enviado um documento JSON no formato GeoJSON contendo informações so-
bre a avaliação feita pelo usuário sobre um defeito encontrado em uma via.
∙ streetSurfaceDataHTTPPost: disponibiliza uma URL com endereço streetSurfaceData
para invocação de um método HTTP post, na qual no corpo da mensagem HTTP
será enviado um documento JSON no formato GeoJSON contendo dados coletados
pela aplicação durante o trajeto realizado pelo usuário.
Para a obtenção dos dados são utilizados endereços análogos aos acima mas que
devem ser invocados utilizando o método HTTP get que retornará a lista dos dados
armazenados. Essa implementação atende aos propósitos da prova de conceito mas deve
ser ampliada em uma aplicação de produção para permitir a parametrização do local, raio
de busca de dados e outros parâmetros para filtro das informações.
4.3.2.3 Visão dos dados
O modelo de dados utilizado pela aplicação servidor é o mesmo da aplicação cli-
ente de maneira à garantir a padronização dos dados e facilitar a comunicação entre os

73. 72
componentes. Os modelos estão representados na Figura 14 e na Figura 15 apresentados
em seções anteriores. Os documentos GeoJSON e modelos especificados na visão de da-
dos da aplicação cliente servem como um protocolo de transmissão de dados, ao utilizar o
mesmo procedimento de marshalling e unmarshalling no servidor garante-se que os dados
não serão corrompidos ou perdidos, ao mesmo tempo em que simplifica-se o processo de
comunicação.
Para a persistência das informações foi escolhida uma base de dados baseada em
documentos chamada MongoDB. Esta base foi escolhida por ser capaz de armazenar do-
cumentos em formato JSON e por ser compatível com GeoJSON. A discussão sobre qual o
melhor modelo ou ferramenta de banco de dados para este tipo de aplicação foge ao escopo
deste trabalho, foi escolhida portanto uma ferramenta que simplificasse o desenvolvimento
desta prova de conceito.
As rotinas de persistência são implementadas utilizando o modelo de classes re-
positório do Spring Framework. Esse modelo propõe classes que são responsáveis pelas
interações com as bases de dados e manipulação dos objetos de domínio. No caso é utili-
zado a interface base CrudRepository que o Spring framework utiliza para gerar em tempo
de execução os métodos responsáveis por consultas, remoções, mudanças e criações de da-
dos do tipo especificado na interface.
4.3.2.4 Visão de tempo de execução
Esta seção aborda os aspectos dinâmicos do funcionamento da aplicação servidor,
apresentando modelos que permitam a análise da execução dos principais fluxos da apli-
cação e a interação entre os componentes estruturais. Estes modelos permitem estabelecer
a relação entre os casos de uso e sua realização pelos componentes da aplicação.
Para a prova de conceito proposta neste trabalho a aplicação servidor executa
dois tipos de operação: a obtenção e o recebimento de dados. Portanto optou-se por criar
apenas um modelo para cada operação uma vez que a sequência de execução é a mesma
variando-se apenas o tipo de dado que esta sendo manipulado.
O modelo apresentado na Figura 22 aborda o fluxo bem sucedido do caso de uso
Armazenar dados, no qual a aplicação recebe uma solicitação HTTP post para a URL
de um tipo de dado específico e os componentes lidam com as ações necessárias para
armazenar o documento GeoJSON contendo as informações na base de dados.

74. 73
Figura 22 – Diagrama de sequência - Armazenamento de Dados
Na Figura 23 modela-se a execução bem sucedida do caso de uso Consultar dados,
no qual a aplicação servidor recebe uma solicitação HTTP get para a URL de um tipo de
dados específico e seus componentes internos executam as ações necessárias para obter os
dados e retorná-los para o ator que os solicitou.
Figura 23 – Diagrama de sequência - Obtenção de Dados
4.4 Testes
Nesta seção serão apresentados os testes realizados com a solução desenvolvida
como prova de conceito para verificar seu comportamento diante dos cenários propostos.
Para a execução dos testes foi utilizado um dispositivo smartphone Motorola Razr1
que
possui conexão com rede de dados, GPS, acelerômetros e a versão Ice Cream Sandwich
do sistema operacional Android, recursos estes suficientes para os testes propostos.
1
Informações detalhadas podem ser obtidas na página da oficial da Motorola para o dispositivo Razr:
http: // www. motorola. com. br/ consumers/ MOTOROLA-RAZR/ 80859,pt_ br,pd. html .

75. 74
4.4.1 Coleta de avaliação de uma via
Neste teste o objetivo é executar os passos do usuário durante o caso de uso Coletar
dados sobre uma via. Ao ativar a opção para avaliar uma via, a aplicação cliente exibe a
interface como na Figura 24, onde já são apresentadas as informações de posicionamento
do usuário e permite-se a associação de uma classificação à via.
Figura 24 – Testes - Coleta da avaliação de uma via
Após a escolha da classificação e a confirmação pelo usuário os dados são enviados
ao servidor para persistência e podem ser acessados através do endereço sugerido nas
especificações com a execução de uma solicitação HTTP get como pode ser visto na
Figura 25.

76. 75
Figura 25 – Testes - Obtenção dos dados de avaliação de vias utilizando um navegador
Um exemplo do documento GeoJSON gerado para esta coleta pode ser encontrado
no Apêndice A.
4.4.2 Coleta de avaliação de um defeito específico
Esta seção refere-se aos testes relacionados ao caso de uso Coletar dados sobre
um defeito. Ao executar o comando para coletar um defeito específico, conforme apre-
sentado na Figura 11, a aplicação cliente exibe a interface de coleta com as informações
de localização do usuário e permite que seja acionada a câmera do dispositivo além da
classificação do defeito. Após a obtenção da fotografia e classificação, a aplicação exibe a
interface conforme Figura 26.

77. 76
Figura 26 – Testes - Coleta da avaliação de um defeito
Após a confirmação pelo usuário os dados são enviados ao servidor para persistên-
cia e podem ser acessados através do endereço sugerido nas especificações com a execução
de uma solicitação HTTP get como pode ser visto na Figura 27.
Figura 27 – Testes - Obtenção dos dados de avaliação de defeitos utilizando um navegador

78. 77
Um exemplo do documento GeoJSON gerado para esta coleta pode ser encontrado
no Apêndice B.
4.4.3 Coleta de dados em um trajeto
A coleta de dados quantitativos sobre um trajeto proposta no caso de uso Coletar
dados em um trajeto é um dos procedimento mais complexos pois envolve a utilização de
um veículo para obtenção dos dados, neste teste foi utilizado um automóvel Volkswagen
Gol2
.
Para a realização dos testes o smartphone foi colocado em um dos porta objetos
do console do veículo com a tela voltada para cima, conforme Figura 28.
Figura 28 – Testes - Posicionamento do dispositivo no interior do veículo
Após o posicionamento do dispositivo o comando para iniciar a coleta é acionado
e o condutor do veículo percorreu um trecho de aproximadamente quatorze quilômetros.
Durante o percurso a interface da aplicação cliente exibiu o trajeto percorrido pelo veículo
conforme apresentado na Figura 29.
2
Informações detalhadas podem ser obtidas na página da oficial da montadora para o veículo: http:
//www.vw.com.br/.

79. 78
Figura 29 – Testes - Trajeto percorrido durante a coleta
Percorrido o trecho onde desejava-se efetuar a coleta, o condutor aciona o comando
para desativar a coleta de dados, a aplicação organiza os dados e e em seguida os envia
ao servidor para persistência. Portanto as informações podem ser acessados através do
endereço sugerido nas especificações com a execução de uma solicitação HTTP get como
pode ser visto na Figura 30.

80. 79
Figura 30 – Testes - Obtenção dos dados coletados em percursos utilizando um navegador
Um exemplo do documento GeoJSON gerado para parte desta coleta pode ser
encontrado no Apêndice C.
Para o trajeto escolhido para execução dos testes foram levantadas as informações
relatadas na Tabela 3.
Tabela 3 – Estatística de Percurso
Distância percorrida Aproximadamente quatorze quilômetros
Tempo de percurso Aproximadamente 30 minutos
Quantidade de subdivisões geradas 158 trechos
Distância média percorrida em cada trecho Aproximadamente 94 metros
Número médio de leituras de aceleração por eixo Aproximadamente 282 leituras por trecho
Quantidade de dados gerada 3,2 MegaBytes
A partir dos dados coletados é possível avaliar se a correlação gerada entre dados
geográficos e dados de aceleração dos sensores do dispositivo faz sentido. Para a prova de
conceito proposta um módulo para tratamento dos dados não faz parte do escopo, por-
tanto as análises à seguir foram feitas utilizando-se aplicações externas como a ferramenta
Google (2013b) e uma planilha de cálculo para geração dos gráficos.
Para a análise foram escolhidos três trechos avaliados segundo a experiência e
opinião do condutor do veículo sobre o percurso os quais podem ser considerados como
bom, regular e ruim de acordo com as classificações da Tabela 1. Em seguida foram
gerados mapas com a marcação do trecho ao qual refere-se a avaliação, além de gráficos
em linha com as informações coletadas pelos acelerômetros apresentadas em 𝑚/𝑠2
ao
longo do tempo de trajeto. Nesta análise considera-se que os dados de aceleração do eixo
Z são os mais importante para os experimentos, uma vez que este eixo está alinhado com

81. 80
o eixo Z do veículo e seus dados representam diretamente o efeito causado por defeitos e
imperfeições na via sobre o veículo durante sua circulação. Os resultados são relatados à
seguir.
Trecho com avaliação Boa - Avenida Morais Costa
A avenida referente à este trecho foi recentemente recuperada, há menos de três
anos, e a experiência proporcionada aos usuários da via é considerada boa. O trajeto é
apresentado na Figura 31.
Figura 31 – Trajeto classificado como Bom pelo condutor
Fonte: Google (2013b)
A qualidade da superfície do trecho é refletida nos dados coletados pelos acelerô-
metros apresentados na Figura 32, ao analisar os dados do eixo Z é possível observar
apenas alguns picos com aceleração acima de 0,5𝑚/𝑠2
e apenas um pico acima de 1𝑚/𝑠2
.
Figura 32 – Dados obtidos durante o trajeto com classificação Bom

82. 81
Trecho com avaliação Regular - Rua Caopia
A rua referente a este trecho possui diversas imperfeições e aparentemente não
passa por nenhum procedimento de recuperação há algum tempo, a experiência propor-
cionada aos usuários da via é considerada regular. O trajeto é apresentado na Figura 33.
Figura 33 – Trajeto classificado como Regular pelo condutor
Fonte: Google (2013b)
O gráfico apresentado na Figura 34 reflete os dados coletados pelos acelerômetros
no percurso, ao analisar os dados do eixo Z percebe-se um número maior de picos com
aceleração acima de 0,5𝑚/𝑠2
e ao menos quatro picos com aceleração acima de 1𝑚/𝑠2
o
que indicaria uma qualidade já degradada da superfície e a presença de alguns defeitos já
perceptíveis pelos usuários da via.
Uma observação interessante é a presença de uma lombada ao final do trecho. Ao
analisar os dados de aceleração no eixo Z no final do percurso é possível observar uma
curva de aceleração mais suave, representada por um segmento de senoide. Este tipo de
leitura poderia ajudar a identificar este perfil de obstáculo e os diferenciar de defeitos ou
outras leituras.
Figura 34 – Dados obtidos durante o trajeto com classificação Regular
Trecho com avaliação Ruim - Rua Jurubeba do Campo
A experiência proporcionada pelo trecho da rua Jurubeba do Campo foi avaliado
pelo condutor como ruim, parte da via não esta pavimentada possuindo paralelepípedos

83. 82
e defeitos aparentes. O trajeto é apresentado na Figura 35.
Figura 35 – Trajeto classificado como Ruim pelo condutor
Fonte: Google (2013b)
Os dados apresentados no gráfico da Figura 36 demostram o impacto de uma
via com pavimentação ruim sobre o veículo. É possível perceber que no trecho inicial,
onde a pavimentação é composta apenas de paralelepípedos, a variação na aceleração
dos três eixos é intensa e possui trechos onde a aceleração coletada no eixo Z chega a
3𝑚/𝑠2
evidenciando uma quantidade elevada de imperfeições e defeitos na pavimentação.
Também é importante observar a diminuição na variação da aceleração quando o veículo
deixa o trecho ruim da via e segue por um trecho com a pavimentação asfáltica com
quantidade de imperfeições inferior, a variação na aceleração é bem menor e muito mais
uniforme situando-se novamente na faixa de 1𝑚/𝑠2
.
Figura 36 – Dados obtidos durante o trajeto com classificação Ruim
A análise dos dados demonstra que mesmo em trechos de vias classificadas como
boas é possível observar a variação de aceleração nas leituras. Acredita-se que as leitu-

84. 83
ras que apresentam menor intensidade, abaixo de 0,5𝑚/𝑠2
, poderiam ser causadas pela
vibração de componentes do veículo transmitidas aos sensores do dispositivo. No entanto
esta é apenas uma hipótese que pode ser estudada em trabalhos posteriores.

85. 84
5 Considerações Finais
A proposta principal deste trabalho foi viabilizar uma solução como prova de con-
ceito da utilização do sensoriamento participativo na coleta de informações sobre a pavi-
mentação viária para auxiliar na gestão da mesma. Neste capítulo serão apresentados os
principais resultados e conclusões desta pesquisa, além de proporcionar uma visão de tra-
balhos futuros, melhorias que poderiam ser desenvolvidas em continuidade a este projeto,
e algumas soluções encontradas durante a pesquisa que possuem propostas similares.
5.1 Resultados e Conclusões
No decorrer deste trabalho foi possível propor, projetar e desenvolver uma prova
de conceito na forma de uma solução de software para aplicar o conceito de sensoriamento
participativo à coleta de informações sobre a pavimentação viária. Com base nas pesquisas
realizadas foi desenvolvido um sistema cliente servidor, no qual o uso da aplicação cliente
mostrou-se bem sucedido na coleta da opinião do usuário sobre vias e defeitos, fotografias
de defeitos específicos e de dados de aceleração e geolocalização durante trajetos percorri-
dos por veículos. A aplicação servidor proposta também se mostrou adequada cumprindo
seu papel no armazenamento e disponibilização dos dados coletados.
Os testes e experimentos da prova de conceito também permitiram uma análise
inicial dos dados coletados pela aplicação, dos quais destacam-se os dados quantitativos
levantados durante o uso da aplicação cliente em trajetos. Foi possível observar que mesmo
utilizando o acelerômetro de um smartphone, que não possui um alto grau de precisão,
seria possível identificar vias e trechos de vias com problemas de pavimentação e até
mesmo obstáculos. No entanto foram analisadas as informações brutas dos sensores, seria
necessário um esforço adicional para tratá-las e retirar ruídos gerados por componentes
do veículo.
Finalmente, entende-se que a solução de software se mostrou adequada aos pro-
pósitos de uma prova de conceito afirmando a viabilidade da proposta. No entanto faz-se
necessário um aprofundamento nos estudos da aplicação cliente para torná-la mais ade-
quada à utilização pelos usuários finais e também na aplicação servidor para torná-la
uma plataforma mais robusta e com mais funcionalidades para lidar com as informações
armazenadas.

86. 85
5.2 Sugestões para Trabalhos Futuros
Baseando-se na complexidade do projeto e nas dificuldades encontradas durante as
pesquisas e desenvolvimento, foram identificados diversos pontos que podem ser utilizados
para continuar, aprofundar e melhorar a solução proposta. Abaixo segue uma lista dos
principais itens identificados:
∙ Ajuste automático da orientação dos dados coletados pelo dispositivo ao eixo de
coordenadas do dispositivo para garantir a consistência dos dados coletados inde-
pendentemente da orientação do dispositivo;
∙ Comparar o impacto da utilização dos diferentes tipos de bases de dados na solução;
∙ Refinar os dados coletados pelo acelerômetro e melhorar a precisão dos dados cole-
tados removendo ruídos;
∙ Criação de um sistema de visualização online dos dados coletados com a sobreposição
de camadas de dados com os mapas viários;
∙ Análise dos dados coletados e derivação dos índices de qualidade de pavimentação
utilizando diferentes metodologias;
∙ Criação de listas de priorização para manutenção com base nas informações quan-
titativas e qualitativas coletadas;
∙ Otimização do uso de recursos do smartphone como energia, dados etc;
∙ Possibilitar a atribuição de notas após finalização do percurso, atribuindo-se uma
classificação a cada um dos trechos pela qual o usuário passou;
∙ Estudo de escalabilidade para determinar quantos clientes a aplicação servidor con-
seguiria gerenciar por vez e quais as melhorias possíveis;
∙ Criar uma base de informações visuais classificadas que possa ser utilizada como
base de algoritmos de visão computacional que ao processar imagens em câmeras
identificassem os defeitos em vias e acionassem medidas corretivas automaticamente.
Entende-se que esta não é uma lista definitiva de estudo, mas é esperado que estas
sugestões possam inspirar e motivar futuros estudos baseados neste trabalho.
5.3 Trabalhos Relacionados
Ao longo das pesquisas e do projeto foram encontradas ferramentas e iniciativas que
possuem funcionalidades que se relacionam com a proposta apresentada. Nas ferramentas

87. 86
encontradas a proposta principal é ajudar no mapeamento de defeitos nas vias para que
seja feito o relato às prefeituras responsáveis, ou seja, a natureza destas soluções é reativa.
Entende-se que a principal diferença presente na proposta deste trabalho é a utilização dos
recursos dos smartphones dos usuários para proporcionar uma coleta constante e proativa
para colaborar na previsão dos problemas antes que eles ocorram. Abaixo segue uma lista
com as principais ferramentas relacionadas à este trabalho:
∙ Buracômetro Band News (RáDIO BAND NEWS FM, 2013);
∙ Informe um buraco da Rádio Sulamérica Trânsito (RáDIO SULAMéRICA TRâN-
SITO, 2013);
∙ My Fun City (MY FUN CITY, 2012);
∙ Fix My Street (FIX MY STREET BRASIL, 2013);
∙ Colb.re (COLAB, 2013);
∙ Waze (WAZE, 2006);
∙ Cidadera (CIDADERA, 2013).

88. 87
Referências
ANDROID OPEN SOURCE PROJECT. Android Overview. 2013. Disponível em:
<http://source.android.com/>. Acesso em: 29.7.2013.
BASS, L.; CLEMENTS, P.; KAZMAN, R. Software Architecture in Practice. New Jersey:
Addison-Wesley Professional, 2012. 640 p.
BECKER, V. E. G. Aplicação do Modelo de Tavakoli para Gerência e Manutenção em
Cidades de Médio Porte. Dissertação (Mestrado) — Universidade de São Paulo, São
Carlos, 2012.
BERNHARDSEN, T. Geographic Information Systems: An Introduction. Arendal: John
Wiley & Sons, 2002. 448 p.
BOOCH, G.; RUMBAUGH, J.; JACOBSON, I. Unified Modeling Language User Guide.
Massachusetts: Addison-Wesley Professional, 2005. 496 p.
BURKE, J. et al. Participatory sensing: Workshop on world-sensor-web (wsw’06): Mobile
device centric sensor networks and applications. In: . [S.l.: s.n.], 2006. p. 117–134.
BUTLER, H. et al. The GeoJSON Format Specification. 2008. Disponível em:
<http://www.geojson.org/geojson-spec.html>. Acesso em: 08.08.2013.
CAUSIM, P. B. Estudo de um Sistema de Gerência de Pavimentos para Cidades de
Pequeno e Médio Porte. Dissertação (Mestrado) — Universidade Estadual de Campinas,
Campinas, 2001.
CIDADERA. Cidadera - Melhore sua Cidade. 2013. Disponível em: <http://cidadera-
.com/>. Acesso em: 15.9.2013.
COLAB. Brasil, 2013. Disponível em: <http://colab.re/>. Acesso em: 20.5.2013.
DEPARTAMENTO DE TRâNSITO DE SãO PAULO. Frota de Veículos em São
Paulo - Por Tipo de Veículo. São Paulo, SP, 2013. Disponível em: <http://www-
.detran.sp.gov.br/wps/portal/detran/odetran/estatisticasdotransito/>. Acesso em:
18.6.2013.
DEPARTAMENTO NACIONAL DE ESTRADAS E RODAGEM. Calibração e
controle de sistemas medidores de irregularidades de superfície de pavimento (Sistemas
Integradores IPR/USP e Maysmeter). Rio de Janeiro, 1994. 18 p.
DEPARTAMENTO NACIONAL DE ESTRADAS E RODAGEM. Medição de
irregularidade de superfície de pavimento com sistemas integradores IPR/USP e
maysmeter. Rio de Janeiro, 1994. 9 p.
DEPARTAMENTO NACIONAL DE INFRAESTRUTURA EM TRANSPORTES.
Avaliação subjetiva da superfície de pavimentos flexíveis e semi-rígidos - Procedimento.
Rio de Janeiro, 2003. 6 p.

89. 88
DEPARTAMENTO NACIONAL DE INFRAESTRUTURA EM TRANSPORTES.
Manual de gerência de pavimentos. Rio de Janeiro, 2011. 189 p.
ECMA INTERNATIONAL. ECMAScript Language Specification. Genebra, 2011. 258 p.
FIX MY STREET BRASIL. Brasil, 2013. Disponível em: <http://www.fixmystreet-
.com.br/>. Acesso em: 20.5.2013.
FRANCHINI, D. Análise do Nível de Vibrações Verticais no Acento de um Trator
Agrícola. Dissertação (Mestrado) — Universidade Federal de Santa Maria, Santa Maria,
2007.
GOOGLE. Android Overview. 2013. Disponível em: <http://www.android.com/>.
Acesso em: 29.7.2013.
GOOGLE. Google Maps. 2013. Disponível em: <http://maps.google.com.br/>. Acesso
em: 23.8.2013.
GOOGLE. Motion Sensors. 2013. Disponível em: <http://developer.android.com/guide-
/topics/sensors/sensors motion.html>. Acesso em: 30.7.2013.
GOOGLE. Sensors Overview. 2013. Disponível em: <http://developer.android.com-
/guide/topics/sensors/sensors overview.html>. Acesso em: 30.7.2013.
GOPIVOTAL INC. Spring Framework. 2013. Disponível em: <http://www.springsource-
.org/spring-framework>. Acesso em: 02.08.2013.
HAAS, R.; HUDSON, W.; ZANIEWSKI, J. Modern pavement management. Malabar,
Flórida: Krieger Publishing Company, 1994.
INTERNATIONAL DATA CORPORATION. Smartphones Expected to Outship Feature
Phones for First Time in 2013. Framingham, 2013. Disponível em: <http://www.idc-
.com/getdoc.jsp?containerId=prUS23982813>. Acesso em: 13.5.2013.
INTERNATIONAL ORGANIZATION FOR STANDARDZATION. Mechanical vibration
and shock - Evaluation of human exposure to whole-body vibration: Part 1: General
requirements. Genebra, 1997. 32 p.
INTRODUCING JSON. 2013. Disponível em: <http://www.json.org>. Acesso em:
02.08.2013.
KANHERE, S. Participatory sensing: Crowdsourcing data from mobile smartphones
in urban spaces. In: Mobile Data Management (MDM), 2011 12th IEEE International
Conference on. [S.l.: s.n.], 2011. v. 2, p. 3–6.
CONGRESSO LUSO BRASILEIRO PARA O PLANEAMENTO URBANO REGIONAL
INTEGRADO E SUSTENTáVEL, 2., 2006, Braga. Anais...: A prática de gestão de
pavimentos em cidades médias brasileiras. 209 p.
MAIA, R. H. Análise da Sensibilidade Aplicada a Estudos de Conforto Vibracional
em Automóveis. Dissertação (Mestrado) — Pontifícia Universidade Católica de Minas
Gerais, Belo Horizonte, 2002.
MY FUN CITY. Brasil, 2012. Disponível em: <http://www.myfuncity.org/>. Acesso
em: 20.5.2013.

90. 89
NATIONAL COORDINATION OFFICE FOR SPACE-BASED POSITIONING,
NAVIGATION, AND TIMING. 2013. Disponível em: <http://www.gps.gov/systems-
/gps/>. Acesso em: 31.5.2013.
OPEN HANDSET ALLIANCE. Android Overview. 2013. Disponível em: <http://www-
.openhandsetalliance.com/android overview.html>. Acesso em: 29.7.2013.
PREFEITURA DE SãO PAULO. Extensão de Vias Pavimentadas por Tipo de Pavimento
Município de São Paulo 2004. São Paulo, SP, 2004. Disponível em: <http://infocidade-
.prefeitura.sp.gov.br/htmls/11 extensao de vias pavimentadas por tipo d 2004 492-
.html>. Acesso em: 18.6.2013.
REESE, R. M. Oracle Certified Associate: Java se 7 programmer study guide.
Birmingham: Packt Publishing, 2012. 332 p.
RáDIO BAND NEWS FM. Buracômetro. 2013. Disponível em: <http://bandnewsfm-
.band.uol.com.br/buracometro.aspx>. Acesso em: 20.8.2013.
RáDIO SULAMéRICA TRâNSITO. Informe um Buraco. 2013. Disponível em:
<http://www.sulamericatransito.com.br/modal/login?apos=buraco>. Acesso em:
20.8.2013.
SCHERZ, P. Practical Electronics for Inventors. San Francisco: McGraw-Hill, 2013.
SELL, I. Projeto do trabalho humano: Melhorando as condições de trabalho. Florianópolis:
Universidade Federal de Santa Catarina, 2002. 470 p.
SHAHIN, M. Pavement Management For Airports, Roads and Parking Lots. Nova
Iorque: Chapman & Hall, 1994.
SOMMERVILLE, I. Engenharia de Software. São Paulo: Pearson Addison Wesley, 2003.
WAZE. 2006. Disponível em: <http://www.waze.com/>. Acesso em: 20.5.2013.
ZHENG, P.; NI, L. Smart Phone and Next Generation Mobile Computing. San Francisco:
Elsevier Inc., 2006.

91. Apêndices

92. 91
APÊNDICE A – Documento GeoJSON:
Exemplo de Coleta de
Dados Sobre uma Via
1 {
2 " type " : " Feature " ,
3 " geometry " :{
4 " type " : " Point " ,
5 " coordinates " :[ −46.5297072 , −23.6056439]
6 } ,
7 " pr op ert ie s " :{
8 " dataType " : " street_rating " ,
9 " userRating " : 1 . 5 ,
10 " timestamp " :1381780800693
11 }
12 }

93. 92
APÊNDICE B – Documento GeoJSON:
Exemplo de Coleta de
Dados Sobre um Defeito
1 {
2 " type " : " Feature " ,
3 " geometry " :{
4 " coordinates " :[ −46.5297498 , −23.6056361] ,
5 " type " : " Point "
6 } ,
7 " pr op ert ie s " :{
8 " dataType " : " street_defect " ,
9 " image " : " /9 j /4AAQSkZJRgABAQAAAQABAAD/2
wBDAAoHBwgHBgoICAgLCgoLDhgQDg0NDh0VFhEYIx8lJCIf<imagem truncada
propositalmente>" ,
10 " timestamp " :1381780566426 ,
11 " userRating " : 2 . 9 }
12 }

94. 93
APÊNDICE C – Documento GeoJSON:
Exemplo de Coleta de Da-
dos Sobre a Superfície de
uma Via
1 {
2 " type " : " Feature "
3 " geometry " :{
4 " coordinates " :[[ −46.5297682 , −23.6056358] ,[ −46.531009 , −23.6063914]] ,
5 " type " : " LineString "
6 } ,
7 " pr op ert ie s " :{
8 " collectedSensorData " : [
9 { " timestamp " :1380616596851 , " xAccel " : −0.54230785 , " yAccel "
:0.431983 , " zAccel " :3.5465746} ,
10 { " timestamp " :1380616596878 , " xAccel " : −0.3112632 , " yAccel "
:0.22300327 , " zAccel " :2.898551} ,
11 { " timestamp " :1380616596891 , " xAccel " : −0.06513584 , " yAccel "
:0.11711109 , " zAccel " :2.8091736} ,
12 { " timestamp " :1380616596911 , " xAccel " :0.070474505 , " yAccel "
:0.21627206 , " zAccel " :2.3086305} ,
13 { " timestamp " :1380616596930 , " xAccel " :0.056379676 , " yAccel "
:0.29560077 , " zAccel " :1.7243214} ,
14 { " timestamp " :1380616596951 , " xAccel " :0.04510379 , " yAccel "
:0.1138975 , " zAccel " :1.5020399} ,
15 { " timestamp " :1380616596972 , " xAccel " :0.15866613 , " yAccel "
:0.09111798 , " zAccel " :1.1403408} ,
16 { " timestamp " :1380616596991 , " xAccel " :0.0656414 , " yAccel "
:0.13418597 , " zAccel " :0.48323154} ,
17 { " timestamp " :1380616597011 , " xAccel " : −0.1313616 , " yAccel "
:0.16864038 , " zAccel " :0.32529354} ,
18 { " timestamp " :1380616597030 , " xAccel " : −0.3502556 , " yAccel "
:0.19620389 , " zAccel " :0.19894314} ,
19 { " timestamp " :1380616597051 , " xAccel " :0.39400268 , " yAccel "
:0.2795462 , " zAccel " :0.955945} ,
20 { " timestamp " :1380616597071 , " xAccel " :0.62165993 , " yAccel "
:0.22363698 , " zAccel " :1.1325064} ,
21 { " timestamp " :1380616597091 , " xAccel " :0.68120253 , " yAccel "
:0.117617965 , " zAccel " :0.2930889} ,

95. 94
22 { " timestamp " :1380616597111 , " xAccel " :0.48367053 , " yAccel "
:0.5844269 , " zAccel " :0.050596237} ,
23 { " timestamp " :1380616597132 , " xAccel " :0.63210267 , " yAccel "
:0.46754146 , " zAccel " : −0.57243824} ,
24 { " timestamp " :1380616597153 , " xAccel " :0.5669737 , " yAccel "
:0.19015849 , " zAccel " : −0.7644081} ,
25 { " timestamp " :1380616597173 , " xAccel " : −0.036753535 , " yAccel "
: −0.27691412 , " zAccel " : −0.12119484} ,
26 { " timestamp " :1380616597193 , " xAccel " : −0.45844388 , " yAccel "
: −0.58928066 , " zAccel " :1.1288757}
27 ] ,
28 " endTimestamp " :1380617959761 ,
29 " startTimestamp " :1380617953017 ,
30 " dataType " : " street_surface_data "
31 }
32 }