implementation of a participatory sensing solution to collect data about pavement condition

Eduardo Carrara de Araujo

Implementação de uma Aplicação deSensoriamento Participativo para Coleta de

Informações Sobre a Qualidade daPavimentação Viária

São Paulo2013

Eduardo Carrara de Araujo

Implementação de uma Aplicação de SensoriamentoParticipativo para Coleta de Informações Sobre a

Qualidade da Pavimentação Viária

Trabalho de conclusão de curso apresentadoao Centro Universitário Senac - CampusSanto Amaro, como exigência parcial paraa conclusão do curso de Pós-Graduação emTecnologias e Arquiteturas na Construção deSoftware.

Centro Universitário Senac

Orientador: Prof. Msc Daniel Paz de Araujo

São Paulo2013

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

Eduardo Carrara de AraujoImplementação de uma aplicação de sensoriamento participa-tivo para coleta de informações sobre a qualidade da pavi-mentação viáriaTrabalho de conclusão de curso apresentado ao Centro Univer-sitário Senac - Campus Santo Amaro, como exigência parcialpara a conclusão do curso de Pós-Graduação em Tecnologiase 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

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.

Agradecimentos

À todos os meus amigos que colaboraram na criação e elaboração da ideia. Alémde proporcionar discussões sem fim sobre as infinitas possibilidades de desenvolvimento erequisitos da solução.

Ao meu orientador Prof. Msc Daniel Paz de Araujo pelas conversas, suporte ecríticas tão valiosas à construção deste trabalho.

À minha noiva pelas infinitas revisões, infinita paciência e inabalável confiança deque seria possível chegar ao fim de mais este caminho.

À minha família por todo o incondicional apoio em todas as situações.

"We can’t solve problems by using the same kind of thinking we used when we createdthem."

Albert Einstein

Resumo

O foco deste trabalho é o desenvolvimento de uma proposta alternativa para avaliara 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 propostase 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 passageirosem veículos. Também foram realizadas pesquisas em sensoriamento participativo,tecnologias em mobilidade e engenharia de software de maneira à determinar comoa 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 provade 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 servidorem seu armazenamento e disponibilização. A análise das informações quantitativascoletadas 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 oimpacto da qualidade da pavimentação na opinião dos usuários das vias.

Palavras-chave: 1. Sensoriamento Participativo. 2. Qualidade da PavimentaçãoViária. 3. Tecnologias em Mobilidade. 4. Arquitetura de Software. 5. ArquiteturaCliente Servidor.

Abstract

The focus of this work is the development of an alternative proposition to evaluatethe pavement conditions for a given city using a participatory sensing solution.To substantiate the project the following areas had to be investigated: proposalsand standards in pavement management, how the pavement evaluation is done andthe effects of a bad quality pavement on the vehicle’s passengers. Research in theareas of participatory sensing, tecnologies in mobility and software engineering weredone to ascertain how the relationship between these topics could collaborate in theproblem’s solution. With this elements in place it was possible to design, analysis anddevelop 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 thedata storage and availability. The collected quantitative information analysis showedthat it is possible to determine the presence of defects and assess the pavementquality even using simple collection devices like a smartphone, and also enable thecollection of qualitative information that could help measure the pavement qualityimpact in the perspective of its users.

Keywords: 1. Participatory Sensing. 2. Pavement Quality. 3. Mobility Technologies.4. Software Architecture. 5. Client Server Architecture.

Lista de ilustrações

Figura 1 – Estrutura de um Sistema de Gerência de Pavimentos . . . . . . . . . . 19Figura 2 – Processo para um Sistema de Gerência de Pavimentos . . . . . . . . . 20Figura 3 – Variação da serventia com o tráfego ou com o tempo decorrido de uti-

lização da via . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23Figura 4 – Diversas faixas de variação do IRI . . . . . . . . . . . . . . . . . . . . . 23Figura 5 – Sistema de coordenadas relativas ao dispositivo . . . . . . . . . . . . . 28Figura 6 – Arquitetura cliente servidor para um sistema bancário de caixas eletrô-

nicos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34Figura 7 – GIS: Abrangência . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35

Figura 8 – Proposta: Visão geral . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43Figura 9 – Diagrama de casos de uso . . . . . . . . . . . . . . . . . . . . . . . . . 48Figura 10 –Diagrama de implantação . . . . . . . . . . . . . . . . . . . . . . . . . 56Figura 11 –Fluxo de interação com as interfaces para os usuários da aplicação cliente 58Figura 12 –Diagrama de componentes da aplicação Buraqueira . . . . . . . . . . . 59Figura 13 –Diagrama de classes da aplicação Buraqueira . . . . . . . . . . . . . . . 61Figura 14 –Diagrama de classes dos elementos de dados da aplicação Buraqueira . 62Figura 15 –Diagrama de classes dos elementos GeoJSON . . . . . . . . . . . . . . 63Figura 16 –Diagrama de sequência - Coleta bem sucedida da opinião do usuário

sobre uma via . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65Figura 17 –Diagrama de sequência - Coleta bem sucedida da opinião do usuário

sobre um defeito específico . . . . . . . . . . . . . . . . . . . . . . . . . 66Figura 18 –Diagrama de sequência - Coleta bem sucedida dos dados sobre a su-

perfície do trajeto realizado pelo usuário . . . . . . . . . . . . . . . . . 67Figura 19 –Diagrama de sequência - Visualização e re-envio de dados não trans-

mitidos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67Figura 20 –Diagrama de componentes da aplicação Buraqueira . . . . . . . . . . . 69Figura 21 –Diagrama de classes da aplicação Buraqueira Server . . . . . . . . . . . 70Figura 22 –Diagrama de sequência - Armazenamento de Dados . . . . . . . . . . . 73Figura 23 –Diagrama de sequência - Obtenção de Dados . . . . . . . . . . . . . . . 73Figura 24 –Testes - Coleta da avaliação de uma via . . . . . . . . . . . . . . . . . 74Figura 25 –Testes - Obtenção dos dados de avaliação de vias utilizando um navegador 75Figura 26 –Testes - Coleta da avaliação de um defeito . . . . . . . . . . . . . . . . 76Figura 27 –Testes - Obtenção dos dados de avaliação de defeitos utilizando um

navegador . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76Figura 28 –Testes - Posicionamento do dispositivo no interior do veículo . . . . . . 77

Figura 29 –Testes - Trajeto percorrido durante a coleta . . . . . . . . . . . . . . . 78Figura 30 –Testes - Obtenção dos dados coletados em percursos utilizando um

navegador . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79Figura 31 –Trajeto classificado como Bom pelo condutor . . . . . . . . . . . . . . 80Figura 32 –Dados obtidos durante o trajeto com classificação Bom . . . . . . . . . 80Figura 33 –Trajeto classificado como Regular pelo condutor . . . . . . . . . . . . 81Figura 34 –Dados obtidos durante o trajeto com classificação Regular . . . . . . . 81Figura 35 –Trajeto classificado como Ruim pelo condutor . . . . . . . . . . . . . . 82Figura 36 –Dados obtidos durante o trajeto com classificação Ruim . . . . . . . . 82

Lista de tabelas

Tabela 1 – Níveis de serventia . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22Tabela 2 – Condições Inaceitáveis às Vibrações Verticais . . . . . . . . . . . . . . 25

Tabela 3 – Estatística de Percurso . . . . . . . . . . . . . . . . . . . . . . . . . . . 79

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

Lista de símbolos

∑︀ Letra grega Sigma

Hz Hertz

g Medida de aceleração

Sumário

1 Introdução . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

2 Estado da Arte . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 192.1 Sistemas de Gerenciamento de Pavimentos (SGP) . . . . . . . . . . . . . . 19

2.1.1 Avaliação da Condição de Pavimentos . . . . . . . . . . . . . . . . . 202.1.2 Valor de Serventia Atual (VSA) . . . . . . . . . . . . . . . . . . . . 212.1.3 Índice Internacional de Rugosidade (International Roughness Index

- IRI) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 232.2 Vibração e o Conforto em Veículos . . . . . . . . . . . . . . . . . . . . . . 242.3 Tecnologias em Mobilidade . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

2.3.1 Telefones Móveis Inteligentes (Smartphones) . . . . . . . . . . . . . 252.3.2 Sistema Operacional Android . . . . . . . . . . . . . . . . . . . . . 262.3.3 Acelerômetros . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 272.3.4 Sistema de Posicionamento Global . . . . . . . . . . . . . . . . . . 28

