Eduardo Carrara de Araujo
Implementação de uma Aplicação de
Sensoriamento Participativo para Coleta de
Informações Sobre a...
Eduardo Carrara de Araujo
Implementação de uma Aplicação de Sensoriamento
Participativo para Coleta de Informações Sobre a...
Ficha catalográfica elaborada pela Biblioteca do Centro Universitário Senac
A663i Araujo, Eduardo Carrara
Implementação de...
Eduardo Carrara de Araujo
Implementação de uma aplicação de sensoriamento participa-
tivo para coleta de informações sobre...
Este projeto é dedicado à todas as pessoas que acreditam que o trabalho coletivo é
capaz de revolucionar a maneira de solu...
Agradecimentos
À todos os meus amigos que colaboraram na criação e elaboração da ideia. Além
de proporcionar discussões se...
"We can’t solve problems by using the same kind of thinking we used when we created
them."
Albert Einstein
Resumo
O foco deste trabalho é o desenvolvimento de uma proposta alternativa para avaliar
a condição da pavimentação viári...
Abstract
The focus of this work is the development of an alternative proposition to evaluate
the pavement conditions for a...
Lista de ilustrações
Figura 1 – Estrutura de um Sistema de Gerência de Pavimentos . . . . . . . . . . 19
Figura 2 – Proces...
Figura 29 –Testes - Trajeto percorrido durante a coleta . . . . . . . . . . . . . . . 78
Figura 30 –Testes - Obtenção dos ...
Lista de tabelas
Tabela 1 – Níveis de serventia . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
Tabela 2 – Co...
Lista de abreviaturas e siglas
API Application Programming Interfaces
DETRAN Departamento de Trânsito
DNER Departamento Na...
Lista de símbolos
∑︀
Letra grega Sigma
Hz Hertz
g Medida de aceleração
Sumário
1 Introdução . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
2 Estado da Arte . . . ....
4.1.8 Sistema operacional do smartphone . . . . . . . . . . . . . . . . . . 46
4.1.9 Uso de ferramentas e serviços livres ...
APÊNDICE B Documento GeoJSON: Exemplo de Coleta de Dados Sobre
um Defeito . . . . . . . . . . . . . . . . . . . . . . . . ...
17
1 Introdução
A infraestrutura das cidades, na forma de serviços e equipamentos, colabora com o
funcionamento e execução...
18
de avaliação no planejamento da manutenção e evolução da malha viária das cidades.
Entende-se que o crescente interesse...
19
2 Estado da Arte
2.1 Sistemas de Gerenciamento de Pavimentos (SGP)
A pavimentação viária representa um recurso valioso ...
20
Figura 2 – Processo para um Sistema de Gerência de Pavimentos
Fonte: Shahin (1994, p. 340)
No Brasil, o Departamento Na...
21
atividades, o DNIT (2011) ressalta sua importância como insumo para o processo deci-
sório do sistema, sua execução pos...
22
Após a coleta das avaliações, o VSA é calculado para cada trecho da via de acordo
com a fórmula (2.1) abaixo:
𝑉 𝑆𝐴 =
∑︀...
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...
24
entender e mensurar as irregularidades está em sua correlação com os custos e qualidade
de serviço entregue aos usuário...
25
As irregularidades presentes nas superfícies das vias são transmitidas aos passa-
geiros na forma de vibrações através ...
26
cessamento computacional e facilidades no acesso a dados. Além das tradicionais funcio-
nalidades de comunicação por vo...
27
∙ acessibilidade: voz para texto, texto para voz, tamanho de fonte, recursos de resposta
etc;
∙ aplicações: agenda, câm...
28
Figura 5 – Sistema de coordenadas relativas ao dispositivo
Fonte: Google (2013d)
2.3.4 Sistema de Posicionamento Global...
29
A integração de receptores GPS em dispositivos Android tem se tornado comum.
Conhecer o posicionamento do usuário do di...
30
do ar, monitoramento de níveis de ruído, monitoramento de pavimentos e condições
de tráfego.
Ainda segundo Kanhere (201...
31
Bass, Clements e Kazman (2012) argumentam que a complexidade presente nos
software modernos frequentemente torna muito ...
32
O papel do arquiteto é orientar o projeto da arquitetura do sistema, seu conheci-
mento técnico é essencial para colabo...
33
2.5.2 Arquitetura Cliente - Servidor
Segundo Sommerville (2003), Bass, Clements e Kazman (2012), este é um modelo
de si...
34
Figura 6 – Arquitetura cliente servidor para um sistema bancário de caixas eletrônicos
Fonte: Bass, Clements e Kazman (...
35
Uma visão geral da abrangência de sistemas de informações geográficas é apresen-
tada na Figura 7.
Figura 7 – GIS: Abra...
36
A UML (Unified Modeling Language) é uma linguagem padrão de modelagem cri-
ada para visualizar, especificar, construir ...
37
por Patrick Naughton, Mike Sheridan, e James Gosling. Se enquadra no paradigma de
linguagens orientadas à objetos, é in...
38
∙ Suporte avançado a programação orientada a aspectos;
∙ Suporte à transações declarativas, caching declarativo, valida...
39
Uma extensão ao JSON relevante para este trabalho é o Geospacial JSON. Segundo
sua especificação em Butler et al. (2008...
40
3 Oportunidade
Nos capítulos 1 e 2 foram apresentados os conceitos relacionados a gestão da pa-
vimentação viária e com...
41
manutenção da capacidade funcional das vias públicas, abre espaço para o desenvolvi-
mento de uma solução que tenha com...
42
4 Proposta
O processo para coleta de informações sobre o estado atual da pavimentação viária
está intimamente relaciona...
43
transmitidas aos sensores do smartphone. Além disso, podem ser obtidos dados
qualitativos, como a opinião do usuário so...
44
Para atingir o objetivo proposto a solução deverá realizar os requisitos abaixo
detalhados.
4.1.1 Dados quantitativos e...
45
Os dados a serem coletados são as leituras de aceleração durante todo o trajeto;
dados de posicionamento durante o traj...
46
∙ Defeitos específicos terão suas localizações apontadas no mapa por marcadores que
ao serem selecionados exibirão todo...
47
em diversas faixas de preços e grande número de funcionalidades. Essas características
garantem uma grande abrangência ...
48
quando executados, produzem algo de valor ao usuário final. Nesta forma de representa-
ção, os papéis desempenhados pel...
49
4.2.1 Coletar dados sobre um defeito
Descrição:
Permite aos atores registrar dados qualitativos sobre um defeito de pav...
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...
51
4.2.3 Coletar dados em um trajeto
Descrição:
Viabiliza a coleta de dados quantitativos sobre a superfície da pavimentaç...
52
∙ Se não for possível obter localização, o sistema informa o usuário e encerra o
caso de uso sem efetuar a coleta.
∙ Se...
53
Atores:
Pedestre, Motorista
Pré-Condições:
∙ Uma conexão de dados deve estar ativa.
Resultados:
Os dados devem ser exib...
54
∙ Exibição ao ator de uma lista com os dados coletados que ainda não foram
transmitidos.
∙ Em caso de re-transmissão os...
55
3. O sistema cria uma mensagem de retorno com os dados selecionados.
4. A mensagem de retorno é enviada ao ator.
Exceçõ...
56
visões diferentes da solução a ser desenvolvida, possibilitando a decomposição e organiza-
ção do sistema em módulos, a...
57
Java em conjunto com as APIs da plataforma Android, além de alguns outros componen-
tes selecionados para acelerar o pr...
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 me...
59
Figura 12 – Diagrama de componentes da aplicação Buraqueira
Os componentes externos foram escolhidos para acelerar o de...
60
No diagrama também especifica-se a necessidade de algumas interfaces externas.
Neste caso as interfaces definem funções...
61
Figura 13 – Diagrama de classes da aplicação Buraqueira
De maneira geral as aplicações Android são centradas nas intera...
62
próprio fluxo de execução e possuem suas próprias Threads. Estes serviços são utilizados
para coleta, processamento e t...
63
Figura 15 – Diagrama de classes dos elementos GeoJSON
Identificou-se a necessidade de três documentos GeoJSON para aten...
Implementation of a Participatory Sensing Solution to Collect Data About Pavement Condition
Implementation of a Participatory Sensing Solution to Collect Data About Pavement Condition
Implementation of a Participatory Sensing Solution to Collect Data About Pavement Condition
Implementation of a Participatory Sensing Solution to Collect Data About Pavement Condition
Implementation of a Participatory Sensing Solution to Collect Data About Pavement Condition
Implementation of a Participatory Sensing Solution to Collect Data About Pavement Condition
Implementation of a Participatory Sensing Solution to Collect Data About Pavement Condition
Implementation of a Participatory Sensing Solution to Collect Data About Pavement Condition
Implementation of a Participatory Sensing Solution to Collect Data About Pavement Condition
Implementation of a Participatory Sensing Solution to Collect Data About Pavement Condition
Implementation of a Participatory Sensing Solution to Collect Data About Pavement Condition
Implementation of a Participatory Sensing Solution to Collect Data About Pavement Condition
Implementation of a Participatory Sensing Solution to Collect Data About Pavement Condition
Implementation of a Participatory Sensing Solution to Collect Data About Pavement Condition
Implementation of a Participatory Sensing Solution to Collect Data About Pavement Condition
Implementation of a Participatory Sensing Solution to Collect Data About Pavement Condition
Implementation of a Participatory Sensing Solution to Collect Data About Pavement Condition
Implementation of a Participatory Sensing Solution to Collect Data About Pavement Condition
Implementation of a Participatory Sensing Solution to Collect Data About Pavement Condition
Implementation of a Participatory Sensing Solution to Collect Data About Pavement Condition
Implementation of a Participatory Sensing Solution to Collect Data About Pavement Condition
Implementation of a Participatory Sensing Solution to Collect Data About Pavement Condition
Implementation of a Participatory Sensing Solution to Collect Data About Pavement Condition
Implementation of a Participatory Sensing Solution to Collect Data About Pavement Condition
Implementation of a Participatory Sensing Solution to Collect Data About Pavement Condition
Implementation of a Participatory Sensing Solution to Collect Data About Pavement Condition
Implementation of a Participatory Sensing Solution to Collect Data About Pavement Condition
Implementation of a Participatory Sensing Solution to Collect Data About Pavement Condition
Implementation of a Participatory Sensing Solution to Collect Data About Pavement Condition
Implementation of a Participatory Sensing Solution to Collect Data About Pavement Condition
Implementation of a Participatory Sensing Solution to Collect Data About Pavement Condition
Próximos SlideShares
Carregando em…5
×

Implementation of a Participatory Sensing Solution to Collect Data About Pavement Condition

210 visualizações

Publicada em

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

Publicada em: Tecnologia
0 comentários
1 gostou
Estatísticas
Notas
  • Seja o primeiro a comentar

Sem downloads
Visualizações
Visualizações totais
210
No SlideShare
0
A partir de incorporações
0
Número de incorporações
10
Ações
Compartilhamentos
0
Downloads
10
Comentários
0
Gostaram
1
Incorporações 0
Nenhuma incorporação

Nenhuma nota no slide

Implementation of a Participatory Sensing Solution to Collect Data About Pavement Condition

  1. 1. Eduardo Carrara de Araujo Implementação de uma Aplicação de Sensoriamento Participativo para Coleta de Informações Sobre a Qualidade da Pavimentação Viária São Paulo 2013
  2. 2. Eduardo Carrara de Araujo Implementação de uma Aplicação de Sensoriamento Participativo para Coleta de Informações Sobre a Qualidade da Pavimentação Viária Trabalho de conclusão de curso apresentado ao Centro Universitário Senac - Campus Santo Amaro, como exigência parcial para a conclusão do curso de Pós-Graduação em Tecnologias e Arquiteturas na Construção de Software. Centro Universitário Senac Orientador: Prof. Msc Daniel Paz de Araujo São Paulo 2013
  3. 3. Ficha catalográfica elaborada pela Biblioteca do Centro Universitário Senac A663i Araujo, Eduardo Carrara Implementação de uma aplicação de sensoriamento participativo para coleta de informações sobre a qualidade da pavimentação viária / Eduardo Carrara de Araujo – São Paulo, 2013. 93 p. : il. color. Orientador: Prof. Daniel Paz de Araujo Trabalho de Conclusão de Curso (Pós-Graduação em Tecnologias e Arquiteturas na Construção de Software) – Centro Universitário Senac, São Paulo, 2013. 1. Sensoriamento participativo 2. Qualidade da pavimentação viária 3. Tecnologias em mobilidade 4. Arquitetura de software 5. Arquitetura cliente servidor I. Araujo, Daniel Paz de (Orient.) II. Título CDD 005.1
  4. 4. Eduardo Carrara de Araujo Implementação de uma aplicação de sensoriamento participa- tivo para coleta de informações sobre a qualidade da pavi- mentação viária Trabalho de conclusão de curso apresentado ao Centro Univer- sitário Senac - Campus Santo Amaro, como exigência parcial para a conclusão do curso de Pós-Graduação em Tecnologias e Arquiteturas na Construção de Software. Orientador Prof. Msc Daniel Paz de Araujo A banca examinadora dos Trabalhos de Conclusão, em sessão pública realizada em ___/___/____, considerou o(a) candidato(a): 1. Examinador(a) 2. Examinador(a) 3. Presidente
  5. 5. Este projeto é dedicado à todas as pessoas que acreditam que o trabalho coletivo é capaz de revolucionar a maneira de solucionar problemas, buscar o bem estar e a melhoria da sociedade em geral.
  6. 6. Agradecimentos À todos os meus amigos que colaboraram na criação e elaboração da ideia. Além de proporcionar discussões sem fim sobre as infinitas possibilidades de desenvolvimento e requisitos da solução. Ao meu orientador Prof. Msc Daniel Paz de Araujo pelas conversas, suporte e críticas tão valiosas à construção deste trabalho. À minha noiva pelas infinitas revisões, infinita paciência e inabalável confiança de que seria possível chegar ao fim de mais este caminho. À minha família por todo o incondicional apoio em todas as situações.
  7. 7. "We can’t solve problems by using the same kind of thinking we used when we created them." Albert Einstein
  8. 8. Resumo O foco deste trabalho é o desenvolvimento de uma proposta alternativa para avaliar a condição da pavimentação viária de uma cidade utilizando uma solução de senso- riamento participativo. Para fundamentar o projeto foram investigadas as propostas e normas na área de gestão de pavimentos, como é realizada a avaliação da pavi- mentação e os efeitos de uma qualidade de pavimentação ruim sobre os passageiros em veículos. Também foram realizadas pesquisas em sensoriamento participativo, tecnologias em mobilidade e engenharia de software de maneira à determinar como a relação destes temas pode colaborar com a solução do problema. Com esta fun- damentação foi possível realizar o projeto, análise e desenvolvimento de uma prova de conceito na forma de uma solução de software com arquitetura cliente servidor, na qual a aplicação cliente é utilizada na coleta dos dados e a aplicação servidor em seu armazenamento e disponibilização. A análise das informações quantitativas coletadas mostrou que é possível determinar a presença de defeitos e estimar a quali- dade da pavimentação mesmo com dispositivos de coleta simples como smartphones, além de viabilizar a coleta de medidas qualitativas que podem ajudar a mensurar o impacto da qualidade da pavimentação na opinião dos usuários das vias. Palavras-chave: 1. Sensoriamento Participativo. 2. Qualidade da Pavimentação Viária. 3. Tecnologias em Mobilidade. 4. Arquitetura de Software. 5. Arquitetura Cliente Servidor.
  9. 9. Abstract The focus of this work is the development of an alternative proposition to evaluate the pavement conditions for a given city using a participatory sensing solution. To substantiate the project the following areas had to be investigated: proposals and standards in pavement management, how the pavement evaluation is done and the effects of a bad quality pavement on the vehicle’s passengers. Research in the areas of participatory sensing, tecnologies in mobility and software engineering were done to ascertain how the relationship between these topics could collaborate in the problem’s solution. With this elements in place it was possible to design, analysis and develop a proof of concept as a software solution based in a client server architecture, in which the client application collects data and the server application handles the data storage and availability. The collected quantitative information analysis showed that it is possible to determine the presence of defects and assess the pavement quality even using simple collection devices like a smartphone, and also enable the collection of qualitative information that could help measure the pavement quality impact in the perspective of its users. Keywords: 1. Participatory Sensing. 2. Pavement Quality. 3. Mobility Technologies. 4. Software Architecture. 5. Client Server Architecture.
  10. 10. Lista de ilustrações Figura 1 – Estrutura de um Sistema de Gerência de Pavimentos . . . . . . . . . . 19 Figura 2 – Processo para um Sistema de Gerência de Pavimentos . . . . . . . . . 20 Figura 3 – Variação da serventia com o tráfego ou com o tempo decorrido de uti- lização da via . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23 Figura 4 – Diversas faixas de variação do IRI . . . . . . . . . . . . . . . . . . . . . 23 Figura 5 – Sistema de coordenadas relativas ao dispositivo . . . . . . . . . . . . . 28 Figura 6 – Arquitetura cliente servidor para um sistema bancário de caixas eletrô- nicos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34 Figura 7 – GIS: Abrangência . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35 Figura 8 – Proposta: Visão geral . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43 Figura 9 – Diagrama de casos de uso . . . . . . . . . . . . . . . . . . . . . . . . . 48 Figura 10 –Diagrama de implantação . . . . . . . . . . . . . . . . . . . . . . . . . 56 Figura 11 –Fluxo de interação com as interfaces para os usuários da aplicação cliente 58 Figura 12 –Diagrama de componentes da aplicação Buraqueira . . . . . . . . . . . 59 Figura 13 –Diagrama de classes da aplicação Buraqueira . . . . . . . . . . . . . . . 61 Figura 14 –Diagrama de classes dos elementos de dados da aplicação Buraqueira . 62 Figura 15 –Diagrama de classes dos elementos GeoJSON . . . . . . . . . . . . . . 63 Figura 16 –Diagrama de sequência - Coleta bem sucedida da opinião do usuário sobre uma via . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65 Figura 17 –Diagrama de sequência - Coleta bem sucedida da opinião do usuário sobre um defeito específico . . . . . . . . . . . . . . . . . . . . . . . . . 66 Figura 18 –Diagrama de sequência - Coleta bem sucedida dos dados sobre a su- perfície do trajeto realizado pelo usuário . . . . . . . . . . . . . . . . . 67 Figura 19 –Diagrama de sequência - Visualização e re-envio de dados não trans- mitidos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67 Figura 20 –Diagrama de componentes da aplicação Buraqueira . . . . . . . . . . . 69 Figura 21 –Diagrama de classes da aplicação Buraqueira Server . . . . . . . . . . . 70 Figura 22 –Diagrama de sequência - Armazenamento de Dados . . . . . . . . . . . 73 Figura 23 –Diagrama de sequência - Obtenção de Dados . . . . . . . . . . . . . . . 73 Figura 24 –Testes - Coleta da avaliação de uma via . . . . . . . . . . . . . . . . . 74 Figura 25 –Testes - Obtenção dos dados de avaliação de vias utilizando um navegador 75 Figura 26 –Testes - Coleta da avaliação de um defeito . . . . . . . . . . . . . . . . 76 Figura 27 –Testes - Obtenção dos dados de avaliação de defeitos utilizando um navegador . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76 Figura 28 –Testes - Posicionamento do dispositivo no interior do veículo . . . . . . 77
  11. 11. Figura 29 –Testes - Trajeto percorrido durante a coleta . . . . . . . . . . . . . . . 78 Figura 30 –Testes - Obtenção dos dados coletados em percursos utilizando um navegador . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79 Figura 31 –Trajeto classificado como Bom pelo condutor . . . . . . . . . . . . . . 80 Figura 32 –Dados obtidos durante o trajeto com classificação Bom . . . . . . . . . 80 Figura 33 –Trajeto classificado como Regular pelo condutor . . . . . . . . . . . . 81 Figura 34 –Dados obtidos durante o trajeto com classificação Regular . . . . . . . 81 Figura 35 –Trajeto classificado como Ruim pelo condutor . . . . . . . . . . . . . . 82 Figura 36 –Dados obtidos durante o trajeto com classificação Ruim . . . . . . . . 82
  12. 12. Lista de tabelas Tabela 1 – Níveis de serventia . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22 Tabela 2 – Condições Inaceitáveis às Vibrações Verticais . . . . . . . . . . . . . . 25 Tabela 3 – Estatística de Percurso . . . . . . . . . . . . . . . . . . . . . . . . . . . 79
  13. 13. Lista de abreviaturas e siglas API Application Programming Interfaces DETRAN Departamento de Trânsito DNER Departamento Nacional de Estradas e Rodagem DNIT Departamento Nacional de Infraestrutura em Transportes GIS Geographic Information Systems GPS Global Positioning System (Sistema de Posicionamento Global) HTTP HyperText Transfer Protocol IRI International Roughness Index (Índice de Irregularidade Internacional) JVM Java Virtual Machine NFC Near Field Communications PoC Proof of Concept (Prova de Conceito) QI Quoeficiente de Irregularidade SDK Software Development Kit SGP Sistema de Gestão de Pavimentos SP Estado de São Paulo localizado no Brasil UML Unified Modeling Language URL Uniform Resource Locator UTC Universal Time Coordinated VSA Valor de Serventia Atual XML eXtensible Markup Language
  14. 14. Lista de símbolos ∑︀ Letra grega Sigma Hz Hertz g Medida de aceleração
  15. 15. Sumário 1 Introdução . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17 2 Estado da Arte . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19 2.1 Sistemas de Gerenciamento de Pavimentos (SGP) . . . . . . . . . . . . . . 19 2.1.1 Avaliação da Condição de Pavimentos . . . . . . . . . . . . . . . . . 20 2.1.2 Valor de Serventia Atual (VSA) . . . . . . . . . . . . . . . . . . . . 21 2.1.3 Índice Internacional de Rugosidade (International Roughness Index - IRI) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23 2.2 Vibração e o Conforto em Veículos . . . . . . . . . . . . . . . . . . . . . . 24 2.3 Tecnologias em Mobilidade . . . . . . . . . . . . . . . . . . . . . . . . . . . 25 2.3.1 Telefones Móveis Inteligentes (Smartphones) . . . . . . . . . . . . . 25 2.3.2 Sistema Operacional Android . . . . . . . . . . . . . . . . . . . . . 26 2.3.3 Acelerômetros . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27 2.3.4 Sistema de Posicionamento Global . . . . . . . . . . . . . . . . . . 28 2.4 Sensoriamento Participativo . . . . . . . . . . . . . . . . . . . . . . . . . . 29 2.5 Tecnologias em Engenharia de Software . . . . . . . . . . . . . . . . . . . . 30 2.5.1 Arquitetura de Software . . . . . . . . . . . . . . . . . . . . . . . . 30 2.5.2 Arquitetura Cliente - Servidor . . . . . . . . . . . . . . . . . . . . . 33 2.5.3 Sistemas de Informações Geográficas . . . . . . . . . . . . . . . . . 34 2.5.4 Linguagem de Modelagem Unificada (UML) . . . . . . . . . . . . . 35 2.6 Tecnologias em Desenvolvimento de Software . . . . . . . . . . . . . . . . . 36 2.6.1 Java . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36 2.6.2 Spring Framework . . . . . . . . . . . . . . . . . . . . . . . . . . . 37 2.6.3 Javascript Objects Notation (JSON) . . . . . . . . . . . . . . . . . . 38 3 Oportunidade . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40 4 Proposta . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42 4.1 Escopo e Requisitos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43 4.1.1 Dados quantitativos e qualitativos sobre a pavimentação . . . . . . 44 4.1.2 Coleta de dados durante um trajeto . . . . . . . . . . . . . . . . . . 44 4.1.3 Coleta de dados sobre uma via específica . . . . . . . . . . . . . . . 45 4.1.4 Coleta de dados sobre um defeito específico . . . . . . . . . . . . . . 45 4.1.5 Visualização de dados coletados . . . . . . . . . . . . . . . . . . . . 45 4.1.6 Disponibilização de dados através de serviços Web . . . . . . . . . . 46 4.1.7 Otimização do uso de conexão de dados . . . . . . . . . . . . . . . . 46
  16. 16. 4.1.8 Sistema operacional do smartphone . . . . . . . . . . . . . . . . . . 46 4.1.9 Uso de ferramentas e serviços livres e/ou gratuitos . . . . . . . . . . 47 4.1.10 Restrições . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47 4.2 Especificação . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47 4.2.1 Coletar dados sobre um defeito . . . . . . . . . . . . . . . . . . . . 49 4.2.2 Coletar dados sobre uma via . . . . . . . . . . . . . . . . . . . . . . 50 4.2.3 Coletar dados em um trajeto . . . . . . . . . . . . . . . . . . . . . . 51 4.2.4 Transmitir dados . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52 4.2.5 Visualizar dados . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52 4.2.6 Visualizar dados não transmitidos . . . . . . . . . . . . . . . . . . . 53 4.2.7 Consultar dados . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54 4.2.8 Armazenar dados . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55 4.3 Arquitetura . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55 4.3.1 Aplicação Cliente . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56 4.3.1.1 Interfaces para o Usuário . . . . . . . . . . . . . . . . . . 57 4.3.1.2 Visão estrutural . . . . . . . . . . . . . . . . . . . . . . . 58 4.3.1.3 Visão dos dados . . . . . . . . . . . . . . . . . . . . . . . 62 4.3.1.4 Visão de tempo de execução . . . . . . . . . . . . . . . . . 65 4.3.2 Aplicação Servidor . . . . . . . . . . . . . . . . . . . . . . . . . . . 68 4.3.2.1 Visão estrutural . . . . . . . . . . . . . . . . . . . . . . . 68 4.3.2.2 Interfaces . . . . . . . . . . . . . . . . . . . . . . . . . . . 71 4.3.2.3 Visão dos dados . . . . . . . . . . . . . . . . . . . . . . . 71 4.3.2.4 Visão de tempo de execução . . . . . . . . . . . . . . . . . 72 4.4 Testes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73 4.4.1 Coleta de avaliação de uma via . . . . . . . . . . . . . . . . . . . . 74 4.4.2 Coleta de avaliação de um defeito específico . . . . . . . . . . . . . 75 4.4.3 Coleta de dados em um trajeto . . . . . . . . . . . . . . . . . . . . 77 5 Considerações Finais . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84 5.1 Resultados e Conclusões . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84 5.2 Sugestões para Trabalhos Futuros . . . . . . . . . . . . . . . . . . . . . . . 85 5.3 Trabalhos Relacionados . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85 Referências . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87 Apêndices 90 APÊNDICE A Documento GeoJSON: Exemplo de Coleta de Dados Sobre uma Via . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91
  17. 17. APÊNDICE B Documento GeoJSON: Exemplo de Coleta de Dados Sobre um Defeito . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92 APÊNDICE C Documento GeoJSON: Exemplo de Coleta de Dados Sobre a Superfície de uma Via . . . . . . . . . . . . . . . . . . . . . . . 93
  18. 18. 17 1 Introdução A infraestrutura das cidades, na forma de serviços e equipamentos, colabora com o funcionamento e execução das diversas atividades sociais e econômicas que movimentam as vidas de seus moradores. É uma peça fundamental na garantia da qualidade de vida dos cidadãos e qualquer problema relacionado tem impacto direto na sociedade. As vias públicas da cidade são parte desta infraestrutura e colaboram na sua lo- gística proporcionando a conexão terrestre entre bairros, vilas, casas e outras cidades. Possibilitam a circulação adequada dos diversos meios de transporte como: públicos, de carga, coletivos, individuais etc. Observando-se sua extensão em uma grande capital bra- sileira, como São Paulo, é possível ter uma ideia de sua representatividade e influência no dia-a-dia dos cidadãos, segundo dados da Prefeitura de São Paulo (2004) estima-se a exis- tência de mais de 17 mil quilômetros de vias públicas por onde, segundo o Departamento de Trânsito de São Paulo (2013), circulam diariamente mais de 7 milhões de veículos. Causim (2001 apud PREUSSLER, 1995, p. 53) exemplifica os impactos da manutenção tardia e da mudança da qualidade do pavimento da via do conceito bom para o mau: au- mento de até 58% no consumo de combustível; aumento de até 38% no custo operacional dos veículos; aumento de até 100% no tempo de percurso; aumento de até 50% no índice de acidentes. Portanto desenvolver formas de monitorar e melhorar a qualidade da pavimenta- ção das vias públicas é um fator importante para aliviar o impacto de seu desate na vida dos cidadãos. Uma das formas propostas para sistematizar essa atividade é o uso do SGP (Sistema de Gestão de Pavimentos), que, segundo Causim (2001), tem por objetivo garan- tir o nível de conforto, segurança e economia dos pavimentos já construídos otimizando o uso de recursos disponíveis e organizando o processo de manutenção. Causim (2001 apud HAAS; HUDSON; ZANIEWSKI, 1994), Shahin (1994) e a norma brasileira DNIT (2011) documentam que uma parte relevante do processo de SGP consiste na coleta contínua de informações sobre as vias e condição de seus pavimentos, é com base nestes dados que todo o processo decisório esta baseado. No entanto, a pesquisa de Lima, Ramos e Junior (2006) mostra que, em cidades médias brasileiras, 60% das prefeituras faz avaliações somente quando necessário e menos de 50% trabalha com algum método específico de seleção de ruas para manutenção. Sendo assim, a proposta deste projeto é a criação de uma ferramenta de software que auxilie a coleta contínua da avaliação subjetiva dos usuários e informações quantita- tivas sobre a qualidade das vias por onde trafegam diariamente, disponibilizando-as em uma base de dados aberta que possa ser aproveitada pela sociedade como parte do critério
  19. 19. 18 de avaliação no planejamento da manutenção e evolução da malha viária das cidades. Entende-se que o crescente interesse da população por smartphones, segundo o IDC (2013) espera-se que sejam embarcados para o mercado brasileiro mais de 28 milhões de unidades em 2013, pode prover as ferramentas necessárias para coleta de informações já que estes dispositivos possuem variados recursos de hardware e software, como acelerô- metros e conexão com a Internet. Outro fator que argumenta a favor da criação de tal ferramenta é o surgimento e o crescimento da participação da população em iniciativas que aproveitam o engajamento social eletrônico para exercitar a cidadania, ferramentas como o My Fun City (2012), Fix My Street Brasil (2013), Colab (2013) e Waze (2006) tem se destacado por disponibilizar funcionalidades e serviços que permitem aos usuá- rios publicar sua opinião sobre o que está acontecendo em suas cidades, o impacto destes acontecimentos em suas vidas e até mesmo utilizar essas informações para melhorar a qualidade dos serviços prestados pelos governos de sua cidade e consequentemente de suas vidas. Portanto, o escopo deste projeto compreende a engenharia e desenvolvimento de uma PoC (Proof of Concept) para um sistema baseado em arquitetura cliente-servidor onde: uma aplicação Android será utilizada pelos usuários para coletar informações dos acelerômetros e GPS (Global Positioning System) do smartphone e as enviar a um ser- vidor, que por sua vez será responsável por armazenar os dados brutos dos sensores e disponibilizá-los através de serviços web. Espera-se que com a utilização da prova de conceito seja possível validar a possibilidade de aplicação do conceito de sensoriamento participativo à este tipo de problema e efetuar uma análise inicial dos dados obtidos durante os testes e experimentos. O presente trabalho está estruturado da seguinte forma: no Capítulo 1 é feita a contextualização do problema e o entendimento da relevância da proposta na melhoria da pavimentação viária; os conceitos teóricos sobre a gestão da pavimentação viária, tec- nologias em mobilidade e sensoriamento participativo são apresentados no Capítulo 2; o detalhamento da oportunidade de melhoria na coleta de informações sobre a pavimen- tação viária é feita no Capítulo 3; no Capítulo 4 é apresentada a proposta, projeto e os testes realizados com a prova de conceito desenvolvida; finalmente no Capítulo 5 são documentadas as conclusões e sugestões para trabalhos futuros.
  20. 20. 19 2 Estado da Arte 2.1 Sistemas de Gerenciamento de Pavimentos (SGP) A pavimentação viária representa um recurso valioso para sociedade, sua preserva- ção é essencial para garantir custos operacionais adequados a usuários e administradores. A interrupção ou diminuição dos serviços de manutenção desta infraestrutura resultam no aumento dos custos de utilização e exigem investimentos maiores para sua recuperação (DNIT, 2011). Becker (2012 apud HAAS; HUDSON; ZANIEWSKI, 1994) apresenta o SGP como um conjunto de atividades coordenadas para o planejamento, projeto, construção, manu- tenção, avaliação e pesquisa de pavimentos. Seu objetivo principal é determinar a siste- mática que possibilite o retorno máximo sobre o investimento dos recursos aplicados para a construção e manutenção de pavimentos a partir de uma base de informações confiáveis sobre o estado da malha viária. A implementação de um SGP pode ser estruturada de maneiras diferentes, é apre- sentada na Figura 1 a estrutura e as atividades para um SGP conforme Causim (2001 apud HAAS; HUDSON; ZANIEWSKI, 1994, p.26), já Shahin (1994) propõe uma organização na forma de processos e fases como representado na Figura 2. Figura 1 – Estrutura de um Sistema de Gerência de Pavimentos Fonte: Causim (2001 apud HAAS; HUDSON; ZANIEWSKI, 1994, p.26)
  21. 21. 20 Figura 2 – Processo para um Sistema de Gerência de Pavimentos Fonte: Shahin (1994, p. 340) No Brasil, o Departamento Nacional de Infraestrutura em Transportes (DNIT) é responsável pela normatização das atividades relacionadas a pavimentação. Na norma DNIT (2011) define-se quatro grandes atividades básicas para este tipo de sistema: 1. Estabelecimento do Sistema de referência; 2. Avaliação dos pavimentos; 3. Determinação das Prioridades; 4. Elaboração de programa plurianual de investimentos. 2.1.1 Avaliação da Condição de Pavimentos Nas estruturas apresentadas é possível observar que a avaliação, coleta e orga- nização de informações sobre a condição das vias é um ponto em comum. Sobre estas
  22. 22. 21 atividades, o DNIT (2011) ressalta sua importância como insumo para o processo deci- sório do sistema, sua execução possibilita determinar as condições funcionais, estruturais e operacionais da malha viária em um determinado momento, além da obtenção e atu- alização de dados que alimentam periodicamente o SGP, possibilitando sua operação de maneira mais eficiente. Uma das funcionalidades mais relevantes de um SGP, segundo Shahin (1994) é sua habilidade de determinar o estado atual e futuro da pavimentação das vias, para garantir a confiabilidade e capacidade do sistema em cumprir esse objetivo é necessário estabelecer um método contínuo de avaliação. Para análise da degradação dos pavimentos e posterior tomada de decisão sobre as ações a serem realizadas, a norma DNIT (2011) esclarece que três fatores devem ser observados: 1. Desempenho funcional: Capacidade do pavimento em exercer sua função principal, que é o fornecimento de uma superfície adequada ao rolamento; 2. Desempenho estrutural: Capacidade do pavimento em manter sua integridade es- trutural durante e após sua utilização; 3. Desempenho operacional e da segurança: Refere-se à aspectos da via que influenciam diretamente sua segurança e utilização pelos usuários, como sinalização, aderência do veículo à via, resistência à derrapagem, comportamento dos motoristas etc. Os defeitos presentes na superfície das vias e como seu estado atual afeta o rola- mento dos veículos estão diretamente relacionados ao desempenho funcional, sua avaliação pode ser feita através do Valor de Serventia Atual (VSA) e do International Roughness Index (Índice de Irregularidade Internacional - IRI). (DNIT, 2011) 2.1.2 Valor de Serventia Atual (VSA) Uma medida subjetiva da superfície do pavimento que mede a capacidade da via proporcionar, na opinião do usuário, rolamento suave e confortável em um momento sob qualquer condição de tráfego. A avaliação é realizada por uma equipe composta de membros especialistas na avaliação deste tipo de infraestrutura. (DNIT, 2003) O processo de avaliação normatizado pela DNIT (2003) estabelece que os avaliado- res devem percorrer as vias utilizando veículos em uma velocidade próxima a velocidade máxima da via; devem ser atribuídas notas a trechos da via, estas notas devem variar entre 0,0 e 5,0 (indicando, respectivamente, pavimentos de péssimo a ótimo); deve-se ter em mente critérios como o quanto o pavimento atende no momento o propósito ao qual foi construído e se o conforto proporcionado é adequado.
  23. 23. 22 Após a coleta das avaliações, o VSA é calculado para cada trecho da via de acordo com a fórmula (2.1) abaixo: 𝑉 𝑆𝐴 = ∑︀ 𝑋 𝑛 (2.1) Onde: ∙ VSA: Valor de Serventia Atual; ∙ X: Avaliação de serventia atual atribuída por cada membro da equipe avaliadora; ∙ n: número de membros do grupo de avaliação. Os cinco níveis de serventia da escala podem ser expressos como na tabela 1. Em geral, após a construção ou reforma da superfície da via o índice VSA é elevado já que esta se apresenta suave e sem irregularidades. (DNIT, 2011) Tabela 1 – Níveis de serventia Padrão de Conforto ao Rolamento Avaliação (faixa de notas) Excelente 4 a 5 Bom 3 a 4 Regular 2 a 3 Ruim 1 a 2 Péssimo 0 a 1 Fonte: DNIT (2003, p. 46) No entanto, o VSA pode diminuir por conta do tráfego e das intempéries. É possível estabelecer dois limites relacionados à degradação da via: de aceitabilidade e trafegabi- lidade. Abaixo do nível de aceitabilidade o conforto proporcionado pela via aos usuários passa a ser inadequado (o limite depende do tipo de via e tráfego, variando de uma VSA de 2 a 2,5). Quando este nível é atingido deve ser feita a manutenção corretiva da via para restaurar sua condição, antes disso apenas a manutenção preventiva periódica é suficiente para manter níveis aceitáveis. Caso não haja manutenção o pavimento pode atingir o limite de trafegabilidade, no qual a circulação de veículos é extremamente prejudicada e torna-se necessária a reconstrução da via. A evolução da curva de serventia é apresentada na Figura 3. (DNIT, 2011)
  24. 24. 23 Figura 3 – Variação da serventia com o tráfego ou com o tempo decorrido de utilização da via Fonte: DNIT (2011, p.47) 2.1.3 Índice Internacional de Rugosidade (International Roughness Index - IRI) O IRI é um índice utilizado para quantificar a quantidade de irregularidades em trechos de uma determinada via. A irregularidade longitudinal refere-se ao somatório dos desvios detectados na superfície de um pavimento em relação a um plano de referência ideal, que impactam em características como qualidade ao rolamento, dinâmica das cargas e a drenagem superficial. Suas faixas de variação são mostradas na Figura 4. (DNIT, 2011) Figura 4 – Diversas faixas de variação do IRI Fonte: DNIT (2011, p.49) As irregularidades afetam diretamente a interação das vias com os veículos, os efeitos são perceptíveis nos passageiros, cargas e nos próprios veículos. A importância em
  25. 25. 24 entender e mensurar as irregularidades está em sua correlação com os custos e qualidade de serviço entregue aos usuários. (DNIT, 2011) No Brasil, o DNIT (2011) recomenda que o levantamento das irregularidades seja feito de acordo com a norma DNER (1994b) que especifica a utilização de sistemas do tipo resposta e também lista a classificação de alguns equipamentos de medição: ∙ Sistemas de medidas diretas de perfil: Método de nível e mira; ∙ Sistemas de medida indireta do perfil: Perfilômetro de superfície GMR, Perfilômetro AASHTO, Perfilômetro CHLOE, Merlin do TRRL; ∙ Sistemas do tipo resposta: Rugosímetro BPR, Bump Integrator, Maysmeter, Inte- grador IPR/USP; ∙ Sistemas de medida com sonda sem contato – Perfilômetro Laser, Perfilômetro Acús- tico da Universidade FELT. O procedimento proposto pela norma DNER (1994b) especifica a realização das medições utilizando um veículo de passeio em conjunto com um instrumento tipo resposta. As leituras devem fornecer os valores absolutos dos deslocamentos verticais do eixo traseiro do veículo em relação à carroceria e devem ser relacionadas às informações de localização do trecho da via onde foi realizada a leitura. O valor final do IRI é calculado através de uma das equações para o coeficiente de irregularidade (QI) conforme especificado na norma DNER (1994a): 𝑄𝐼 = 𝑎 + 𝑏𝐿 (2.2) 𝑄𝐼 = 𝑎 + 𝑏𝐿 + 𝑐𝐿2 (2.3) Onde: ∙ a, b e c: determinados pelo método dos mínimos quadrados; ∙ L: leitura do instrumento de medição. 2.2 Vibração e o Conforto em Veículos O desempenho funcional refere-se a capacidade dos pavimentos em fornecer uma superfície adequada à utilização pelos usuários, sua avaliação é associada a diversos fatores entre eles o conforto resultante da utilização da via. (DNIT, 2011)
  26. 26. 25 As irregularidades presentes nas superfícies das vias são transmitidas aos passa- geiros na forma de vibrações através dos diversos componentes do veículo. (MAIA, 2002) A norma ISO (1997) estabelece diretrizes para a análise de vibrações ao corpo inteiro, principalmente em circunstâncias em que a vibração é transmitida através de uma superfície de sustentação como pés de uma pessoa em pé, nádegas de uma pessoa sentada ou área de sustentação onde se recosta. Esta norma ainda recomenda que a quantidade a ser utilizada para medir a intensidade da vibração é a aceleração, normalmente expressa em metros por segundo ao quadrado. Segundo Franchini (2007 apud SELL, 2002, p. 48), frequência, deslocamento, velo- cidade e aceleração são as principais características físicas na geração de vibrações verticais que podem afetar o corpo humano. Algumas diferentes faixas de vibração e aceleração que tornam as condições inaceitáveis ao corpo humano estão compiladas na tabela 2. Tabela 2 – Condições Inaceitáveis às Vibrações Verticais Frequências inferiores a 2Hz e aceleração de 3g a 4g Frequências entre 4Hz e 14Hz e aceleração entre 1,2g e 3,2g Frequências acima de 14Hz e aceleração entre 5g e 9g Com aceleração de 1,5g a vibração se torna perigosa e insuportável A aceleração mais crítica em relação ao incômodo é de 1g, cerca de 10𝑚/𝑠2 À 2,5𝑚/𝑠2 a incidência de erros é tão grave que as vibrações devem ser consideradas perigosas Com aceleração de 0,5𝑚/𝑠2 no assento, os erros do motorista aumentam significati- vamente De 1Hz a 4Hz, há dificuldade para respirar De 2Hz a 16 Hz, o desempenho do motorista diminui muito e os efeitos pioram com o aumento da aceleração De 4Hz e 8 Hz, há maior sensação de incômodo De 4Hz a 10 Hz começam dores no peito, na barriga, reação na musculatura, resso- nância no maxilar inferior De 8Hz a 12 Hz, dores nas costas De 10Hz a 20 Hz, tensão muscular, dor de cabeça, perturbações visuais, dores na traqueia, perturbações na fala Fonte: Adaptado de Franchini (2007 apud SELL, 2002, p. 48) 2.3 Tecnologias em Mobilidade 2.3.1 Telefones Móveis Inteligentes (Smartphones) Zheng e Ni (2006) define smartphone, ou telefone móvel inteligente, como uma nova classe de aparelhos celulares, dotada de um aumento significativo no poder de pro-
  27. 27. 26 cessamento computacional e facilidades no acesso a dados. Além das tradicionais funcio- nalidades de comunicação por voz e mensagens de texto, esta nova classe de dispositivos oferece uma ampla gama de aplicações como calendários, agendas, calculadoras, jogos, execução e gravação de áudio e vídeo, câmera integrada, mensagens instantâneas, acesso à internet, comércio eletrônico, pagamentos eletrônicos, aplicativos empresariais, serviços baseados em localização entre outras. Com o aumento da capacidade de processamento e da variedade de funcionali- dades disponíveis é possível olhar para o smartphone como o resultado da convergência de diversos dispositivos e fica clara sua importância como agente de inovação nas mais diversas áreas do entretenimento ao meio corporativo, e até mesmo na área acadêmica. Zheng e Ni (2006) 2.3.2 Sistema Operacional Android Segundo a Open Handset Alliance (2013) e o Android Open Source Project (2013), a plataforma Android é um conjunto de softwares composto por sistema operacional, middleware, ferramentas de desenvolvimento (software development kit (SDK)) e algu- mas aplicações chave para dispositivos móveis. Este conjunto pode ser incorporado a uma ampla variedade de dispositivos para possibilitar aos desenvolvedores a criação de apli- cativos capazes de utilizar todo o potencial dos dispositivos nos quais serão embarcados (usualmente tablets e smartphones) e entregar aos usuários uma experiência única. Uma das principais vantagens da plataforma Android é proporcionar um ambiente unificado e aberto para o desenvolvimento de aplicações. O código da plataforma é open- source e todas as funcionalidades do dispositivo podem ser acessadas via API (application programming interfaces). Open Handset Alliance (2013) As principais funcionalidades são encontradas em Google (2013a), abaixo segue uma lista com algumas delas: ∙ funcionalidades de áudio e video; ∙ comunicação via voz e texto; ∙ diversas formas de acesso à dados e internet; ∙ localização e navegação; ∙ gráficos avançados; ∙ internacionalização e localização; ∙ segurança: perfis, desbloqueio biométrico e via senha etc;
  28. 28. 27 ∙ acessibilidade: voz para texto, texto para voz, tamanho de fonte, recursos de resposta etc; ∙ aplicações: agenda, câmera, galeria multimídia, relógio, navegador para internet, teclado na tela, aplicativo para troca de mensagens de texto, notícias e clima etc; ∙ recursos de hardware: acelerômetros, compasso eletrônico, GPS (Global Positioning System), NFC (Near Field Communications), câmera, sensor de proximidade, sensor de luminosidade, sensor de temperatura, sensor de pressão atmosférica, giroscópio etc. 2.3.3 Acelerômetros Sensores de aceleração, ou acelerômetros, são componentes eletro-mecânicos capa- zes de medir a aceleração aplicada ao corpo do sensor, inclusive a aceleração da gravidade. Comumente fornecido em circuitos integrados compostos de três sensores preparados para medir a aceleração em diferentes dimensões. Sua disponibilidade e utilização tem se tor- nado cada vez mais comum em smartphones para proporcionar novas formas de interação e melhorar a usabilidade para o usuário. (SCHERZ, 2013; GOOGLE, 2013c) A documentação em Google (2013c) especifica o funcionamento do acelerômetro na plataforma Android, cujo sensor mede a aceleração aplicada ao dispositivo derivando-a da medição das forças aplicadas ao próprio sensor. Nesta medição está inclusa a aceleração da gravidade, que precisa ser removida para se obter a aceleração real do dispositivo. Conforme apresentado em Google (2013d) o acelerômetro utiliza o sistema de coordenadas padrão para sensores em dispositivos Android representado na Figura 5. Em Google (2013c) descreve-se as seguintes condições com o dispositivo sobre uma mesa em sua orientação natural: ∙ Se o dispositivo for empurrado para a esquerda, a aceleração no eixo x é positiva; ∙ Se o dispositivo for empurrado para cima, a aceleração no eixo y é positiva; ∙ Se o dispositivo for empurrado de encontro ao céu com uma aceleração de 𝐴𝑚/𝑠2 , a aceleração no eixo z será de 𝐴𝑚/𝑠2 + 9, 81, que corresponde a aceleração do dispositivo (+𝐴𝑚/𝑠2 ) subtraída da aceleração da gravidade (−9, 81𝑚/𝑠2 ); ∙ Quando parado, a leitura será de uma aceleração de +9, 81𝑚/𝑠2 correspondente a aceleração do dispositivo (0𝑚/𝑠2 ) subtraída da aceleração da gravidade (−9, 81𝑚/𝑠2 ).
  29. 29. 28 Figura 5 – Sistema de coordenadas relativas ao dispositivo Fonte: Google (2013d) 2.3.4 Sistema de Posicionamento Global O sistema de posicionamento global (do inglês Global Positioning System, ou ainda GPS) é definido pelo National Coordination Office for Space-Based Positioning, Naviga- tion, and Timing (2013) como um utilitário que fornece aos usuários serviços de posicio- namento, navegação e ajuste de tempo. Sua implementação é divida em três segmentos: ∙ Segmento do Espaço: compreende vinte e quatro satélites que orbitam o planeta Terra transmitindo continuamente sinais de rádio contendo informações de posicio- namento e tempo; ∙ Segmento de Controle: conjunto de instalações distribuídas por diversos países que monitoram e controlam as operações dos satélites GPS; ∙ Segmento de Usuário: consiste em um receptor de sinais GPS capaz de captar, interpretar os dados e calcular informações de posicionamento a serem utilizadas por uma aplicação específica. O processo de utilização do sistema GPS inicia com a transmissão das informações de posicionamento e tempo pelos satélites; os sinais de rádio são recebidos e interpretados por um receptor GPS que utiliza os dados para calcular a distância do receptor até o satélite; a partir da distância estimada até pelo menos quatro satélites o receptor uti- liza cálculos de geometria para obter o posicionamento do receptor em relação à Terra. (NATIONAL COORDINATION OFFICE FOR SPACE-BASED POSITIONING, NAVI- GATION, AND TIMING, 2013)
  30. 30. 29 A integração de receptores GPS em dispositivos Android tem se tornado comum. Conhecer o posicionamento do usuário do dispositivo permite o desenvolvimento de apli- cações inteligentes capazes de entregar serviços e informações mais relevantes. As funci- onalidades contidas nas classes do pacote android.location permitem acesso aos serviços de sistema do Android que fornecem a localização do usuário. No entanto, é importante ressaltar que, apesar do GPS ser o método mais preciso em ambientes externos, para esta tarefa o receptor consome mais energia do que outras formas e não é tão rápido quanto desejado pela maioria dos usuários, este problema é abordado na plataforma Android utilizando uma técnica que mescla informações obtidas de diversos meios para estimar a localização do usuário, como o sinal de Wi-Fi e de dados do smartphone. 2.4 Sensoriamento Participativo A evolução das tecnologias móveis, com a criação de dispositivos como os smartpho- nes com amplo acesso a dados e melhorada capacidade de processamento, aliada a sua crescente adoção por grande parte das pessoas começam a possibilitar novas formas de coleta de informações como o sensoriamento participativo (do inglês paticipatory sensing), cuja ideia principal é disponibilizar aos cidadãos ferramentas que os tornem capazes de coletar e compartilhar informações sobre seu meio ambiente utilizando os recursos dispo- níveis em smartphones. (KANHERE, 2011; BURKE et al., 2006) Aplicações que trabalham o conceito de sensoriamento participativo tipicamente adotam o modelo cliente servidor no qual um software instalado no smartphone de um voluntário, ativado manualmente, automaticamente ou através do contexto, coleta os da- dos dos sensores e os envia a uma aplicação em um servidor, que por sua vez efetua o processamento e disponibiliza as informações em formatos que podem variar de acordo com as necessidades dos usuários. (KANHERE, 2011) A versatilidade e variedade de recursos disponíveis nos dispositivos móveis atu- ais possibilitam uma variedade de aplicações que, segundo Kanhere (2011) podem ser divididas em duas categorias: ∙ Aplicações de sensoriamento orientadas às pessoas: utiliza os sensores do dispositivo móvel para obter dados sobre o comportamento do usuário. São alguns exemplos: monitoramento de saúde pessoal, cálculo de impacto ambiental, monitoramento e documentação de experiências esportivas, melhorar o uso de mídias sociais, auditoria de preços. ∙ Aplicações de sensoriamento orientadas ao ambiente: utiliza os sensores do dispo- sitivo móvel, e possivelmente equipamentos adicionais, para obter dados sobre o ambiente onde está o usuário. São alguns exemplos: monitoramento da qualidade
  31. 31. 30 do ar, monitoramento de níveis de ruído, monitoramento de pavimentos e condições de tráfego. Ainda segundo Kanhere (2011), o sensoriamento participativo oferece algumas vantagens sobre redes de sensores distribuídos tradicionais como o uso da infraestrutura já existente de smartphones e redes de dados (WiFi ou celular), o que permite um custo de implementação mais baixo; a grande cobertura das operadoras de celular habilita uma grande penetração no número de dispositivos e na área que pode ser coberta pela aplicação; o uso smartphones como sensores intrinsecamente permite economia de escala; o uso de plataformas móveis já existentes para desenvolvimento e distribuição das aplicações torna o processo de implantação e implementação mais fácil; finalmente, ao incluir os cidadãos ao processo de coleta é possível projetar soluções que realmente colaborem na melhoria do dia a dia das comunidades. 2.5 Tecnologias em Engenharia de Software De acordo com Sommerville (2003), a engenharia de software é uma disciplina que trata de todas as particularidades e atividades relacionadas à produção de software du- rante todo o ciclo de vida do projeto, desde a prospecção e especificação até a manutenção do sistema. Os engenheiros de software trabalham de maneira sistemática e organizada para identificar teorias, métodos e ferramentas que sejam mais adequadas para auxiliar na solução dos problemas dentro das restrições organizacionais e financeiras que lhe são impostas. Esta seção aborda algumas questões relacionadas à engenharia de software que guiam e fundamentam o projeto proposto neste trabalho, principalmente no que diz res- peito a arquitetura de software e modelos de referência utilizados. 2.5.1 Arquitetura de Software A arquitetura de software é uma descrição, constituída de um ou mais modelos, que representa a visão estrutural do sistema possibilitando a identificação, a comunicação e a compreensão dos diversos elementos, além de suas relações e propriedades, que podem fazer parte do software. (SOMMERVILLE, 2003; BASS; CLEMENTS; KAZMAN, 2012) O projeto de arquitetura é o processo pelo qual o sistema é decomposto em subsis- temas e módulos, e as decisões sobre a estrutura, organização e relacionamento entre os diversos elementos identificados são documentados. A arquitetura representa a conexão entre os requisitos de software, as necessidades do negócio, e o sistema a ser construído. (SOMMERVILLE, 2003)
  32. 32. 31 Bass, Clements e Kazman (2012) argumentam que a complexidade presente nos software modernos frequentemente torna muito difícil sua compreensão com uma única visão ou estrutura. O conjunto de todos os elementos de software e hardware que compõem o sistema é chamado de estrutura; já a visão é uma representação de um subconjunto de elementos estruturais organizados coerentemente e representados de forma a garantir a compreensão por todos os envolvidos no projeto. As estruturas podem ser dividas em três tipos: ∙ Estrutura de Módulos: uma representação estática do sistema composta pelas unida- des de implementação (classes, camadas, ou divisões de funcionalidades); é estrutu- rada como um conjunto de códigos ou unidades de dados que devem ser construídos ou contratados. Se dedica a investigar as responsabilidades, dependências e relacio- namentos entre os elementos; ∙ Estruturas Componentes-Conectores: incorpora decisões sobre a estrutura dos ele- mentos que possuem comportamento em tempo de execução. Componentes são ele- mentos que fazem parte da estrutura (serviços, clientes, servidores, filtros etc) e os conectores representam os meios de comunicação entre os elementos (retornos de chamada, meios de sincronização etc). Provê informações sobre o fluxo de dados no sistema, paralelismo, dados compartilhados, interação entre componentes em tempo de execução; ∙ Estruturas de Alocação: representam os relacionamentos do sistema com compo- nentes que não fazem parte do software (como unidades de processamento, sistemas de arquivos, redes, times de desenvolvimento etc). Colabora com informações sobre interações com o ambiente externo como quais times de software irão desenvolver cada componente, em qual unidade de processamento cada componente irá executar etc. Cada estrutura permite analisar e projetar perspectivas diferentes do sistema, no entanto isso não as torna independentes. É importante estabelecer relações entre elementos de diferentes estruturas para entender como essas interações podem afetar o comporta- mento da aplicação em tempo de execução, é possível assim prever problemas e estabelecer estratégias para prevenção. Apesar de colaborar na construção de visões diferentes sobre o software nem todos os projetos justificam a utilização de muitos modelos estruturais, quanto maior o sistema mais complexa e diferente é a relação entre as estruturas, por- tanto, seu projeto e documentação devem ser realizados tendo em vista o retorno sobre investimento proporcionado por estas atividades, geralmente representado em termos de menor tempo de desenvolvimento e menores custos de manutenção. (SOMMERVILLE, 2003; BASS; CLEMENTS; KAZMAN, 2012)
  33. 33. 32 O papel do arquiteto é orientar o projeto da arquitetura do sistema, seu conheci- mento técnico é essencial para colaborar na seleção dos modelos e estruturas mais ade- quados para compreender e documentar o software abrangendo os requisitos e guiando o desenvolvimento. No entanto, as habilidades que o arquiteto deve apresentar vão além da perspectiva técnica, habilidades como comunicação, negociação e conhecimento das regras do negócio são igualmente importantes uma vez que seu envolvimento não está focado somente no desenvolvimento, mas também na interação com clientes e pessoas não-técnicas que possuem grande interesse e influência no projeto. (BASS; CLEMENTS; KAZMAN, 2012) Projetar a arquitetura do sistema ajuda a garantir o cumprimento de seu papel em relação aos objetivos estabelecidos pelo negócio. Do ponto de vista técnico, Bass, Clements e Kazman (2012) enumeram algumas razões para a execução desta atividade: ∙ A arquitetura possibilitará ou não as características de qualidade do sistema; ∙ As decisões tomadas durante o projeto da arquitetura permitirão a reflexão e o gerenciamento das mudanças conforme o sistema evolui; ∙ A análise da arquitetura permite a previsão das qualidades do sistema; ∙ A documentação melhora a comunicação sobre o projeto; ∙ Define as primeiras, que são as mais fundamentais e difíceis decisões de projeto; ∙ Define as restrições sobre as implementações subsequentes; ∙ Dita a estrutura da organização, ou vice-versa; ∙ Pode prover os fundamentos para prototipação evolucionária; ∙ Permite ao arquiteto e ao gerente de projetos refletir sobre custo e cronograma; ∙ Pode se tornar o núcleo de uma linha de produtos na forma de um modelo transfe- rível e reutilizável; ∙ Foca a atenção do desenvolvimento na montagem dos componentes e não somente na construção; ∙ Restringe alternativas de projeto, canalizando esforços e reduzindo a complexidade do sistema e do projeto; ∙ Pode ser a fundação para o treinamento de um novo membro da equipe.
  34. 34. 33 2.5.2 Arquitetura Cliente - Servidor Segundo Sommerville (2003), Bass, Clements e Kazman (2012), este é um modelo de sistema distribuído em que os dados e o processamento estão em diversos processadores. Composto por um grande número de clientes que desejam acessar recursos e serviços compartilhados, que por sua vez são geridos por um ou mais servidores e acessados através de uma rede. A ideia principal é extrair serviços comuns e centralizá-los em um local, ou um pequeno número de locais. Desta forma é possível melhorar a escalabilidade e a disponibi- lidade através da gestão centralizada dos recursos e sua distribuição através de múltiplos servidores físicos. Os componentes podem ainda ser organizados em camadas de funcio- nalidades relacionadas. (BASS; CLEMENTS; KAZMAN, 2012) Algumas desvantagens que devem ser consideradas ao adotar este tipo de modelo como a centralização dos recursos que pode transformar o servidor em um gargalo de performance ou em um ponto único de falha; a separação de funcionalidades entre cliente e servidor que pode se tornar complexa e sua mudança pode ter um alto custo após a implementação. (BASS; CLEMENTS; KAZMAN, 2012) A adoção do modelo cliente-servidor pode ser considerada nas seguintes situações: aplicações com centenas ou milhares de clientes; aplicações e dados altamente voláteis; integração de dados de múltiplas fontes. São exemplos do uso de arquitetura cliente- servidor aplicações web onde o browser é o cliente e o servidor são componentes de um site de comércio eletrônico; sistemas de informação em redes locais cujos clientes são aplicações com interfaces gráficas para o usuário e o servidor são sistemas de gerenciamento de banco de dados; sistemas bancários nos quais os clientes são os caixas eletrônicos e os servidores são os componentes que fornecem os serviços financeiros. (SOMMERVILLE, 2003; BASS; CLEMENTS; KAZMAN, 2012) Um exemplo de arquitetura cliente servidor para um sistema bancário de caixas eletrônicos pode ser visto na Figura 6.
  35. 35. 34 Figura 6 – Arquitetura cliente servidor para um sistema bancário de caixas eletrônicos Fonte: Bass, Clements e Kazman (2012) 2.5.3 Sistemas de Informações Geográficas As novas tecnologias permitiram diversos avanços nas formas como nos comunica- mos, analisamos e tomamos decisões sobre nossos entornos. Informações sobre o mundo real podem ser coletadas, processadas e apresentadas de maneira simplificada para cumprir necessidades específicas. Tomar decisões sobre nosso meio ambiente requer informações sobre locais específicos na superfície da Terra. Informações geográficas são assim chama- das pois ajudam a distinguir um local do outro e possibilitam tomar ações específicas de acordo com as condições de cada local, são portanto essenciais ao planejamento e processo de decisão efetivos na sociedade moderna. (BERNHARDSEN, 2002) Sistemas de informações geográficas (do inglês Geographic Information Systems - GIS) são compostos de hardwares e softwares capazes de manipular informações geográfi- cas para criar produtos derivados de mapas e ligar diversos elementos relacionados a esses dados. Todos os dados inseridos em um GIS são geo-referenciados, ou seja, estão atrelados a um local específico na superfície da Terra através de um sistema de coordenadas, dos quais o mais comum é o composto por latitude e longitude. (BERNHARDSEN, 2002) Diversas qualidades e características podem ser relacionadas a localidades, estes atributos podem ser parâmetros físicos, como elevação da terra e temperatura, ou classifi- cações como dados de proprietários, zoneamento etc. Em alguns casos estas propriedades são atreladas a pontos, mas é possível estabelecer um relacionamento mais complexo com linhas ou áreas, exemplos comuns são o mapeamento de lagos, cidades, ruas e rios. (BERNHARDSEN, 2002)
  36. 36. 35 Uma visão geral da abrangência de sistemas de informações geográficas é apresen- tada na Figura 7. Figura 7 – GIS: Abrangência Fonte: Bernhardsen (2002) A capacidade do GIS de armazenar, processar e apresentar informações sobre o relacionamento entre características, atributos e locais são algumas de suas funcionali- dades mais poderosas. Frequentemente dados são processados e sobrepostos na forma de mapas, tabelas ou formatos especiais que fornecem informações vitais sobre localidades geográficas. (BERNHARDSEN, 2002) Bernhardsen (2002) lista algumas aplicações de sistemas de informações geográfi- cas: visualização e produção de mapas; análise de dados para otimização de sistemas de transporte; sistema de informações sobre propriedades; sistema de gerenciamento de dis- tribuição de encanamentos e cabeamentos; sistemas de planejamento de rodovias; sistemas de navegação em terra e mar. 2.5.4 Linguagem de Modelagem Unificada (UML) Segundo Booch, Rumbaugh e Jacobson (2005), existem limites para a capacidade humana em compreender complexidades, sendo assim criamos modelos como uma forma de simplificar a realidade e compreender melhor o sistema que está sendo desenvolvido.
  37. 37. 36 A UML (Unified Modeling Language) é uma linguagem padrão de modelagem cri- ada para visualizar, especificar, construir e documentar artefatos de um sistema complexo de software. Esta ferramenta provê um conjunto de estruturas que permite a descrição de características conceituais como processos de negócio, requisitos e casos de uso; e itens concretos como estruturas de classes, módulos e componentes a serem implantados. Não está entre os objetivos da UML especificar quais estruturas criar e quando criar, papel este que deve ser cumprido pelo processo de desenvolvimento de software o que torna esta uma linguagem flexível que pode ser utilizada com quaisquer tipos de processos. (BOOCH; RUMBAUGH; JACOBSON, 2005) De acordo com Booch, Rumbaugh e Jacobson (2005), são definidos basicamente três tipos de blocos de construção: ∙ Itens: elementos básicos que permitem a criação de modelos de abstração unitários, podem ser estruturais, comportamentais, de agrupamento ou anotacionais; ∙ Relacionamentos: componentes que permitem definir o significado da relação entre os diversos itens, podem definir dependências, associações, generalizações ou reali- zações; ∙ Diagramas: uma representação gráfica de um conjunto de itens e relacionamentos que permite a visualização de perspectivas diferentes do projeto do sistema. São ao todo treze diagramas: de classes, de objetos, de componentes, de estrutura com- posta, de casos de uso, de sequência, de comunicação, de estado, de atividades, de implantação, de pacotes, de temporização, de visão geral de interação. 2.6 Tecnologias em Desenvolvimento de Software O desenvolvimento de software consiste na transformação das especificações do projeto em um sistema funcional. Esta etapa envolve a programação dos componentes de software por um desenvolvedor que traduz todas as diretrizes presentes no projeto em instruções compreensíveis ao computador, a utilização de ferramentas e frameworks auxiliares tornam o trabalho deste profissional mais rápido, produtivo e criativo. (SOM- MERVILLE, 2003) Esta seção trata das linguagens e frameworks que apoiam o desenvolvimento dos componentes de software que fazem parte da solução proposta neste projeto. 2.6.1 Java Linguagem de programação criada em meados dos anos 90 pela empresa Sun Mi- crosystems (adquirida pela Oracle em 2009), originalmente chamava-se Oak e foi criada
  38. 38. 37 por Patrick Naughton, Mike Sheridan, e James Gosling. Se enquadra no paradigma de linguagens orientadas à objetos, é independente de plataforma, sua estrutura sintática e semântica foram adaptadas de outra linguagem a C++. (REESE, 2012) Na época de seu lançamento, Java foi bastante inovador por prover funcionalidades com alta qualidade e facilidade de uso diretamente no framework da linguagem como thre- ading, comunicação por redes e segurança. Uma de suas características mais interessantes é a utilização de uma linguagem de máquina para uma arquitetura própria (chamada de bytecode Java) que é interpretada e executada pela Java Virtual Machine (JVM), essa decisão de projeto teve como objetivo tornar as aplicações desenvolvidas em Java inde- pendentes de plataforma, sendo que somente a implementação da máquina virtual varia dependendo da arquitetura. (REESE, 2012) A evolução da linguagem e de suas ferramentas de desenvolvimento permitiram a criação de diferentes tipos de aplicação e contribuíram para sua utilização em diversas áreas. Reese (2012) apresenta uma lista dos tipos de aplicação que podem ser desenvolvidas em Java: ∙ Aplicações desktop para console e com interfaces gráficas; ∙ Aplicações web baseadas em servidores e suportadas por Servlets, Java Server Pages Java Server Faces e outros padrões da Java Enterprise Edition (JEE); ∙ Applets que executam dentro do browser; ∙ Aplicações embarcadas; ∙ Componentes reutilizáveis com JavaBeans. 2.6.2 Spring Framework Um modelo de programação e configuração, além de um framework de ferramentas, para o desenvolvimento de aplicações Java Enterprise. Sua principal característica é seu suporte estrutural para a construção da aplicação, seu foco é fornecer funcionalidades de apoio de alta qualidade para que os times de desenvolvimento possam se preocupar somente com a implementação das regras de negócio. Spring possui suporte a implantação em diversos tipos de plataforma, possui projeto modular e pode ser adotado de maneira incremental ou através da adoção de componentes individuais. (GOPIVOTAL INC., 2013) Em GoPivotal Inc. (2013) é possível encontrar algumas de suas características: ∙ Sistema de injeção de dependência flexível com configuração via XML (eXtensible Markup Language) ou anotações;
  39. 39. 38 ∙ Suporte avançado a programação orientada a aspectos; ∙ Suporte à transações declarativas, caching declarativo, validação declarativa e for- matação declarativa; ∙ Abstrações para utilizar frameworks JEE como Java Database Conector, Java Per- sistence API, Java Transactions API e Java Messaging Services; ∙ Suporte a frameworks de código aberto como Hibernate e Quartz; ∙ Framework web flexível para a criação de aplicações e serviços baseados em RESTful MVC (Representational State Tranfer Model-View-Controller); ∙ Facilidades e ferramentas para o desenvolvimento de testes unitários e de integração. 2.6.3 Javascript Objects Notation (JSON) JSON é um formato leve de troca de dados, sua estrutura foi baseada em um subconjunto da linguagem de programação JavaScript especificada pelo padrão ECMA (2011). Seu formato é facilmente manipulável por seres humanos e máquinas, é baseado em texto e completamente independente de linguagem de programação, apesar de utilizar convenções parecidas com as presentes em linguagens da família C. (INTRODUCING. . . , 2013) Segundo a definição em Introducing. . . (2013), o formato é baseado em duas es- truturas: coleções de pares de nome e valor; e listas ordenadas de valores. Estas estruturas são definidas da seguinte forma: ∙ Objetos: conjunto desordenado de pares nome e valor. Iniciado com abertura de chaves e finalizado com fechamento de chaves, nomes e valores são separados por dois pontos e os pares separados por vírgulas; ∙ Arrays: coleção ordenada de valores. Iniciado com abertura de colchetes e finalizado com fechamento de colchetes, valores são separados por vírgulas; ∙ Valores: podem ser texto entre aspas duplas, um número, true, false, null, um objeto ou array. ∙ String: sequência de zero ou mais caracteres Unicode; ∙ Número: Representação numérica em formato decimal (octal e hexadecimal não são utilizados); ∙ Espaços em branco: podem ser inseridos em qualquer ponto da notação, geralmente utilizados para melhorar a legibilidade.
  40. 40. 39 Uma extensão ao JSON relevante para este trabalho é o Geospacial JSON. Segundo sua especificação em Butler et al. (2008), este é um formato de troca de dados geoespaciais que permite em seu formato a adição de estruturas de dados geográficos como pontos, linhas, polígonos, coleções geométricas, e ainda propriedades que servem para enriquecer o nível de informações sobre os dados geográficos.
  41. 41. 40 3 Oportunidade Nos capítulos 1 e 2 foram apresentados os conceitos relacionados a gestão da pa- vimentação viária e como a qualidade da superfície das vias pode impactar significativa- mente o dia-a-dia e a saúde dos cidadãos. As técnicas de gerenciamento de pavimentos e o estudo do conforto em veículos auxiliam a compreensão dos efeitos do desgaste das vias sobre os veículos e seus passageiros, além de propor sistemáticas para que os gestores desta infraestrutura possam planejar e atuar no momento mais adequado para prevenir que o estado destas vias atinja um nível crítico e prejudicial. Os métodos documentados por Causim (2001 apud HAAS; HUDSON; ZANI- EWSKI, 1994), Shahin (1994) e a norma brasileira DNIT (2011) determinam que a coleta contínua de informações sobre a condição atual da pavimentação viária é um procedimento importante para garantir que o SGP possua dados atualizados. Desta forma, torna-se possível estimar a qualidade de um determinado trecho de pavimento, planejar sua ma- nutenção, otimizar o uso de recursos públicos e mitigar os efeitos causados pela aparição de defeitos em sua superfície. Apesar da importância da atividade de coleta, a pesquisa de Lima, Ramos e Junior (2006) aponta que, em cidades médias brasileiras, 60% das prefeituras avalia as condições da pavimentação somente quando há solicitação da população; 60% destas cidades utiliza algum SGP e, no entanto, apenas 12% realiza a atualização dos levantamentos de campo e avaliação dos pavimentos; menos da metade das prefeituras utiliza um método formal específico para selecionar vias para a manutenção, sendo que apenas 20% delas utiliza a análise da condição da pavimentação para este fim. São diversas as dificuldades enfrentadas pela gestão pública para manter uma base de informações atualizada sobre as vias sob sua gestão, ainda no trabalho de Lima, Ramos e Junior (2006) conclui-se que a falta de recursos e a ausência de uma política formal para gestão do sistema viário contribuem para o desperdício de recursos técnicos e financeiros. Lima, Ramos e Junior (2006) ainda complementam que, apesar dos avanços tecnológicos, na maioria das cidades brasileiras não são aplicados procedimentos específicos para avaliar a necessidade de manutenção e restauração dos pavimentos; na maioria dos casos os órgãos públicos municipais desconhecem a real condição dos pavimentos atuando reativamente na solução de problemas; e finalmente, os recursos técnicos especializados são escassos e utilizados com pouco, ou nenhum planejamento, geralmente para suprir necessidades extremas de reparo. Portanto a baixa taxa de uso da análise do estado da pavimentação viária, ali- ada a sua relevância e restrições de recursos, no auxílio a efetiva gestão da condição e
  42. 42. 41 manutenção da capacidade funcional das vias públicas, abre espaço para o desenvolvi- mento de uma solução que tenha como foco uma abordagem diferente das existentes, no entanto complementar, que colabore na coleta de dados e por consequência na melhoria do processo de gestão de pavimentos.
  43. 43. 42 4 Proposta O processo para coleta de informações sobre o estado atual da pavimentação viária está intimamente relacionado com o destino dos dados obtidos, e, como visto em capítulos anteriores, à partir deles podem ser derivados indicadores que representem a capacidade da via em exercer sua função. No Brasil as normas (DNIT, 2003) e DNER (1994b), que descrevem os indicadores VSA e IRI apresentados no capítulo 2, detalham que os procedimentos de coleta de dados devem ser executados por equipes especializadas com equipamentos preparados e calibrados especificamente para este fim. As restrições de recursos humanos e financeiros destacados por Lima, Ramos e Junior (2006) tornam-se uma barreira às medições utilizando recursos especializados, uma vez que se torna cada vez mais difícil disponibilizá-los e desenvolvê-los em quantidade suficiente para abranger adequadamente, e com maior frequência, a quantidade de vias nas cidades. A proposta do presente trabalho utiliza os conceitos de sensoriamento participativo no desenvolvimento de uma aplicação orientada ao ambiente para possibilitar a participa- ção de pessoas não especialistas no processo de coleta. Com o aumento de participantes nesta atividade pode-se aumentar a abrangência geográfica e a frequência das medições, otimizando portanto o uso de recursos especializados reservando-os a momentos e locais onde são mais necessários. O conceito de sensoriamento participativo orientado ao ambiente foi escolhido pois possibilita a simplificação dos equipamentos de medição com a sugestão do uso de uma aplicação para um smartphone, pertencente a um usuário voluntário, capaz de utilizar os recursos disponíveis neste dispositivo para monitorar informações relevantes do ambiente e enviá-las a um servidor para serem processadas posteriormente; além de motivar o cidadão comum a participar voluntariamente do processo de coleta, aumentando não somente o volume e frequência dos dados mas também sua relevância em relação ao dia-a-dia dos usuários da infraestrutura viária. Uma visão de alto nível da solução proposta está representada na Figura 8, na qual o procedimento de coleta está divido em três etapas: 1. Coleta de informações é o cumprimento das atividades de recolhimento de dados pelos usuários voluntários. Pode ocorrer basicamente de duas formas: a) Em um veículo, a solução pode ser ativada para obter dados quantitativos atra- vés do registro da aceleração causada pelas imperfeições da via sobre o veículo e
  44. 44. 43 transmitidas aos sensores do smartphone. Além disso, podem ser obtidos dados qualitativos, como a opinião do usuário sobre o trajeto percorrido; b) A pé, a solução pode ser utilizada para recolher dados qualitativos como a opinião do usuário sobre a via observada e imagens de irregularidades e buracos; 2. Transmissão de dados, na qual é realizada o envio das informações à próxima etapa utilizando os recursos de conectividade disponíveis no smartphone; 3. Processamento e Armazenamento, que consiste no recebimento e persistência dos dados para posterior disponibilização a outros serviços. Figura 8 – Proposta: Visão geral Nas próximas seções serão detalhadas as funcionalidades e a arquitetura utilizadas como referência para a construção da solução. 4.1 Escopo e Requisitos Compreende projeto e desenvolvimento do protótipo de uma solução de sensoria- mento participativo orientada ao ambiente composta de duas aplicações: ∙ Aplicação cliente para smartphone: utilizada pelos usuários para coletar as informa- ções sobre a pavimentação e enviá-las a um servidor; ∙ Aplicação servidor: responsável pelo recebimento, armazenamento e posterior dis- ponibilização dos dados coletados.
  45. 45. 44 Para atingir o objetivo proposto a solução deverá realizar os requisitos abaixo detalhados. 4.1.1 Dados quantitativos e qualitativos sobre a pavimentação O objetivo principal da solução é coletar informações que possam ser utilizadas na análise da condição do pavimento. Portanto é necessário definir a natureza dos dados a serem coletados de maneira a guiar os requisitos funcionais que definem quando e como a coleta será realizada. Os dados qualitativos a serem coletados são: ∙ Opinião do usuário em relação a qualidade da pavimentação do percurso realizado, possibilitando a atribuição de uma nota que deverá variar de 0 (péssimo) à 5 (exce- lente). Essa informação permite a criação de indicadores como o VSA (apresentado no capítulo 2); ∙ Fotografias do estado atual do pavimento ou de um defeito específico, para posterior análise por um especialista em uma possível priorização de manutenção. Já os dados quantitativos são extraídos da leitura da aceleração dos eixos X, Y e Z obtidos do acelerômetro do dispositivo, em 𝑚/𝑠2 , durante um trajeto percorrido pelo veículo do usuário. Estes dados são a informação bruta que pode ser utilizada na derivação de indicadores como o IRI e índices de conforto (apresentados no capítulo 2); Deve-se atentar também para os dados que permitem a contextualização e a loca- lização das informações sobre o pavimento no tempo e espaço: ∙ Posicionamento informados pelo módulo de GPS do dispositivo expressos em lati- tude e longitude; ∙ Dados temporais expressos em milissegundos à partir de 1 de Janeiro de 1970 00:00:00.0 UTC, para fácil conversão. Essas definições devem ser utilizadas como referência em todo o projeto. 4.1.2 Coleta de dados durante um trajeto Deverá ser possível ao usuário efetuar a coleta de dados durante um percurso com seu veículo. Para isso o smartphone deverá ser posicionado sobre o painel do veículo com a face voltada para cima, o usuário poderá então acionar um comando na aplicação para iniciar a coleta de dados antes de começar seu trajeto, e ao final do percurso o usuário deverá acionar um comando para interromper a coleta, armazenar e enviar os dados.
  46. 46. 45 Os dados a serem coletados são as leituras de aceleração durante todo o trajeto; dados de posicionamento durante o trajeto, basicamente as variações de latitude e longi- tude que ocorreram durante a movimentação; a opinião do usuário em relação a qualidade da pavimentação do percurso realizado; e, dados temporais. A coleta destas informações permite sua correlação e contextualização através da criação de uma camada de dados que pode ser sobreposta a mapas que permitam a análise de dados de regiões específicas, conforme proposto por sistemas de informações geográficas. Por fim, a opinião do usuário serve como informação qualitativa que provê a perspectiva e expectativa do usuário em relação à via durante o trajeto. 4.1.3 Coleta de dados sobre uma via específica Deverá ser possível ao usuário informar sua opinião sobre a qualidade da pavi- mentação de uma via específica. Ao ser selecionada esta opção o sistema deverá exibir a localização atual do usuário e permitir que ele avalie a condição do pavimento. Serão armazenadas as informações de posicionamento no momento da coleta, opinião do usuário em relação a qualidade da pavimentação no local da coleta e dados temporais. Entende-se que a manutenção ou restauração de uma via que tem mais avaliações negativas por um número maior de usuários terá um impacto positivo muito maior. Dessa forma, coletar a opinião do usuário possibilita estimar o impacto do estado atual da via para usuário final, pretende-se desta forma disponibilizar mais uma ferramenta que auxilie o processo de escolha de vias para manutenção. 4.1.4 Coleta de dados sobre um defeito específico Deverá ser possível ao usuário registrar informações sobre um defeito específico encontrado em uma via. Ao utilizar esta opção o sistema deverá exibir a localização atual do usuário, permitir que seja obtida uma fotografia e a avaliação qualitativa do defeito. As informações armazenadas são os dados de posicionamento no momento da coleta, opinião do usuário em relação ao defeito em questão e dados temporais. O registro de defeitos específicos permite a identificação de problemas de critici- dade mais alta que possam necessitar de atenção imediata, além de possibilitar a análise do problema por um especialista sem seu deslocamento até o local. 4.1.5 Visualização de dados coletados O sistema deverá disponibilizar uma interface para o usuário visualizar as infor- mações que já foram coletadas. Os dados deverão ser sobrepostos a um mapa da região onde o usuário se encontra no momento. Cada tipo de informação poderá ser visualizada de maneira diferente:
  47. 47. 46 ∙ Defeitos específicos terão suas localizações apontadas no mapa por marcadores que ao serem selecionados exibirão todos as informações referentes ao defeito; ∙ As avaliações qualitativas enviadas pelos usuários serão utilizadas para determinar o índice VSA dos trechos de vias e sua representação gráfica deverá ser colorida de acordo com o resultado: verde (Excelente), azul (Bom), amarelo (Regular), rosa (Ruim) e vermelho (Péssimo); ∙ Os dados de aceleração coletados não deverão ser exibidos nesta interface pois exi- gem um pós-processamento mais complexo para se derivar indicadores que sejam mais relevantes aos usuários. O principal objetivo deste requisito é propiciar transparência aos usuários sobre as condições atuais das vias de sua localidade. As mesmas informações disponibilizadas aos administradores estará visível aos cidadãos que colaboraram no processo de coleta, possibilitando uma participação mais efetiva da população no processo de gestão das vias. 4.1.6 Disponibilização de dados através de serviços Web Todos os dados coletados deverão ser disponibilizados através de serviços abertos que deverão receber como parâmetro um endereço ou intervalo de coordenadas geográficas (latitude e longitude inicial, e latitude e longitude final), o tipo de informação que deseja- se obter (dados de aceleração, defeitos ou opiniões dos usuários) e um período de tempo (data inicial e data final). A resposta da solicitação deverá conter todas as informações coletadas que atendam aos parâmetros informados, deve-se considerar que quando um parâmetro for informado em branco todas as informações relativas ao mesmo deverão ser retornadas. 4.1.7 Otimização do uso de conexão de dados É comum que, quando ao ar livre ou nas ruas, os usuários de smartphones estejam conectados a redes de dados disponibilizadas pelas operadoras de celular que limitam a velocidade e a quantidade de informação que podem ser utilizadas de acordo com o serviço contratado pelo usuário. Esse tipo de dispositivo normalmente possui mais de um tipo de conexão, é importante portanto que a aplicação transmita as informações aos servidores somente quando um tipo de conexão mais adequada (como o Wi-Fi) estiver disponível de maneira a preservar os recursos contratados pelo usuário. 4.1.8 Sistema operacional do smartphone A aplicação cliente deverá ser desenvolvida para o sistema operacional Android devido a sua grande presença no mercado de smartphones, disponibilidade de dispositivos
  48. 48. 47 em diversas faixas de preços e grande número de funcionalidades. Essas características garantem uma grande abrangência geográfica e a disponibilidade dos recursos tecnológicos necessários à aplicação. 4.1.9 Uso de ferramentas e serviços livres e/ou gratuitos De maneira a otimizar os recursos financeiros na construção do protótipo deve-se selecionar apenas ferramentas e serviços que sejam livres ou que possuam versões sem custo. 4.1.10 Restrições Durante o processo de análise de requisitos foram identificadas algumas restrições que não poderão ser tratadas no decorrer deste trabalho devido as restrições de tempo e escopo: ∙ Orientação do dispositivo: os dados de aceleração são coletados de todos os eixos, mudanças de orientação podem causar um desalinhamento entre planos de coor- denadas do dispositivo e do veículo. Seria necessário desenvolver e aplicar técnicas para responder adequadamente a essas mudanças. ∙ Precisão dos dados coletados: é importante ressaltar que a precisão dos sensores disponíveis é sensivelmente inferior a de equipamentos especiais calibrados em la- boratório o que pode causar discrepâncias nos dados coletados. ∙ Coleta em diferentes tipos de veículos: podem causar distorções uma vez que cada tipo de veículo possui componentes e estrutura diferentes, se faz necessário desen- volver e aplicar métodos que permitam lidar com essas diferenças. ∙ Não serão abordadas neste projeto aplicações que façam a análise dos dados coleta- dos, esta possibilidade pode ser exploradas em trabalhos posteriores. 4.2 Especificação Os requisitos de software são apresentados de uma maneira mais abstrata, em uma linguagem mais próxima e compreensível aos usuários. A especificação aprimora os requisitos enriquecendo o nível de detalhes e os aproxima do projeto da arquitetura e da implementação. Neste ponto é importante criar modelos que descrevam o que o sistema deverá fazer e não como fazê-lo. (SOMMERVILLE, 2003) Para a criação da especificação foi selecionado o modelo de casos de uso, que apre- senta descrições de conjuntos de ações e interações entre o sistema e seus usuários que,
  49. 49. 48 quando executados, produzem algo de valor ao usuário final. Nesta forma de representa- ção, os papéis desempenhados pelos usuários são apresentados na forma de atores e são entidades externas ao sistema; já o caso de uso descreve todos os passos e atividades rea- lizadas durante a interação entre sistema e ator. (BOOCH; RUMBAUGH; JACOBSON, 2005) Sendo assim, na Figura 9 é apresentado o diagrama de casos de uso para a solução proposta, e na sequência estão descritos os detalhes de cada um dos itens do diagrama. Figura 9 – Diagrama de casos de uso
  50. 50. 49 4.2.1 Coletar dados sobre um defeito Descrição: Permite aos atores registrar dados qualitativos sobre um defeito de pavimentação específico que se queira relatar. Atores: Pedestre, Motorista Pré-Condições: ∙ O sistema de GPS do dispositivo deve estar ativo. ∙ Uma conexão de dados deve estar ativa. ∙ O dispositivo deve possuir câmera. Resultados: Os dados coletados devem estar registrados na base de dados e disponíveis para consulta. Descrição do processo: 1. O ator ativa a opção de registrar dados sobre um defeito. 2. O sistema obtém a localização do ator e a informa ao ator. 3. O sistema obtém as informações temporais da coleta. 4. O sistema solicita a entrada de uma fotografia e a avaliação. 5. O ator captura uma fotografia do defeito. 6. O ator seleciona uma nota entre 1 e 5 para avaliação. 7. O ator confirma a coleta. 8. O sistema executa o caso de uso Transmitir dados e informa o resultado ao ator. Exceções, erros e situações especiais: ∙ O ator poderá cancelar a operação a qualquer momento. ∙ Antes da confirmação do envio o ator poderá alterar sua avaliação e fotografia captura a qualquer momento. ∙ Se não for possível obter localização, o sistema informa o usuário e encerra o caso de uso sem efetuar a coleta. ∙ Caso o dispositivo não possua câmera, o sistema informa o usuário e encerra o caso de uso sem efetuar a coleta. ∙ Se a conexão de dados estiver indisponível, o sistema informa o usuário e ar- mazena as informações localmente para envio posterior.
  51. 51. 50 4.2.2 Coletar dados sobre uma via Descrição: Permite a avaliação qualitativa espontânea de uma via por qualquer ator do sistema. Atores: Pedestre, Motorista Pré-Condições: ∙ O sistema de GPS do dispositivo deve estar ativo. ∙ Uma conexão de dados deve estar ativa. Resultados: Os dados coletados devem estar registrados na base de dados e disponíveis para consulta. Descrição do processo: 1. O ator ativa a opção de avaliar uma via. 2. O sistema obtém a localização do ator e a informa ao ator. 3. O sistema obtém as informações temporais da coleta. 4. O sistema solicita a entrada da avaliação. 5. O ator seleciona uma nota entre 1 e 5 para avaliação. 6. O ator confirma a coleta. 7. O sistema executa o caso de uso Transmitir dados e informa o resultado ao ator. Exceções, erros e situações especiais: ∙ O ator poderá cancelar a operação a qualquer momento. ∙ Antes da confirmação do envio o ator poderá alterar sua avaliação a qualquer momento. ∙ Se não for possível obter localização, o sistema informa o usuário e encerra o caso de uso sem efetuar a coleta. ∙ Se a conexão de dados estiver indisponível, o sistema informa o usuário e ar- mazena as informações localmente para envio posterior.
  52. 52. 51 4.2.3 Coletar dados em um trajeto Descrição: Viabiliza a coleta de dados quantitativos sobre a superfície da pavimentação da via, além da avaliação qualitativa do usuário sobre o trajeto. Atores: Motorista Pré-Condições: ∙ O sistema de GPS do dispositivo deve estar ativo. ∙ Uma conexão de dados deve estar ativa. ∙ O dispositivo deve estar posicionado com a tela para cima sobre o console do veículo. Resultados: Os dados coletados devem estar registrados na base de dados e disponíveis para consulta. Descrição do processo: 1. O ator solicita ao sistema que inicie a coleta. 2. Enquanto o ator não solicita o fim da coleta. a) O sistema obtém uma atualização da posição. b) O sistema informa ao ator o trajeto percorrido até o momento. c) O sistema coleta as informações de aceleração dos eixo X, Y e Z do dispo- sitivo. d) O sistema obtém as informações temporais. e) O sistema registra localmente todas as informações coletadas até o mo- mento. 3. Ator solicita o fim da coleta. 4. O sistema solicita a avaliação do trajeto. 5. O ator seleciona uma nota entre 1 e 5 para avaliação. 6. O ator confirma a coleta. 7. O sistema executa o caso de uso Transmitir dados e informa o resultado ao ator. Exceções, erros e situações especiais: ∙ O ator poderá encerrar a operação a qualquer momento.
  53. 53. 52 ∙ Se não for possível obter localização, o sistema informa o usuário e encerra o caso de uso sem efetuar a coleta. ∙ Se a conexão de dados estiver indisponível, o sistema informa o usuário e ar- mazena as informações localmente para envio posterior. 4.2.4 Transmitir dados Descrição: Envia os dados informados ao servidor. Atores: Outros casos de uso. Pré-Condições: ∙ Uma conexão de dados deve estar ativa. Resultados: Os dados transmitidos devem ser recebidos e persistidos pela aplicação servidor. Descrição do processo: 1. Monta a mensagem para envio ao servidor com as informações recebidas. 2. A aplicação cliente efetua uma chamada ao serviço de armazenagem da apli- cação servidor informando a mensagem montada no passo 1. 3. A aplicação servidor executa o caso de uso Armazenar dados e informa o re- sultado a aplicação cliente. 4. O caso de uso encerra com o envio do código de retorno (falha ou sucesso) ao caso de uso ator. Exceções, erros e situações especiais: ∙ Se a conexão de dados estiver indisponível, o sistema informa o usuário e ar- mazena as informações localmente para envio posterior. ∙ Se houver perda de conexão durante a transmissão o caso de uso é encerrado com erro. ∙ Se o serviço estiver indisponível o caso de uso é encerrado com erro. 4.2.5 Visualizar dados Descrição: Permite ao ator consultar os dados já coletados e submetidos ao sistema.
  54. 54. 53 Atores: Pedestre, Motorista Pré-Condições: ∙ Uma conexão de dados deve estar ativa. Resultados: Os dados devem ser exibidos ao ator. Descrição do processo: 1. O ator solicita a visualização dos dados. 2. A aplicação cliente obtém a localização do ator e a informa ao ator. 3. A aplicação cliente solicita os dados já cadastrados à aplicação servidor pas- sando como parâmetro a localização do ator. 4. A aplicação servidor executa o caso de uso Consultar dados e informa o resul- tado à aplicação cliente. 5. A aplicação cliente disponibiliza os dados ao ator. Exceções, erros e situações especiais: ∙ Se a conexão de dados estiver indisponível o sistema informa o ator e o caso de uso é encerrado com erro. ∙ Se houver perda de conexão durante a transmissão o sistema informa o ator e o caso de uso é encerrado com erro. ∙ Se o serviço estiver indisponível o sistema informa o ator e o caso de uso é encerrado com erro. 4.2.6 Visualizar dados não transmitidos Descrição: Possibilita ao ator a consulta e re-transmissão de dados que por motivos de conec- tividade não puderam ser enviados à aplicação servidor antes. Atores: Pedestre, Motorista Pré-Condições: ∙ Uma conexão de dados deve estar ativa. Resultados:
  55. 55. 54 ∙ Exibição ao ator de uma lista com os dados coletados que ainda não foram transmitidos. ∙ Em caso de re-transmissão os dados, estes devem estar registrados na base de dados e disponíveis para consulta. Descrição do processo: 1. O ator solicita a visualização de dados não transmitidos. 2. O sistema lista todas as coletas realizadas e não enviadas ao servidor em uma lista. 3. Se o ator desejar re-enviar os dados: a) O ator seleciona um ou mais itens que deseja reenviar. b) O sistema recarrega os dados selecionados. c) O sistema executa o caso de uso Transmitir dados e informa o resultado ao ator. Exceções, erros e situações especiais: ∙ O ator poderá encerrar a operação a qualquer momento. ∙ Se a conexão de dados estiver indisponível, o sistema informa o usuário e man- tém as informações localmente para envio posterior. 4.2.7 Consultar dados Descrição: Fornece um serviço de consulta às informações já coletas pelos usuários. Atores: Aplicação Cliente, Sistemas de Gerenciamento de Pavimentos (SGP) Pré-Condições: 1. Deve haver conexão com a internet. 2. Deve haver dados cadastrados na base de dados. Resultados: Os dados solicitados são retornados de acordo com os parâmetros informados. Descrição do processo: 1. O ator solicita dados informando uma localização (latitude e longitude) e um raio (em metros). 2. O sistema consulta a base de dados com os parâmetros informados.
  56. 56. 55 3. O sistema cria uma mensagem de retorno com os dados selecionados. 4. A mensagem de retorno é enviada ao ator. Exceções, erros e situações especiais: ∙ Se não houver dados é retornada uma mensagem vazia. ∙ Em caso de perda de conexão a resposta a ser enviada é descartada. ∙ Em caso de parâmetros inválidos é retornada uma mensagem vazia. 4.2.8 Armazenar dados Descrição: Fornece um serviço para armazenamento de informações já coletas pelas instâncias das aplicações cliente. Atores: Aplicação Cliente Pré-Condições: Deve haver conexão com a internet. Resultados: Os dados enviados são persistidos na base de dados. Descrição do processo: 1. O ator envia uma mensagem contendo as informações coletadas. 2. O sistema cria um documento com base na mensagem recebida. 3. O sistema armazena o documento na base de dados. 4. É enviado um código de sucesso ao ator. Exceções, erros e situações especiais: ∙ Se a mensagem recebida estiver vazia é retornado sucesso. ∙ Em caso de perda de conexão a resposta a ser enviada é descartada. ∙ Em caso de mensagem recebida inválida é retornado um código de erro. 4.3 Arquitetura Conforme visto no capítulo 2, a arquitetura de software tem papel importante na criação do vínculo entre a especificação funcional e as tecnologias a serem utilizadas na implementação do sistema. Nesta etapa serão criados diversos modelos que representam
  57. 57. 56 visões diferentes da solução a ser desenvolvida, possibilitando a decomposição e organiza- ção do sistema em módulos, a análise de aspectos dinâmicos e estruturais e o cumprimento dos requisitos e casos de uso especificados na etapa anterior. Para esta solução será adotada uma arquitetura cliente servidor, conforme sugerido por Kanhere (2011), uma vez que para cumprir o objetivo proposto é necessário utilizar uma aplicação para coletar as informações e outra para centralizar e servir os dados coletados. A estrutura cliente servidor adotada neste projeto está descrita no diagrama de implantação representado na Figura 10 abaixo: Figura 10 – Diagrama de implantação A solução será composta por dois artefatos principais: a aplicação cliente Bura- queira.apk e a aplicação servidor BuraqueiraServer.war, e ainda um terceiro artefato que representa o repositório onde os dados coletados serão armazenados. Nas seções seguintes a estrutura interna e os papéis de cada um destes componentes serão detalhados. 4.3.1 Aplicação Cliente Batizada de Buraqueira, a aplicação cliente tem como principal objetivo fornecer aos usuários as funcionalidades relacionadas à coleta de dados. Para tanto neste artefato deverão ser implementados os casos de uso: Coletar dados sobre um defeito, Coletar dados em um trajeto, Coletar dados sobre uma via, Transmitir dados e Visualizar dados não transmitidos. Para a implementação desta aplicação será utilizada a linguagem de programação
  58. 58. 57 Java em conjunto com as APIs da plataforma Android, além de alguns outros componen- tes selecionados para acelerar o processo de desenvolvimento. 4.3.1.1 Interfaces para o Usuário As interfaces para os usuários são responsáveis por fornecer formas de interação que permitam ao usuário usufruir das funcionalidades da aplicação e do dispositivo em uso. Para a prova de conceito proposta foi idealizado um conjunto de interfaces que permitam que o usuário execute com poucos toques as atividades de coleta de informações. Na Figura 11 esta representado o fluxo de navegação através das interfaces da aplicação cliente.
  59. 59. 58 Figura 11 – Fluxo de interação com as interfaces para os usuários da aplicação cliente 4.3.1.2 Visão estrutural Para melhor organizar e compreender os diversos elementos da aplicação Bura- queira é apresentado o diagrama de componentes na Figura 12. Nele apresenta-se uma visão de alto nível da aplicação na qual estão representadas suas dependências com outros componentes, os serviços externos necessários a suas funcionalidades e sua organização interna em pacotes.
  60. 60. 59 Figura 12 – Diagrama de componentes da aplicação Buraqueira Os componentes externos foram escolhidos para acelerar o desenvolvimento adici- onando funcionalidades essenciais: ∙ GSON: provê a funcionalidade de conversão de objetos Java em notação JSON e vice versa; ∙ Spring Android REST e Core: facilitam a comunicação com a aplicação servidor provendo formas de utilização simplificadas de chamadas a métodos HTTP que permitem a transmissão dos dados coletados ao servidor; ∙ Google Play Services: contém diversas funcionalidades relacionadas aos serviços do Google. Para a aplicação Buraqueira serão utilizas as funções de geolocalização do serviço Google Mapas; ∙ Android Framework: com foco na plataforma Android, a aplicação deve ser cons- truída de acordo com seus padrões, utilizando os controles e componentes disponibi- lizados por sua API. As principais funcionalidades a serem acessadas são: construção de interfaces para os usuários, acesso a sensores, acesso ao sistema de arquivos, com- ponentes que permitem multitarefa e controle de permissões.
  61. 61. 60 No diagrama também especifica-se a necessidade de algumas interfaces externas. Neste caso as interfaces definem funções que serão implementadas e providas pela aplica- ção servidor. Espera-se que estas funcionalidades atendam às seguintes especificações: ∙ streetRatingHTTPPost: invocação de um método HTTP post no endereço streetRating onde no corpo da mensagem HTTP será enviado um documento JSON no formato GeoJSON contendo informações sobre a avaliação feita pelo usuário sobre uma via específica. ∙ streetDefectRatingHTTPPost: invocação de um método HTTP post no endereço streetDefectRating onde no corpo da mensagem HTTP será enviado um documento JSON no formato GeoJSON contendo informações sobre a avaliação feita pelo usuá- rio sobre um defeito encontrado em uma via. ∙ streetSurfaceDataHTTPPost: invocação de um método HTTP post no endereço streetSurfaceData onde no corpo da mensagem HTTP será enviado um documento JSON no formato GeoJSON contendo dados coletados pela aplicação durante o trajeto realizado pelo usuário. O detalhamento sobre os dados e formatos utilizados é feito na seção 4.3.1.3. Nesta visão de componentes também optou-se por detalhar a organização interna do artefato Buraqueira.apk representando os pacotes e componentes implementados para a aplicação: ∙ buraqueira: pacote raiz contendo o ponto de entrada da aplicação. ∙ view: contém as implementações dos comportamentos das interfaces gráficas para os usuários. ∙ utils: classes utilitárias. ∙ domain: implementações das classes que lidam com representações de dados rela- cionados ao domínio da aplicação, como as avaliações coletadas dos usuários. Uma característica importante é a utilização de um pacote interno para organização das classes utilizadas na representação destas informações em formato GeoJSON. ∙ data: contém os serviços responsáveis pela coleta e transmissão de dados relevantes para a aplicação como localização e aceleração do dispositivo. Na Figura 13 está representada uma visão estrutural mais detalhada dos principais componentes internos da aplicação Buraqueira.
  62. 62. 61 Figura 13 – Diagrama de classes da aplicação Buraqueira De maneira geral as aplicações Android são centradas nas interações com usuários, o tipo mais comum de componente é a Activity, ou atividade, na qual são implementadas uma atividade unitária que pode ser realizada pelo usuário. No modelo estrutural acima optou-se por utilizar uma atividade, a MainActivity como maneira de direcionar o usuário para as ações que podem ser realizadas, este componente assume papel de ponto de en- trada da aplicação o que o torna um bom candidato para inicializar os serviços executados em segundo plano, nele ainda permite-se ao usuário iniciar a coleta de dados de acelera- ção durante um trajeto. Outros componentes utilizados no controle da interface gráfica são: CollectedDataToTransmitActivity responsável pela interface de listagem e re-envio ao servidor de dados coletados, armazenados localmente e que ainda não foram trans- mitidos ao servidor; DefectCollectionActivity controla a interface que permite ao usuário coletar informações sobre um defeito específico na via; StreetRatingDialog disponibiliza uma interface para classificação da via onde o usuário se encontra no momento. Outro tipo de componente relevante na construção de aplicações em plataformas Android é o Service, ou serviço, que permite a implementação de funcionalidades utilitárias que são executadas em segundo plano. Este elemento da plataforma Android é utilizado na aplicação Buraqueira para criar classes ativas que, uma vez iniciadas, controlam seu
  63. 63. 62 próprio fluxo de execução e possuem suas próprias Threads. Estes serviços são utilizados para coleta, processamento e transmissão dos dados da aplicação. Algumas das razões para o uso deste tipo de estrutura são: garantia da responsividade da interface gráfica para o usuário, reduzir ao mínimo possível a perda de dados informados pelos sensores e melhorar o aproveitamento da capacidade de processamento do dispositivo. 4.3.1.3 Visão dos dados A aplicação Buraqueira lida com a coleta de dados e informações relevantes para a solução, conforme definido anteriormente. Nesta seção será detalhada a modelagem destes dados para utilização na aplicação cliente. O diagrama Figura 14 possui uma representação da modelagem dos principais elementos. Figura 14 – Diagrama de classes dos elementos de dados da aplicação Buraqueira Com a utilização do formato GeoJSON para troca de informações entre a aplicação cliente e servidor, optou-se por adotar um componente externo para efetuar a conversão de objetos Java em notação JSON e vice versa. O processo, conhecido como marshalling e unmarshalling, é feito utilizando o componente GSON. Para garantir a correta geração dos dados em notação GeoJSON foi necessária a utilização de classes adicionais com variáveis de classe que correspondessem ao formato de saída desejado. As classes adicionais foram organizadas no pacote domain/gson e estão representadas no diagrama da Figura 15.
  64. 64. 63 Figura 15 – Diagrama de classes dos elementos GeoJSON Identificou-se a necessidade de três documentos GeoJSON para atender aos requi- sitos desta solução: Avaliação de Vias específicas Objeto em notação GeoJSON do tipo Feature utilizando um elemento Geometry do tipo Point para armazenar o local onde foi feita a coleta da informação associado à nota informada pelo usuário no campo userRating. A notação completa é definida como abaixo: 1 { 2 " type " : " Feature " , 3 " geometry " : { 4 " type " : " Point " , 5 " coordinates " : [ ’ longitude ’ , ’ l a t i t u d e ’ ] 6 } , 7 " pr op ert ie s " : { 8 " userRating " : ’ nota ’ , 9 " timestamp " : ’ timestamp ’ , 10 " dataType " : " street_rating " 11 } 12 }

×