2.4 Sensoriamento Participativo . . . . . . . . . . . . . . . . . . . . . . . . . . 292.5 Tecnologias em Engenharia de Software . . . . . . . . . . . . . . . . . . . . 30

2.5.1 Arquitetura de Software . . . . . . . . . . . . . . . . . . . . . . . . 302.5.2 Arquitetura Cliente - Servidor . . . . . . . . . . . . . . . . . . . . . 332.5.3 Sistemas de Informações Geográficas . . . . . . . . . . . . . . . . . 342.5.4 Linguagem de Modelagem Unificada (UML) . . . . . . . . . . . . . 35

2.6 Tecnologias em Desenvolvimento de Software . . . . . . . . . . . . . . . . . 362.6.1 Java . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 362.6.2 Spring Framework . . . . . . . . . . . . . . . . . . . . . . . . . . . 372.6.3 Javascript Objects Notation (JSON) . . . . . . . . . . . . . . . . . . 38

3 Oportunidade . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40

4 Proposta . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 424.1 Escopo e Requisitos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43

4.1.1 Dados quantitativos e qualitativos sobre a pavimentação . . . . . . 444.1.2 Coleta de dados durante um trajeto . . . . . . . . . . . . . . . . . . 444.1.3 Coleta de dados sobre uma via específica . . . . . . . . . . . . . . . 454.1.4 Coleta de dados sobre um defeito específico . . . . . . . . . . . . . . 454.1.5 Visualização de dados coletados . . . . . . . . . . . . . . . . . . . . 454.1.6 Disponibilização de dados através de serviços Web . . . . . . . . . . 464.1.7 Otimização do uso de conexão de dados . . . . . . . . . . . . . . . . 46

4.1.8 Sistema operacional do smartphone . . . . . . . . . . . . . . . . . . 464.1.9 Uso de ferramentas e serviços livres e/ou gratuitos . . . . . . . . . . 474.1.10 Restrições . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47

4.2 Especificação . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 474.2.1 Coletar dados sobre um defeito . . . . . . . . . . . . . . . . . . . . 494.2.2 Coletar dados sobre uma via . . . . . . . . . . . . . . . . . . . . . . 504.2.3 Coletar dados em um trajeto . . . . . . . . . . . . . . . . . . . . . . 514.2.4 Transmitir dados . . . . . . . . . . . . . . . . . . . . . . . . . . . . 524.2.5 Visualizar dados . . . . . . . . . . . . . . . . . . . . . . . . . . . . 524.2.6 Visualizar dados não transmitidos . . . . . . . . . . . . . . . . . . . 534.2.7 Consultar dados . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 544.2.8 Armazenar dados . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55

4.3 Arquitetura . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 554.3.1 Aplicação Cliente . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56

4.3.1.1 Interfaces para o Usuário . . . . . . . . . . . . . . . . . . 574.3.1.2 Visão estrutural . . . . . . . . . . . . . . . . . . . . . . . 584.3.1.3 Visão dos dados . . . . . . . . . . . . . . . . . . . . . . . 624.3.1.4 Visão de tempo de execução . . . . . . . . . . . . . . . . . 65

4.3.2 Aplicação Servidor . . . . . . . . . . . . . . . . . . . . . . . . . . . 684.3.2.1 Visão estrutural . . . . . . . . . . . . . . . . . . . . . . . 684.3.2.2 Interfaces . . . . . . . . . . . . . . . . . . . . . . . . . . . 714.3.2.3 Visão dos dados . . . . . . . . . . . . . . . . . . . . . . . 714.3.2.4 Visão de tempo de execução . . . . . . . . . . . . . . . . . 72

4.4 Testes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 734.4.1 Coleta de avaliação de uma via . . . . . . . . . . . . . . . . . . . . 744.4.2 Coleta de avaliação de um defeito específico . . . . . . . . . . . . . 754.4.3 Coleta de dados em um trajeto . . . . . . . . . . . . . . . . . . . . 77

5 Considerações Finais . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 845.1 Resultados e Conclusões . . . . . . . . . . . . . . . . . . . . . . . . . . . . 845.2 Sugestões para Trabalhos Futuros . . . . . . . . . . . . . . . . . . . . . . . 855.3 Trabalhos Relacionados . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85

Referências . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87

Apêndices 90

APÊNDICE A Documento GeoJSON: Exemplo de Coleta de Dados Sobreuma Via . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91

APÊNDICE B Documento GeoJSON: Exemplo de Coleta de Dados Sobreum Defeito . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92

APÊNDICE C Documento GeoJSON: Exemplo de Coleta de Dados Sobre aSuperfície de uma Via . . . . . . . . . . . . . . . . . . . . . . . 93

17

1 Introdução

A infraestrutura das cidades, na forma de serviços e equipamentos, colabora com ofuncionamento e execução das diversas atividades sociais e econômicas que movimentamas vidas de seus moradores. É uma peça fundamental na garantia da qualidade de vidados 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, decarga, 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 nodia-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 Departamentode 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çãotardia 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 operacionaldos veículos; aumento de até 100% no tempo de percurso; aumento de até 50% no índicede 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 vidados 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 ouso de recursos disponíveis e organizando o processo de manutenção.

Causim (2001 apud HAAS; HUDSON; ZANIEWSKI, 1994), Shahin (1994) e anorma brasileira DNIT (2011) documentam que uma parte relevante do processo de SGPconsiste 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 pesquisade Lima, Ramos e Junior (2006) mostra que, em cidades médias brasileiras, 60% dasprefeituras faz avaliações somente quando necessário e menos de 50% trabalha com algummétodo específico de seleção de ruas para manutenção.

Sendo assim, a proposta deste projeto é a criação de uma ferramenta de softwareque 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 emuma base de dados aberta que possa ser aproveitada pela sociedade como parte do critério

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 oIDC (2013) espera-se que sejam embarcados para o mercado brasileiro mais de 28 milhõesde unidades em 2013, pode prover as ferramentas necessárias para coleta de informaçõesjá 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 talferramenta é o surgimento e o crescimento da participação da população em iniciativasque aproveitam o engajamento social eletrônico para exercitar a cidadania, ferramentascomo 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 destesacontecimentos em suas vidas e até mesmo utilizar essas informações para melhorar aqualidade dos serviços prestados pelos governos de sua cidade e consequentemente desuas vidas.

Portanto, o escopo deste projeto compreende a engenharia e desenvolvimento deuma PoC (Proof of Concept) para um sistema baseado em arquitetura cliente-servidoronde: uma aplicação Android será utilizada pelos usuários para coletar informações dosacelerô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 edisponibilizá-los através de serviços web. Espera-se que com a utilização da prova deconceito seja possível validar a possibilidade de aplicação do conceito de sensoriamentoparticipativo à este tipo de problema e efetuar uma análise inicial dos dados obtidosdurante os testes e experimentos.

O presente trabalho está estruturado da seguinte forma: no Capítulo 1 é feita acontextualização do problema e o entendimento da relevância da proposta na melhoriada 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; odetalhamento 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 eos testes realizados com a prova de conceito desenvolvida; finalmente no Capítulo 5 sãodocumentadas as conclusões e sugestões para trabalhos futuros.

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 resultamno 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 comoum 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 paraa construção e manutenção de pavimentos a partir de uma base de informações confiáveissobre 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 apudHAAS; HUDSON; ZANIEWSKI, 1994, p.26), já Shahin (1994) propõe uma organizaçãona 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)

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 normaDNIT (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

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, estruturaise 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 demaneira mais eficiente. Uma das funcionalidades mais relevantes de um SGP, segundoShahin (1994) é sua habilidade de determinar o estado atual e futuro da pavimentaçãodas 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 sobreas ações a serem realizadas, a norma DNIT (2011) esclarece que três fatores devem serobservados:

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 influenciamdiretamente sua segurança e utilização pelos usuários, como sinalização, aderênciado 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çãopode ser feita através do Valor de Serventia Atual (VSA) e do International RoughnessIndex (Í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 viaproporcionar, na opinião do usuário, rolamento suave e confortável em um momentosob qualquer condição de tráfego. A avaliação é realizada por uma equipe composta demembros 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 velocidademáxima da via; devem ser atribuídas notas a trechos da via, estas notas devem variarentre 0,0 e 5,0 (indicando, respectivamente, pavimentos de péssimo a ótimo); deve-se terem mente critérios como o quanto o pavimento atende no momento o propósito ao qualfoi construído e se o conforto proporcionado é adequado.

22

Após a coleta das avaliações, o VSA é calculado para cada trecho da via de acordocom 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. Emgeral, após a construção ou reforma da superfície da via o índice VSA é elevado já queesta 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 4Regular 2 a 3Ruim 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ívelestabelecer 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áriospassa a ser inadequado (o limite depende do tipo de via e tráfego, variando de uma VSAde 2 a 2,5). Quando este nível é atingido deve ser feita a manutenção corretiva da via pararestaurar sua condição, antes disso apenas a manutenção preventiva periódica é suficientepara manter níveis aceitáveis. Caso não haja manutenção o pavimento pode atingir olimite de trafegabilidade, no qual a circulação de veículos é extremamente prejudicada etorna-se necessária a reconstrução da via. A evolução da curva de serventia é apresentadana Figura 3. (DNIT, 2011)

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 emtrechos de uma determinada via. A irregularidade longitudinal refere-se ao somatório dosdesvios detectados na superfície de um pavimento em relação a um plano de referênciaideal, que impactam em características como qualidade ao rolamento, dinâmica das cargase 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, osefeitos são perceptíveis nos passageiros, cargas e nos próprios veículos. A importância em

24

entender e mensurar as irregularidades está em sua correlação com os custos e qualidadede serviço entregue aos usuários. (DNIT, 2011)

No Brasil, o DNIT (2011) recomenda que o levantamento das irregularidades sejafeito de acordo com a norma DNER (1994b) que especifica a utilização de sistemas dotipo 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ômetroAASHTO, 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 dasmediçõ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 traseirodo veículo em relação à carroceria e devem ser relacionadas às informações de localizaçãodo trecho da via onde foi realizada a leitura.

O valor final do IRI é calculado através de uma das equações para o coeficiente deirregularidade (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ículosO 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 fatoresentre eles o conforto resultante da utilização da via. (DNIT, 2011)

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 corpointeiro, principalmente em circunstâncias em que a vibração é transmitida através de umasuperfície de sustentação como pés de uma pessoa em pé, nádegas de uma pessoa sentadaou área de sustentação onde se recosta. Esta norma ainda recomenda que a quantidade aser utilizada para medir a intensidade da vibração é a aceleração, normalmente expressaem 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 verticaisque podem afetar o corpo humano. Algumas diferentes faixas de vibração e aceleraçãoque 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 4gFrequências entre 4Hz e 14Hz e aceleração entre 1,2g e 3,2gFrequências acima de 14Hz e aceleração entre 5g e 9gCom aceleração de 1,5g a vibração se torna perigosa e insuportávelA 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 consideradasperigosasCom aceleração de 0,5𝑚/𝑠2 no assento, os erros do motorista aumentam significati-vamenteDe 1Hz a 4Hz, há dificuldade para respirarDe 2Hz a 16 Hz, o desempenho do motorista diminui muito e os efeitos pioram como aumento da aceleraçãoDe 4Hz e 8 Hz, há maior sensação de incômodoDe 4Hz a 10 Hz começam dores no peito, na barriga, reação na musculatura, resso-nância no maxilar inferiorDe 8Hz a 12 Hz, dores nas costasDe 10Hz a 20 Hz, tensão muscular, dor de cabeça, perturbações visuais, dores natraqueia, 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 umanova classe de aparelhos celulares, dotada de um aumento significativo no poder de pro-

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 dispositivosoferece 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çosbaseados 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ênciade diversos dispositivos e fica clara sua importância como agente de inovação nas maisdiversas á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 umaampla 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 ambienteunificado 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 (applicationprogramming interfaces). Open Handset Alliance (2013)

As principais funcionalidades são encontradas em Google (2013a), abaixo segueuma 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;

27

∙ acessibilidade: voz para texto, texto para voz, tamanho de fonte, recursos de respostaetc;

∙ 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 PositioningSystem), NFC (Near Field Communications), câmera, sensor de proximidade, sensorde luminosidade, sensor de temperatura, sensor de pressão atmosférica, giroscópioetc.

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 paramedir 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çãoe melhorar a usabilidade para o usuário. (SCHERZ, 2013; GOOGLE, 2013c)

A documentação em Google (2013c) especifica o funcionamento do acelerômetrona plataforma Android, cujo sensor mede a aceleração aplicada ao dispositivo derivando-ada medição das forças aplicadas ao próprio sensor. Nesta medição está inclusa a aceleraçãoda 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 decoordenadas padrão para sensores em dispositivos Android representado na Figura 5.

Em Google (2013c) descreve-se as seguintes condições com o dispositivo sobre umamesa 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 dodispositivo (+𝐴𝑚/𝑠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 aaceleração do dispositivo (0𝑚/𝑠2) subtraída da aceleração da gravidade (−9, 81𝑚/𝑠2).

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 aindaGPS) é 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 planetaTerra 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 quemonitoram 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 utilizadaspor uma aplicação específica.

O processo de utilização do sistema GPS inicia com a transmissão das informaçõesde posicionamento e tempo pelos satélites; os sinais de rádio são recebidos e interpretadospor um receptor GPS que utiliza os dados para calcular a distância do receptor até osaté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)

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çosde sistema do Android que fornecem a localização do usuário. No entanto, é importanteressaltar que, apesar do GPS ser o método mais preciso em ambientes externos, para estatarefa o receptor consome mais energia do que outras formas e não é tão rápido quantodesejado pela maioria dos usuários, este problema é abordado na plataforma Androidutilizando uma técnica que mescla informações obtidas de diversos meios para estimar alocalização do usuário, como o sinal de Wi-Fi e de dados do smartphone.

2.4 Sensoriamento ParticipativoA 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 suacrescente adoção por grande parte das pessoas começam a possibilitar novas formas decoleta de informações como o sensoriamento participativo (do inglês paticipatory sensing),cuja ideia principal é disponibilizar aos cidadãos ferramentas que os tornem capazes decoletar 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 tipicamenteadotam o modelo cliente servidor no qual um software instalado no smartphone de umvoluntá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 oprocessamento e disponibiliza as informações em formatos que podem variar de acordocom 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 serdivididas em duas categorias:

∙ Aplicações de sensoriamento orientadas às pessoas: utiliza os sensores do dispositivomó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 edocumentação de experiências esportivas, melhorar o uso de mídias sociais, auditoriade 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 oambiente onde está o usuário. São alguns exemplos: monitoramento da qualidade

30

do ar, monitoramento de níveis de ruído, monitoramento de pavimentos e condiçõesde tráfego.

Ainda segundo Kanhere (2011), o sensoriamento participativo oferece algumasvantagens sobre redes de sensores distribuídos tradicionais como o uso da infraestruturajá existente de smartphones e redes de dados (WiFi ou celular), o que permite um custode implementação mais baixo; a grande cobertura das operadoras de celular habilita umagrande 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 deplataformas móveis já existentes para desenvolvimento e distribuição das aplicações tornao processo de implantação e implementação mais fácil; finalmente, ao incluir os cidadãosao processo de coleta é possível projetar soluções que realmente colaborem na melhoriado dia a dia das comunidades.

2.5 Tecnologias em Engenharia de SoftwareDe 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çãodo sistema. Os engenheiros de software trabalham de maneira sistemática e organizadapara identificar teorias, métodos e ferramentas que sejam mais adequadas para auxiliarna solução dos problemas dentro das restrições organizacionais e financeiras que lhe sãoimpostas.

Esta seção aborda algumas questões relacionadas à engenharia de software queguiam 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çãoe a compreensão dos diversos elementos, além de suas relações e propriedades, que podemfazer 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 osdiversos elementos identificados são documentados. A arquitetura representa a conexãoentre os requisitos de software, as necessidades do negócio, e o sistema a ser construído.(SOMMERVILLE, 2003)

31

Bass, Clements e Kazman (2012) argumentam que a complexidade presente nossoftware modernos frequentemente torna muito difícil sua compreensão com uma únicavisão ou estrutura. O conjunto de todos os elementos de software e hardware que compõemo sistema é chamado de estrutura; já a visão é uma representação de um subconjunto deelementos estruturais organizados coerentemente e representados de forma a garantir acompreensão por todos os envolvidos no projeto. As estruturas podem ser dividas em trêstipos:

∙ 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ídosou 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 osconectores representam os meios de comunicação entre os elementos (retornos dechamada, meios de sincronização etc). Provê informações sobre o fluxo de dados nosistema, paralelismo, dados compartilhados, interação entre componentes em tempode 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, sistemasde arquivos, redes, times de desenvolvimento etc). Colabora com informações sobreinterações com o ambiente externo como quais times de software irão desenvolvercada componente, em qual unidade de processamento cada componente irá executaretc.

Cada estrutura permite analisar e projetar perspectivas diferentes do sistema, noentanto isso não as torna independentes. É importante estabelecer relações entre elementosde 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 estabelecerestratégias para prevenção. Apesar de colaborar na construção de visões diferentes sobreo 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 sobreinvestimento proporcionado por estas atividades, geralmente representado em termos demenor tempo de desenvolvimento e menores custos de manutenção. (SOMMERVILLE,2003; BASS; CLEMENTS; KAZMAN, 2012)

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 guiandoo desenvolvimento. No entanto, as habilidades que o arquiteto deve apresentar vão alémda perspectiva técnica, habilidades como comunicação, negociação e conhecimento dasregras 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 pessoasnã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 papelem 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 ogerenciamento 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 somentena construção;

∙ Restringe alternativas de projeto, canalizando esforços e reduzindo a complexidadedo sistema e do projeto;

∙ Pode ser a fundação para o treinamento de um novo membro da equipe.

33

2.5.2 Arquitetura Cliente - Servidor

Segundo Sommerville (2003), Bass, Clements e Kazman (2012), este é um modelode 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çoscompartilhados, que por sua vez são geridos por um ou mais servidores e acessados atravésde uma rede.

A ideia principal é extrair serviços comuns e centralizá-los em um local, ou umpequeno 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últiplosservidores 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 modelocomo a centralização dos recursos que pode transformar o servidor em um gargalo deperformance ou em um ponto único de falha; a separação de funcionalidades entre clientee servidor que pode se tornar complexa e sua mudança pode ter um alto custo após aimplementaçã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 sitede comércio eletrônico; sistemas de informação em redes locais cujos clientes são aplicaçõescom interfaces gráficas para o usuário e o servidor são sistemas de gerenciamento de bancode dados; sistemas bancários nos quais os clientes são os caixas eletrônicos e os servidoressã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 caixaseletrônicos pode ser visto na Figura 6.

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 mundoreal podem ser coletadas, processadas e apresentadas de maneira simplificada para cumprirnecessidades específicas. Tomar decisões sobre nosso meio ambiente requer informaçõessobre 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 deacordo com as condições de cada local, são portanto essenciais ao planejamento e processode 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 essesdados. Todos os dados inseridos em um GIS são geo-referenciados, ou seja, estão atreladosa um local específico na superfície da Terra através de um sistema de coordenadas, dosquais o mais comum é o composto por latitude e longitude. (BERNHARDSEN, 2002)

Diversas qualidades e características podem ser relacionadas a localidades, estesatributos 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 propriedadessão atreladas a pontos, mas é possível estabelecer um relacionamento mais complexocom linhas ou áreas, exemplos comuns são o mapeamento de lagos, cidades, ruas e rios.(BERNHARDSEN, 2002)

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 orelacionamento entre características, atributos e locais são algumas de suas funcionali-dades mais poderosas. Frequentemente dados são processados e sobrepostos na forma demapas, tabelas ou formatos especiais que fornecem informações vitais sobre localidadesgeográ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 detransporte; sistema de informações sobre propriedades; sistema de gerenciamento de dis-tribuição de encanamentos e cabeamentos; sistemas de planejamento de rodovias; sistemasde navegação em terra e mar.

2.5.4 Linguagem de Modelagem Unificada (UML)

Segundo Booch, Rumbaugh e Jacobson (2005), existem limites para a capacidadehumana em compreender complexidades, sendo assim criamos modelos como uma formade simplificar a realidade e compreender melhor o sistema que está sendo desenvolvido.

36

A UML (Unified Modeling Language) é uma linguagem padrão de modelagem cri-ada para visualizar, especificar, construir e documentar artefatos de um sistema complexode software. Esta ferramenta provê um conjunto de estruturas que permite a descrição decaracterísticas conceituais como processos de negócio, requisitos e casos de uso; e itensconcretos como estruturas de classes, módulos e componentes a serem implantados. Nãoestá entre os objetivos da UML especificar quais estruturas criar e quando criar, papeleste que deve ser cumprido pelo processo de desenvolvimento de software o que tornaesta 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 basicamentetrê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 entreos 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 relacionamentosque permite a visualização de perspectivas diferentes do projeto do sistema. Sãoao 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, deimplantação, de pacotes, de temporização, de visão geral de interação.

2.6 Tecnologias em Desenvolvimento de SoftwareO desenvolvimento de software consiste na transformação das especificações do

projeto em um sistema funcional. Esta etapa envolve a programação dos componentesde software por um desenvolvedor que traduz todas as diretrizes presentes no projetoem instruções compreensíveis ao computador, a utilização de ferramentas e frameworksauxiliares 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 doscomponentes 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

37

por Patrick Naughton, Mike Sheridan, e James Gosling. Se enquadra no paradigma delinguagens orientadas à objetos, é independente de plataforma, sua estrutura sintática esemântica foram adaptadas de outra linguagem a C++. (REESE, 2012)

Na época de seu lançamento, Java foi bastante inovador por prover funcionalidadescom 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 debytecode Java) que é interpretada e executada pela Java Virtual Machine (JVM), essadecisã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 variadependendo da arquitetura. (REESE, 2012)

A evolução da linguagem e de suas ferramentas de desenvolvimento permitiram acriaçã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 desenvolvidasem Java:

∙ Aplicações desktop para console e com interfaces gráficas;

∙ Aplicações web baseadas em servidores e suportadas por Servlets, Java Server PagesJava 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 é seusuporte estrutural para a construção da aplicação, seu foco é fornecer funcionalidadesde apoio de alta qualidade para que os times de desenvolvimento possam se preocuparsomente com a implementação das regras de negócio. Spring possui suporte a implantaçãoem diversos tipos de plataforma, possui projeto modular e pode ser adotado de maneiraincremental 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 (eXtensibleMarkup Language) ou anotações;

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 RESTfulMVC (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 umsubconjunto da linguagem de programação JavaScript especificada pelo padrão ECMA(2011). Seu formato é facilmente manipulável por seres humanos e máquinas, é baseadoem texto e completamente independente de linguagem de programação, apesar de utilizarconvençõ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 estruturassão definidas da seguinte forma:

∙ Objetos: conjunto desordenado de pares nome e valor. Iniciado com abertura dechaves e finalizado com fechamento de chaves, nomes e valores são separados pordois pontos e os pares separados por vírgulas;

∙ Arrays: coleção ordenada de valores. Iniciado com abertura de colchetes e finalizadocom fechamento de colchetes, valores são separados por vírgulas;

∙ Valores: podem ser texto entre aspas duplas, um número, true, false, null, um objetoou 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ãoutilizados);

∙ Espaços em branco: podem ser inseridos em qualquer ponto da notação, geralmenteutilizados para melhorar a legibilidade.

39

Uma extensão ao JSON relevante para este trabalho é o Geospacial JSON. Segundosua especificação em Butler et al. (2008), este é um formato de troca de dados geoespaciaisque 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 enriquecero nível de informações sobre os dados geográficos.

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 pavimentose o estudo do conforto em veículos auxiliam a compreensão dos efeitos do desgaste dasvias sobre os veículos e seus passageiros, além de propor sistemáticas para que os gestoresdesta infraestrutura possam planejar e atuar no momento mais adequado para prevenirque 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 coletacontínua de informações sobre a condição atual da pavimentação viária é um procedimentoimportante para garantir que o SGP possua dados atualizados. Desta forma, torna-sepossí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çãode 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çõesda pavimentação somente quando há solicitação da população; 60% destas cidades utilizaalgum SGP e, no entanto, apenas 12% realiza a atualização dos levantamentos de campoe avaliação dos pavimentos; menos da metade das prefeituras utiliza um método formalespecífico para selecionar vias para a manutenção, sendo que apenas 20% delas utiliza aanálise da condição da pavimentação para este fim.

São diversas as dificuldades enfrentadas pela gestão pública para manter uma basede informações atualizada sobre as vias sob sua gestão, ainda no trabalho de Lima, Ramose Junior (2006) conclui-se que a falta de recursos e a ausência de uma política formal paragestã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 avaliara necessidade de manutenção e restauração dos pavimentos; na maioria dos casos os órgãospúblicos municipais desconhecem a real condição dos pavimentos atuando reativamentena solução de problemas; e finalmente, os recursos técnicos especializados são escassose utilizados com pouco, ou nenhum planejamento, geralmente para suprir necessidadesextremas 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

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, noentanto complementar, que colabore na coleta de dados e por consequência na melhoriado processo de gestão de pavimentos.

42

4 Proposta

O processo para coleta de informações sobre o estado atual da pavimentação viáriaestá intimamente relacionado com o destino dos dados obtidos, e, como visto em capítulosanteriores, à partir deles podem ser derivados indicadores que representem a capacidadeda 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 osprocedimentos de coleta de dados devem ser executados por equipes especializadas comequipamentos preparados e calibrados especificamente para este fim.

As restrições de recursos humanos e financeiros destacados por Lima, Ramos eJunior (2006) tornam-se uma barreira às medições utilizando recursos especializados, umavez que se torna cada vez mais difícil disponibilizá-los e desenvolvê-los em quantidadesuficiente para abranger adequadamente, e com maior frequência, a quantidade de viasnas cidades.

A proposta do presente trabalho utiliza os conceitos de sensoriamento participativono 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 participantesnesta 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 locaisonde são mais necessários.

O conceito de sensoriamento participativo orientado ao ambiente foi escolhido poispossibilita a simplificação dos equipamentos de medição com a sugestão do uso de umaaplicação para um smartphone, pertencente a um usuário voluntário, capaz de utilizar osrecursos disponíveis neste dispositivo para monitorar informações relevantes do ambiente eenviá-las a um servidor para serem processadas posteriormente; além de motivar o cidadãocomum a participar voluntariamente do processo de coleta, aumentando não somente ovolume e frequência dos dados mas também sua relevância em relação ao dia-a-dia dosusuários da infraestrutura viária.

Uma visão de alto nível da solução proposta está representada na Figura 8, naqual o procedimento de coleta está divido em três etapas:

1. Coleta de informações é o cumprimento das atividades de recolhimento de dadospelos 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

43

transmitidas aos sensores do smartphone. Além disso, podem ser obtidos dadosqualitativos, 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 aopiniã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 etapautilizando os recursos de conectividade disponíveis no smartphone;

3. Processamento e Armazenamento, que consiste no recebimento e persistência dosdados 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 utilizadascomo referência para a construção da solução.

4.1 Escopo e RequisitosCompreende 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.

44

Para atingir o objetivo proposto a solução deverá realizar os requisitos abaixodetalhados.

4.1.1 Dados quantitativos e qualitativos sobre a pavimentação

O objetivo principal da solução é coletar informações que possam ser utilizadas naanálise da condição do pavimento. Portanto é necessário definir a natureza dos dados aserem coletados de maneira a guiar os requisitos funcionais que definem quando e comoa 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 (apresentadono capítulo 2);

∙ Fotografias do estado atual do pavimento ou de um defeito específico, para posterioraná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 eZ obtidos do acelerômetro do dispositivo, em 𝑚/𝑠2, durante um trajeto percorrido peloveículo do usuário. Estes dados são a informação bruta que pode ser utilizada na derivaçãode 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 197000: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 comseu veículo. Para isso o smartphone deverá ser posicionado sobre o painel do veículo coma face voltada para cima, o usuário poderá então acionar um comando na aplicação parainiciar a coleta de dados antes de começar seu trajeto, e ao final do percurso o usuáriodeverá acionar um comando para interromper a coleta, armazenar e enviar os dados.

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 qualidadeda pavimentação do percurso realizado; e, dados temporais.

A coleta destas informações permite sua correlação e contextualização através dacriação de uma camada de dados que pode ser sobreposta a mapas que permitam aanálise de dados de regiões específicas, conforme proposto por sistemas de informaçõesgeográficas. Por fim, a opinião do usuário serve como informação qualitativa que provê aperspectiva 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á exibira localização atual do usuário e permitir que ele avalie a condição do pavimento. Serãoarmazenadas as informações de posicionamento no momento da coleta, opinião do usuárioem 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çõesnegativas por um número maior de usuários terá um impacto positivo muito maior. Dessaforma, coletar a opinião do usuário possibilita estimar o impacto do estado atual da viapara usuário final, pretende-se desta forma disponibilizar mais uma ferramenta que auxilieo 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íficoencontrado em uma via. Ao utilizar esta opção o sistema deverá exibir a localização atualdo usuário, permitir que seja obtida uma fotografia e a avaliação qualitativa do defeito. Asinformações armazenadas são os dados de posicionamento no momento da coleta, opiniãodo 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álisedo 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ãoonde o usuário se encontra no momento. Cada tipo de informação poderá ser visualizadade maneira diferente:

46

∙ Defeitos específicos terão suas localizações apontadas no mapa por marcadores queao serem selecionados exibirão todos as informações referentes ao defeito;

∙ As avaliações qualitativas enviadas pelos usuários serão utilizadas para determinaro índice VSA dos trechos de vias e sua representação gráfica deverá ser coloridade 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 sejammais relevantes aos usuários.

O principal objetivo deste requisito é propiciar transparência aos usuários sobreas condições atuais das vias de sua localidade. As mesmas informações disponibilizadasaos 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 abertosque 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çõescoletadas que atendam aos parâmetros informados, deve-se considerar que quando umparâmetro for informado em branco todas as informações relativas ao mesmo deverão serretornadas.

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 estejamconectados a redes de dados disponibilizadas pelas operadoras de celular que limitam avelocidade e a quantidade de informação que podem ser utilizadas de acordo com o serviçocontratado pelo usuário. Esse tipo de dispositivo normalmente possui mais de um tipo deconexão, é importante portanto que a aplicação transmita as informações aos servidoressomente quando um tipo de conexão mais adequada (como o Wi-Fi) estiver disponível demaneira 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 Androiddevido a sua grande presença no mercado de smartphones, disponibilidade de dispositivos

47

em diversas faixas de preços e grande número de funcionalidades. Essas característicasgarantem uma grande abrangência geográfica e a disponibilidade dos recursos tecnológicosnecessá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-seselecionar apenas ferramentas e serviços que sejam livres ou que possuam versões semcusto.

4.1.10 Restrições

Durante o processo de análise de requisitos foram identificadas algumas restriçõesque não poderão ser tratadas no decorrer deste trabalho devido as restrições de tempo eescopo:

∙ 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écnicaspara responder adequadamente a essas mudanças.

∙ Precisão dos dados coletados: é importante ressaltar que a precisão dos sensoresdisponí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 cadatipo 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çãoOs 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 osrequisitos enriquecendo o nível de detalhes e os aproxima do projeto da arquitetura e daimplementação. Neste ponto é importante criar modelos que descrevam o que o sistemadeverá 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,

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ãoentidades 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çãoproposta, e na sequência estão descritos os detalhes de cada um dos itens do diagrama.

Figura 9 – Diagrama de casos de uso

49

4.2.1 Coletar dados sobre um defeito

Descrição:Permite aos atores registrar dados qualitativos sobre um defeito de pavimentaçãoespecí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 paraconsulta.

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 aoator.

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 fotografiacaptura a qualquer momento.

∙ Se não for possível obter localização, o sistema informa o usuário e encerra ocaso de uso sem efetuar a coleta.

∙ Caso o dispositivo não possua câmera, o sistema informa o usuário e encerra ocaso 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.

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.


Pré-Condições:





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.





∙ O ator poderá cancelar a operação a qualquer momento.

∙ Antes da confirmação do envio o ator poderá alterar sua avaliação a qualquermomento.



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 dispositivo deve estar posicionado com a tela para cima sobre o console doveículo.



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.





∙ O ator poderá encerrar a operação a qualquer momento.

52



4.2.4 Transmitir dados

Descrição:Envia os dados informados ao servidor.

Atores:Outros casos de uso.

Pré-Condições:


Resultados:Os dados transmitidos devem ser recebidos e persistidos pela aplicação servidor.


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) aocaso de uso ator.



∙ Se houver perda de conexão durante a transmissão o caso de uso é encerradocom 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.

53


Pré-Condições:


Resultados:Os dados devem ser exibidos ao ator.


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.


∙ Se a conexão de dados estiver indisponível o sistema informa o ator e o casode uso é encerrado com erro.

∙ Se houver perda de conexão durante a transmissão o sistema informa o ator eo 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.


Pré-Condições:


Resultados:

54

∙ Exibição ao ator de uma lista com os dados coletados que ainda não foramtransmitidos.

∙ Em caso de re-transmissão os dados, estes devem estar registrados na base dedados e disponíveis para consulta.


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 umalista.

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.


∙ 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.


1. O ator solicita dados informando uma localização (latitude e longitude) e umraio (em metros).

2. O sistema consulta a base de dados com os parâmetros informados.

55

3. O sistema cria uma mensagem de retorno com os dados selecionados.

4. A mensagem de retorno é enviada ao ator.


∙ 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ânciasdas 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.


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.


∙ 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 ArquiteturaConforme 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 naimplementação do sistema. Nesta etapa serão criados diversos modelos que representam

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 cumprimentodos requisitos e casos de uso especificados na etapa anterior.

Para esta solução será adotada uma arquitetura cliente servidor, conforme sugeridopor Kanhere (2011), uma vez que para cumprir o objetivo proposto é necessário utilizaruma aplicação para coletar as informações e outra para centralizar e servir os dadoscoletados.

A estrutura cliente servidor adotada neste projeto está descrita no diagrama deimplantaçã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 querepresenta o repositório onde os dados coletados serão armazenados. Nas seções seguintesa 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 forneceraos usuários as funcionalidades relacionadas à coleta de dados. Para tanto neste artefatodeverão ser implementados os casos de uso: Coletar dados sobre um defeito, Coletar dadosem um trajeto, Coletar dados sobre uma via, Transmitir dados e Visualizar dados nãotransmitidos.

Para a implementação desta aplicação será utilizada a linguagem de programação

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 quepermitam 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 permitamque o usuário execute com poucos toques as atividades de coleta de informações. NaFigura 11 esta representado o fluxo de navegação através das interfaces da aplicaçãocliente.

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 umavisão de alto nível da aplicação na qual estão representadas suas dependências com outroscomponentes, os serviços externos necessários a suas funcionalidades e sua organizaçãointerna em pacotes.

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 evice versa;

∙ Spring Android REST e Core: facilitam a comunicação com a aplicação servidorprovendo formas de utilização simplificadas de chamadas a métodos HTTP quepermitem a transmissão dos dados coletados ao servidor;

∙ Google Play Services: contém diversas funcionalidades relacionadas aos serviços doGoogle. Para a aplicação Buraqueira serão utilizas as funções de geolocalização doserviç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çãode interfaces para os usuários, acesso a sensores, acesso ao sistema de arquivos, com-ponentes que permitem multitarefa e controle de permissões.

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 streetRatingonde no corpo da mensagem HTTP será enviado um documento JSON no formatoGeoJSON contendo informações sobre a avaliação feita pelo usuário sobre uma viaespecífica.

∙ streetDefectRatingHTTPPost: invocação de um método HTTP post no endereçostreetDefectRating onde no corpo da mensagem HTTP será enviado um documentoJSON 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çostreetSurfaceData onde no corpo da mensagem HTTP será enviado um documentoJSON no formato GeoJSON contendo dados coletados pela aplicação durante otrajeto 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 internado artefato Buraqueira.apk representando os pacotes e componentes implementados paraa 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 paraos 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. Umacaracterística importante é a utilização de um pacote interno para organização dasclasses 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 relevantespara a aplicação como localização e aceleração do dispositivo.

Na Figura 13 está representada uma visão estrutural mais detalhada dos principaiscomponentes internos da aplicação Buraqueira.

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 implementadasuma atividade unitária que pode ser realizada pelo usuário. No modelo estrutural acimaoptou-se por utilizar uma atividade, a MainActivity como maneira de direcionar o usuáriopara 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 executadosem 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áficasão: CollectedDataToTransmitActivity responsável pela interface de listagem e re-envioao servidor de dados coletados, armazenados localmente e que ainda não foram trans-mitidos ao servidor; DefectCollectionActivity controla a interface que permite ao usuáriocoletar informações sobre um defeito específico na via; StreetRatingDialog disponibilizauma 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 plataformasAndroid é o Service, ou serviço, que permite a implementação de funcionalidades utilitáriasque são executadas em segundo plano. Este elemento da plataforma Android é utilizadona aplicação Buraqueira para criar classes ativas que, uma vez iniciadas, controlam seu

62

próprio fluxo de execução e possuem suas próprias Threads. Estes serviços são utilizadospara coleta, processamento e transmissão dos dados da aplicação. Algumas das razõespara o uso deste tipo de estrutura são: garantia da responsividade da interface gráficapara o usuário, reduzir ao mínimo possível a perda de dados informados pelos sensores emelhorar 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 asolução, conforme definido anteriormente. Nesta seção será detalhada a modelagem destesdados para utilização na aplicação cliente. O diagrama Figura 14 possui uma representaçãoda 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çãocliente e servidor, optou-se por adotar um componente externo para efetuar a conversãode objetos Java em notação JSON e vice versa. O processo, conhecido como marshalling eunmarshalling, é feito utilizando o componente GSON. Para garantir a correta geração dosdados em notação GeoJSON foi necessária a utilização de classes adicionais com variáveisde classe que correspondessem ao formato de saída desejado. As classes adicionais foramorganizadas no pacote domain/gson e estão representadas no diagrama da Figura 15.

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 Geometrydo 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 comoabaixo:

1 {2 " type " : " Feature " ,3 " geometry " : {4 " type " : " Point " ,5 " c oo rd ina t e s " : [ ’ l ong i tude ’ , ’ l a t i t u d e ’ ]6 } ,7 " p r o p e r t i e s " : {8 " userRat ing " : ’ nota ’ ,9 " timestamp " : ’ timestamp ’ ,

10 " dataType " : " s t r e e t _ r a t i n g "11 }12 }

64

Avaliação de defeitos

Objeto em notação GeoJSON do tipo Feature utilizando um elemento Geometrydo tipo Point para armazenar o local onde o defeito foi encontrado e associá-lo à nota eimagem informados pelo usuário. A notação completa é definida como abaixo:

1 {2 " type " : " Feature " ,3 " geometry " : {4 " type " : " Point " ,5 " c oo rd ina t e s " : [ ’ l ong i tude ’ , ’ l a t i t u d e ’ ]6 } ,7 " p r o p e r t i e s " : {8 " dataType " : " s t r e e t _ d e f e c t " ,9 " userRat ing " : ’ 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 Geometrydo tipo LineString para armazenar um trecho do trajeto percorrido em conjunto com asinformaçõ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 cadaeixo. Como em um único trecho são efetuadas diversas leituras os objetos com dados deaceleração são armazenados em um array. A notação completa é definida como abaixo:

1 {2 " type " : " Feature " ,3 " geometry " : {4 " type " : " L ineSt r ing " ,5 " c oo rd ina t e s " : [ [ ’ 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 ’ ] , [

’ l ong i tudeF ina l ’ , ’ l a t i t u d e F i n a l ’ ] ]6 } ,7 " p r o p e r t i e s " : {8 " dataType " : " s t ree t_sur face_data " ,9 " startTimestamp " : ’ timestamp ’ ,

10 " endTimestamp " : ’ timestamp ’ ,11 " co l l e c t edSenso rData " : [12 {13 " xAccel " : " va l o r da a c e l . no e ixo X" ,14 " yAccel " : " va l o r da a c e l . no e ixo Y" ,15 " zAcce l " : " va l o r da a c e l . no e ixo Z" ,16 " timestamp " : ’ timestamp ’17 }

65

18 ]19 }20 }

Finalmente, para garantir que os dados não se percam, caso a transmissão aoservidor não seja possível, foi necessário o uso de uma técnica de persistência. No casooptou-se pela persistência simples dos documentos JSON em formato texto escritos emarquivos 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 dedados 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çãocom 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ãoserão apresentados os fluxos principais de maneira à estabelecer uma relação com os casosde uso propostos para esta solução e entender como são realizados pelos componentes daaplicação.

O primeiro modelo na Figura 16 explora a execução bem sucedida do caso do usoColetar dados sobre uma via, no qual o usuário interage com a interface gráfica parafornecer 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 usoColetar dados sobre um defeito, no qual o usuário utiliza a câmera fotográfica disponível

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 defeitoespecí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 mesmotempo. Durante a execução temos a interação com dois serviços paralelos que coletamde maneira independente a aceleração e a localização, após a sinalização do término dacoleta 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 respectivosdados de aceleração. Finalmente, o último serviço é utilizado para envio dos dados aoservidor. 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 leiturainformadas pelos sensores.

67

Figura 18 – Diagrama de sequência - Coleta bem sucedida dos dados sobre a superfície do trajeto realizadopelo 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ãotransmitidos 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

68

serviço em plano de fundo que se comunica com a aplicação servidor utilizando requisiçõesHTTP 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 servidorresponsá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çãoserá utilizada a linguagem de programação Java além de componentes selecionados quecolaborem 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 é apresentadano diagrama de componentes da Figura 20. Analogamente ao diagrama utilizado para aaplicação cliente, neste também é possível identificar os principais pacotes, componentese interfaces fornecidas pela aplicação.

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 funcionalidadede conversão de objetos Java em notação JSON e vice versa;

∙ Spring Framework: possui um conjunto de ferramentas e bibliotecas que permitemo 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çãointerna da aplicação servidor com seus pacotes e componentes:

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 peloservidor;

∙ domain: conjunto de classes análogo ao da aplicação cliente com implementações dasclasses 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 basede dados;

∙ repository: contém as classes repositório responsáveis por prover os serviços de acessoaos objetos de domínio armazenados na base de dados.

Na Figura 21 é apresentado um diagrama de classes com uma visão estruturaldetalhada dos componentes internos da aplicação servidor.

Figura 21 – Diagrama de classes da aplicação Buraqueira Server

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 aadoção de seus modelos de desenvolvimento. Como resultado obtêm-se uma estruturasimplificada 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. Paraexecutar as interações com as classes repositório optou-se por utilizar a classe Buraqueiracomo 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 clientepara 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 daaplicaçã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 aavaliação feita pelo usuário sobre uma via específica.

∙ streetDefectRatingHTTPPost: disponibiliza uma URL com endereço streetDefectRatingpara invocação de um método HTTP post, na qual no corpo da mensagem HTTPserá 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 streetSurfaceDatapara invocação de um método HTTP post, na qual no corpo da mensagem HTTPserá enviado um documento JSON no formato GeoJSON contendo dados coletadospela 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 quedevem ser invocados utilizando o método HTTP get que retornará a lista dos dadosarmazenados. Essa implementação atende aos propósitos da prova de conceito mas deveser ampliada em uma aplicação de produção para permitir a parametrização do local, raiode 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

72

componentes. Os modelos estão representados na Figura 14 e na Figura 15 apresentadosem 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 omesmo procedimento de marshalling e unmarshalling no servidor garante-se que os dadosnão serão corrompidos ou perdidos, ao mesmo tempo em que simplifica-se o processo decomunicação.

Para a persistência das informações foi escolhida uma base de dados baseada emdocumentos 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 omelhor modelo ou ferramenta de banco de dados para este tipo de aplicação foge ao escopodeste trabalho, foi escolhida portanto uma ferramenta que simplificasse o desenvolvimentodesta 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 pelasinteraçõ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 tempode 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 estabelecera 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 executadois tipos de operação: a obtenção e o recebimento de dados. Portanto optou-se por criarapenas um modelo para cada operação uma vez que a sequência de execução é a mesmavariando-se apenas o tipo de dado que esta sendo manipulado.

O modelo apresentado na Figura 22 aborda o fluxo bem sucedido do caso de usoArmazenar dados, no qual a aplicação recebe uma solicitação HTTP post para a URLde um tipo de dado específico e os componentes lidam com as ações necessárias paraarmazenar o documento GeoJSON contendo as informações na base de dados.

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 dedados específico e seus componentes internos executam as ações necessárias para obter osdados e retorná-los para o ator que os solicitou.

Figura 23 – Diagrama de sequência - Obtenção de Dados

4.4 TestesNesta 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 quepossui conexão com rede de dados, GPS, acelerômetros e a versão Ice Cream Sandwichdo 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 .

http://www.motorola.com.br/consumers/MOTOROLA-RAZR/80859,pt_br,pd.html

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 Coletardados sobre uma via. Ao ativar a opção para avaliar uma via, a aplicação cliente exibe ainterface como na Figura 24, onde já são apresentadas as informações de posicionamentodo 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 enviadosao servidor para persistência e podem ser acessados através do endereço sugerido nasespecificações com a execução de uma solicitação HTTP get como pode ser visto naFigura 25.

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 encontradono 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 sobreum 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çõesde localização do usuário e permite que seja acionada a câmera do dispositivo além daclassificação do defeito. Após a obtenção da fotografia e classificação, a aplicação exibe ainterface conforme Figura 26.

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çãode 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

77

Um exemplo do documento GeoJSON gerado para esta coleta pode ser encontradono 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 Coletardados em um trajeto é um dos procedimento mais complexos pois envolve a utilização deum veículo para obtenção dos dados, neste teste foi utilizado um automóvel VolkswagenGol2.

Para a realização dos testes o smartphone foi colocado em um dos porta objetosdo 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 é acionadoe 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ículoconforme 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/.

http://www.vw.com.br/

http://www.vw.com.br/

78

Figura 29 – Testes - Trajeto percorrido durante a coleta

Percorrido o trecho onde desejava-se efetuar a coleta, o condutor aciona o comandopara desativar a coleta de dados, a aplicação organiza os dados e e em seguida os enviaao servidor para persistência. Portanto as informações podem ser acessados através doendereço sugerido nas especificações com a execução de uma solicitação HTTP get comopode ser visto na Figura 30.

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 serencontrado no Apêndice C.

Para o trajeto escolhido para execução dos testes foram levantadas as informaçõesrelatadas na Tabela 3.

Tabela 3 – Estatística de Percurso

Distância percorrida Aproximadamente quatorze quilômetrosTempo de percurso Aproximadamente 30 minutosQuantidade de subdivisões geradas 158 trechosDistância média percorrida em cada trecho Aproximadamente 94 metrosNúmero médio de leituras de aceleração por eixo Aproximadamente 282 leituras por trechoQuantidade de dados gerada 3,2 MegaBytes

A partir dos dados coletados é possível avaliar se a correlação gerada entre dadosgeográficos e dados de aceleração dos sensores do dispositivo faz sentido. Para a prova deconceito 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 ferramentaGoogle (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 eopinião do condutor do veículo sobre o percurso os quais podem ser considerados comobom, regular e ruim de acordo com as classificações da Tabela 1. Em seguida foramgerados mapas com a marcação do trecho ao qual refere-se a avaliação, além de gráficosem linha com as informações coletadas pelos acelerômetros apresentadas em 𝑚/𝑠2 aolongo do tempo de trajeto. Nesta análise considera-se que os dados de aceleração do eixoZ são os mais importante para os experimentos, uma vez que este eixo está alinhado com

80

o eixo Z do veículo e seus dados representam diretamente o efeito causado por defeitos eimperfeiçõ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êsanos, 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 observarapenas 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

81

Trecho com avaliação Regular - Rua Caopia

A rua referente a este trecho possui diversas imperfeições e aparentemente nãopassa 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


O gráfico apresentado na Figura 34 reflete os dados coletados pelos acelerômetrosno percurso, ao analisar os dados do eixo Z percebe-se um número maior de picos comaceleração acima de 0,5𝑚/𝑠2 e ao menos quatro picos com aceleração acima de 1𝑚/𝑠2 oque 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. Aoanalisar os dados de aceleração no eixo Z no final do percurso é possível observar umacurva de aceleração mais suave, representada por um segmento de senoide. Este tipo deleitura poderia ajudar a identificar este perfil de obstáculo e os diferenciar de defeitos ououtras 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 avaliadopelo condutor como ruim, parte da via não esta pavimentada possuindo paralelepípedos

82

e defeitos aparentes. O trajeto é apresentado na Figura 35.

Figura 35 – Trajeto classificado como Ruim pelo condutor


Os dados apresentados no gráfico da Figura 36 demostram o impacto de umavia 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çãodos três eixos é intensa e possui trechos onde a aceleração coletada no eixo Z chega a3𝑚/𝑠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ículodeixa o trecho ruim da via e segue por um trecho com a pavimentação asfáltica comquantidade de imperfeições inferior, a variação na aceleração é bem menor e muito maisuniforme 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 comoboas é possível observar a variação de aceleração nas leituras. Acredita-se que as leitu-

83

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

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 osprincipais 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õesNo 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 sensoriamentoparticipativo à coleta de informações sobre a pavimentação viária. Com base nas pesquisasrealizadas foi desenvolvido um sistema cliente servidor, no qual o uso da aplicação clientemostrou-se bem sucedido na coleta da opinião do usuário sobre vias e defeitos, fotografiasde 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 cumprindoseu papel no armazenamento e disponibilização dos dados coletados.

Os testes e experimentos da prova de conceito também permitiram uma análiseinicial dos dados coletados pela aplicação, dos quais destacam-se os dados quantitativoslevantados durante o uso da aplicação cliente em trajetos. Foi possível observar que mesmoutilizando 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, serianecessário um esforço adicional para tratá-las e retirar ruídos gerados por componentesdo 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-senecessá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á-lauma plataforma mais robusta e com mais funcionalidades para lidar com as informaçõesarmazenadas.

85

5.2 Sugestões para Trabalhos FuturosBaseando-se na complexidade do projeto e nas dificuldades encontradas durante as

pesquisas e desenvolvimento, foram identificados diversos pontos que podem ser utilizadospara continuar, aprofundar e melhorar a solução proposta. Abaixo segue uma lista dosprincipais itens identificados:

∙ Ajuste automático da orientação dos dados coletados pelo dispositivo ao eixo decoordenadas 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çãode camadas de dados com os mapas viários;

∙ Análise dos dados coletados e derivação dos índices de qualidade de pavimentaçãoutilizando 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 umaclassificaçã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 comobase de algoritmos de visão computacional que ao processar imagens em câmerasidentificassem os defeitos em vias e acionassem medidas corretivas automaticamente.

Entende-se que esta não é uma lista definitiva de estudo, mas é esperado que estassugestões possam inspirar e motivar futuros estudos baseados neste trabalho.

5.3 Trabalhos RelacionadosAo longo das pesquisas e do projeto foram encontradas ferramentas e iniciativas que

possuem funcionalidades que se relacionam com a proposta apresentada. Nas ferramentas

86

encontradas a proposta principal é ajudar no mapeamento de defeitos nas vias para queseja 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 dosrecursos dos smartphones dos usuários para proporcionar uma coleta constante e proativapara colaborar na previsão dos problemas antes que eles ocorram. Abaixo segue uma listacom 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).

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 emCidades de Médio Porte. Dissertação (Mestrado) — Universidade de São Paulo, SãoCarlos, 2012.

BERNHARDSEN, T. Geographic Information Systems: An Introduction. Arendal: JohnWiley & 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): Mobiledevice 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 dePequeno 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ãoPaulo - 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 econtrole de sistemas medidores de irregularidades de superfície de pavimento (SistemasIntegradores IPR/USP e Maysmeter). Rio de Janeiro, 1994. 18 p.

DEPARTAMENTO NACIONAL DE ESTRADAS E RODAGEM. Medição deirregularidade de superfície de pavimento com sistemas integradores IPR/USP emaysmeter. 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.

http://source.android.com/

http://www.geojson.org/geojson-spec.html

http://cidadera.com/

http://cidadera.com/

http://colab.re/

http://www.detran.sp.gov.br/wps/portal/detran/odetran/estatisticasdotransito/

http://www.detran.sp.gov.br/wps/portal/detran/odetran/estatisticasdotransito/

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 TratorAgrí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/>. Acessoem: 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 FeaturePhones 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 vibrationand shock - Evaluation of human exposure to whole-body vibration: Part 1: Generalrequirements. 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 smartphonesin urban spaces. In: Mobile Data Management (MDM), 2011 12th IEEE InternationalConference on. [S.l.: s.n.], 2011. v. 2, p. 3–6.

CONGRESSO LUSO BRASILEIRO PARA O PLANEAMENTO URBANO REGIONALINTEGRADO E SUSTENTáVEL, 2., 2006, Braga. Anais...: A prática de gestão depavimentos em cidades médias brasileiras. 209 p.

MAIA, R. H. Análise da Sensibilidade Aplicada a Estudos de Conforto Vibracionalem Automóveis. Dissertação (Mestrado) — Pontifícia Universidade Católica de MinasGerais, Belo Horizonte, 2002.

MY FUN CITY. Brasil, 2012. Disponível em: <http://www.myfuncity.org/>. Acessoem: 20.5.2013.

http://www.fixmystreet.com.br/

http://www.fixmystreet.com.br/

http://www.android.com/

http://maps.google.com.br/

http://developer.android.com/guide/topics/sensors/sensors_motion.html

http://developer.android.com/guide/topics/sensors/sensors_motion.html

http://developer.android.com/guide/topics/sensors/sensors_overview.html

http://developer.android.com/guide/topics/sensors/sensors_overview.html

http://www.springsource.org/spring-framework

http://www.springsource.org/spring-framework

http://www.idc.com/getdoc.jsp?containerId=prUS23982813

http://www.idc.com/getdoc.jsp?containerId=prUS23982813

http://www.json.org

http://www.myfuncity.org/

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 PavimentoMunicí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. NovaIorque: 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.

http://www.gps.gov/systems/gps/

http://www.gps.gov/systems/gps/

http://www.openhandsetalliance.com/android_overview.html

http://www.openhandsetalliance.com/android_overview.html

http://infocidade.prefeitura.sp.gov.br/htmls/11_extensao_de_vias_pavimentadas_por_tipo_d_2004_492.html



http://bandnewsfm.band.uol.com.br/buracometro.aspx

http://bandnewsfm.band.uol.com.br/buracometro.aspx

http://www.sulamericatransito.com.br/modal/login?apos=buraco

http://www.waze.com/

Apêndices

91

APÊNDICE A – Documento GeoJSON:Exemplo de Coleta deDados Sobre uma Via

1 {2 " type " : " Feature " ,3 " geometry " : {4 " type " : " Point " ,5 " c oo rd ina t e s " : [ −46.5297072 , −23.6056439]6 } ,7 " p r o p e r t i e s " : {8 " dataType " : " s t r e e t _ r a t i n g " ,9 " userRat ing " : 1 . 5 ,

10 " timestamp " :138178080069311 }12 }

92

APÊNDICE B – Documento GeoJSON:Exemplo de Coleta deDados Sobre um Defeito

1 {2 " type " : " Feature " ,3 " geometry " : {4 " c oo rd ina t e s " : [ −46.5297498 , −23.6056361] ,5 " type " : " Point "6 } ,7 " p r o p e r t i e s " : {8 " dataType " : " s t r e e t _ d e f e c t " ,9 " image " : " /9 j /4AAQSkZJRgABAQAAAQABAAD/2

wBDAAoHBwgHBgoICAgLCgoLDhgQDg0NDh0VFhEYIx8lJCIf<imagem truncadapropos i ta lmente >" ,

10 " timestamp " :1381780566426 ,11 " userRat ing " : 2 . 9 }12 }

93

APÊNDICE C – Documento GeoJSON:Exemplo de Coleta de Da-dos Sobre a Superfície deuma Via

1 {2 " type " : " Feature "3 " geometry " : {4 " c oo rd ina t e s " : [ [ −46 .5297682 , −23 .6056358 ] , [ −46 .531009 , −23 .6063914 ] ] ,5 " type " : " L ineSt r ing "6 } ,7 " p r o p e r t i e s " : {8 " co l l e c t edSenso rData " : [9 { " timestamp " :1380616596851 , " xAccel " : −0.54230785 , " yAccel "

: 0 . 4 31983 , " zAcce l " : 3 . 5465746} ,10 { " timestamp " :1380616596878 , " xAccel " : −0.3112632 , " yAccel "

: 0 . 22300327 , " zAcce l " : 2 . 898551} ,11 { " timestamp " :1380616596891 , " xAccel " : −0.06513584 , " yAccel "

: 0 . 11711109 , " zAcce l " : 2 . 8091736} ,12 { " timestamp " :1380616596911 , " xAccel " : 0 . 070474505 , " yAccel "










: 0 . 117617965 , " zAcce l " : 0 . 2930889} ,

94

22 { " timestamp " :1380616597111 , " xAccel " : 0 . 48367053 , " yAccel ": 0 . 5844269 , " zAcce l " : 0 . 050596237} ,

23 { " timestamp " :1380616597132 , " xAccel " : 0 . 63210267 , " yAccel ": 0 . 46754146 , " zAcce l " : −0.57243824} ,

24 { " timestamp " :1380616597153 , " xAccel " : 0 . 5669737 , " yAccel ": 0 . 19015849 , " zAcce l " : −0.7644081} ,

25 { " timestamp " :1380616597173 , " xAccel " : −0.036753535 , " yAccel ": −0.27691412 , " zAcce l " : −0.12119484} ,

26 { " timestamp " :1380616597193 , " xAccel " : −0.45844388 , " yAccel ": −0.58928066 , " zAcce l " : 1 . 1288757}

27 ] ,28 " endTimestamp " :1380617959761 ,29 " startTimestamp " :1380617953017 ,30 " dataType " : " s t ree t_sur face_data "31 }32 }

implementation of a participatory sensing solution to collect data about pavement condition

Technology