Bike-UFF: Um sistema de compartilhamento para o transporte verde

(1)

Universidade Federal Fluminense

Instituto de Computa¸

c˜

ao

Departamento de Ciˆ

encia da Computa¸

c˜

ao

Bike-UFF

Um sistema de compartilhamento para o transporte verde

Jorge da Silva Junior

Victor da Silva Rempto

Niter´

oi-RJ

2017

(2)

ii JORGE DA SILVA JUNIOR

VICTOR REMPTO

Bike-UFF

Um sistema de compartilhamento para o transporte verde

Trabalho submetido ao Curso de Bacharelado em Ciência da Computa¸cão na Universidade Federal Fluminense como requisito parcial para a obten¸cão do t´ıtulo de Bacharel em Ciência da Computa¸cão.

Orientador: Prof. Eugene F. Vinod Rebello

Niter´oi-RJ 2017

(3)

Ficha Catalográfica elaborada pela Biblioteca da Escola de Engenharia e Instituto de Computação da UFF

S586 Silva Junior, Jorge da

Bike-UFF: um sistema de compartilhamento para o transporte verde / Jorge da Silva Junior, Victor Rempto. – Niterói, RJ : [s.n.], 2017.

55 f.

Projeto Final (Bacharelado em Ciência da Computação) – Universidade Federal Fluminense, 2017.

Orientador: Eugene F. Vinod Rebello.

1. Aplicativo móvel. 2. Mobilidade urbana. 3. Transporte urbano. I. Rempto, Victor. II. Título.

(4)

JORGE DA SII」VA JUNIOR

VICTOR DA SIINA REMPTO

Bike-UFF

Um sis七ema de compartilhamen七o para o transporte verde

Trabalho submetido ao Curso de Bacharelado em Ci合ncia da Computapao

na Universidade Ftderal Fluminense como

requisito parcial para a obtenc肴o do titulo

de Bacharel em Ci合ncia da Computac各o.

四囲

Aprovado por:

Prof. Eugene F. Vinod Rebe11o, Ph.D. - Orientador

- 生霊梁島豊s。

- ,偽繁粂曲B。。r。S, Ph。

UFF

Niter6i-RJ

(5)

v

“Em algum lugar, alguma coisa incr´ıvel est´a esperando para ser descoberta”. (Carl Sagan)

(6)

vi

Agradecimentos

Agradecemos aos nossos familiares e amigos pelo suporte em todas as horas, a todos os professores que fizeram parte da nossa forma¸c˜ao e ao professor Eugene Francis Vinod Rebello, pela orienta¸c˜ao, apoio e confian¸ca.

(7)

vii

Resumo

“Computadores s˜ao como bicicletas para nossas mentes” Steve Jobs.

A mobilidade urbana vem se tornando uma questão cada vez mais importante no planeja-mento das cidades. O cresciplaneja-mento de cidades vem sendo acompanhado com um auplaneja-mento de custos em termos de trânsito, engarrafamentos e polui¸cão. Por isso, encontrar solu¸cões viáveis que aperfei¸coem deslocamentos de forma sustentável se tornou um tema de prim´ a-ria importância para governantes nos últimos anos. Os modais de transporte tradicionais tem se mostrado particularmente ineficazes para deslocamentos curtos, se tornando um problema financeiro para a popula¸cão de menor poder aquisitivo e de log´ıstica para o Estado, responsável pela gestão do sistema.

Este projeto tem como objetivo apresentar um sistema piloto cuja finalidade é de melhorar a mobilidade do corpo discente de universidades em campi grandes ou que tem aulas em campi diferentes numa cidade, como é o caso de muitos alunos da Universidade Federal Fluminense, por meio de um modal de transporte de compartilhamento de bici-cletas. Supondo a disponibilidade de bicicletas ou convênio, como no caso de Bike Rio da Prefeitura do Rio de Janeiro com o banco Itaú, neste projeto também será discutido tecnologias de suporte e uma implementa¸cão para questões de autentica¸cão, seguran¸ca e controle de usuários, dentre as quais foi adotado a plataforma Arduino e identifica¸cão por radiofrequência.

Palavras-chave: Mobilidade urbana, Transporte urbano, Aluguel de bicicletas, Arduino, Web, Dispositivos M´oveis.

(8)

viii

Abstract

“Computers are like a bicycle for our minds” Steve Jobs.

Urban mobility has become an increasingly important issue in city planning. The rapid growth of cities has been followed by increasing costs in terms of travel times, traffic jams and pollution. Thus finding practical solutions that optimize travel in a sustainable way has become a key issue for politicians in recent years. Traditional modes of transport have proved to be particularly ineffective for short commutes, creating a disproportio-nate financial burden for the lower-income population, and a logistics nightmare for the organizations responsible for the management of the transportation system.

This project aims to present a pilot system whose purpose is to improve the mobility of the students at universities located within a large campus, or those with classes at different campi within a city, as is the case for many students at the Fluminense Federal University, through a bicycle loan scheme. The project will also discusses technologies to support the implementation of authentication, security and user control mechanisms, including the use of the Arduino platform and radio frequency identification.

Keywords: Urban Mobility, Urban transportation, Bicycle hire, Arduino, Web, Mobile Devices.

(9)

Sum´

ario

Resumo vii

Abstract viii

Lista de Figuras xi

Lista de Tabelas xii

1 Introdu¸cão 1 1.1 Descri¸cão do problema . . . 2 1.2 Motiva¸cão e Objetivo . . . 2 1.3 Organiza¸cão da monografia . . . 3 2 Trabalhos Relacionados 4 2.1 Bike Rio . . . 4 2.2 Citi Bike . . . 6 2.3 Resumo do cap´ıtulo . . . 6 3 Arquitetura proposta 8 3.1 Estudo de caso . . . 8 3.1.1 A Institui¸cão de Ensino . . . 8 3.1.2 Situa¸cão atual . . . 9 3.2 Solu¸cão Proposta . . . 10 3.3 Arquitetura do Sistema . . . 11 3.4 Requisitos do Sistema . . . 13 3.4.1 Requisitos Funcionais . . . 15 3.4.2 Requisitos Não Funcionais . . . 18 ix

(10)

x 3.5 Resumo do cap´ıtulo . . . 19 4 Tecnologias Relevantes 20 4.1 Arduino . . . 20 4.2 NFC . . . 21 4.3 REST . . . 22 4.4 RFID . . . 23 4.5 Resumo do cap´ıtulo . . . 23 5 Implementa¸cão 24 5.1 Banco de dados . . . 24 5.2 Módulo Arduino . . . 26 5.2.1 Arduino Mega . . . 26 5.2.2 Teclado Matricial 4x4 . . . 27 5.2.3 LCD 16x2 I2C . . . 29 5.2.4 Módulo RFID . . . 30 5.2.5 esp8266 . . . 31 5.3 Interfaces Web . . . 33 5.3.1 Interface Aluno . . . 33 5.3.2 Interface Administrativa . . . 34

5.4 An´alise de requisitos atendidos . . . 35

6 Conclus˜ao 37

Gloss´ario 39

Siglas 40

(11)

xi

Lista de Figuras

2.1 Tela inicial do aplicativo BikeRio . . . 5

2.2 Tela inicial do aplicativo Citi Bike . . . 7

3.1 Modelo de esta¸c˜ao para retirada de bicicletas proposto . . . 11

3.2 Casos de uso do m´odulo Arduino . . . 13

3.3 Casos de uso da aplica¸c˜ao WEB . . . 14

5.1 Modelo Entidade Relacionamento do Banco de Dados . . . 25

5.2 Prot´otipo do m´odulo Arduino . . . 27

5.3 Diferen¸ca na quantidade de portas entre Arduinos UNO e MEGA . . . 27

5.4 Schema do teclado matricial . . . 28

5.5 LCD 16x2 . . . 30

5.6 M´odulo RFID . . . 30

5.7 Esquema do m´odulo esp8266 . . . 32

5.8 Home Page . . . 33

5.9 Mapa com bicicletas dispon´ıveis . . . 34

5.10 Tela para relatar problemas com as bicicletas . . . 35

5.11 Tela com o Hist´orico de um aluno. . . 36

(12)

xii

Lista de Tabelas

5.1 Pinos do Teclado Matricial. . . 28

5.2 Pinagem do LCD . . . 29

5.3 Pinagem do RFID . . . 31

5.4 Pinagem do m´odulo Wifi . . . 32

(13)

Cap´ıtulo 1

Introdu¸

c˜

ao

“ A pol´ıtica de mobilidade urbana tem, deste modo, objeto mais amplo que os servi¸cos de transportes urbanos: trata-se, na verdade, da rela¸cão dos deslo-camentos de pessoas e bens com a própria cidade e de seu planejamento para o desenvolvimento de suas fun¸cões sociais, proporcionando o acesso universal dos cidadãos às oportunidades que a vida na urbe oferece.” (IPEA, 2008)

A mobilidade urbana está ligada ao estado do deslocamento de uma popula¸cão no espa¸co geográfico da cidade, analisando a garantia à livre circula¸cão de pessoas entre diferentes áreas. O termo normalmente é empregado em rela¸cão ao trânsito de ve´ıculos e pessoas no meio urbano.

´

Areas urbanas são localidades que possuem altas concentra¸cões de atividades econˆ o-micas, além disso, são complexas estruturas espaciais apoiadas por sistemas de transporte. Quanto maior a cidade, maior a complexidade e o potencial para desvios, particularmente quando tal complexidade não é devidamente gerenciada.

No Brasil, foi adotado a partir da década de 1950 o sistema rodoviário como o principal modelo de transporte. A prevalência deste modal teve como objetivo incenti-var a entrada da indústria automobil´ıstica no pa´ıs, entretanto, quando foi adotada tal pol´ıtica, a popula¸cão encontrava-se em sua maior parte nas regiões interioranas, situa¸cão que se alterou rapidamente nas décadas a seguir, chegando ao seu ponto de inversão na década de 1970. Esta urbaniza¸cão levou consigo um aumento no número de carros nas vias, entretanto, não foi acompanhada por investimentos de infraestrutura necessários, acarretando a deteriora¸cão das estradas, assim como dos servi¸cos públicos de transporte.

(14)

2 A Universidade Federal Fluminense, sediada em Niterói, possui diversos Campi espalhados pela cidade, para realizar deslocamentos de um campus a outro, os alunos fazem uso de ônibus, carros e bicicletas particulares ou andam por distâncias que podem chegar a 3 quilômetros.

1.1 Descri¸

c˜

ao do problema

Como apresentado na se¸c˜ao anterior, muitos alunos da UFF sofrem do problema da mo-bilidade entre diferentes campi durante o per´ıodo letivo. O tempo gasto em translados `

a pé pode se tornar um fator prejudicial ao bom aproveitamento das disciplinas cursa-das, outras op¸cões como o linhas de ônibus municipais ou o BusUFF podem se tornar respectivamente onerosos em demasia, do ponto de financeiro, e superlotados.

Os alunos se encontram com limitadas op¸cões: Deslocarem-se à pé entre campi, correndo o risco de perder seus compromissos; utilizar do transporte coletivo, o qual pode não estar dentro das possibilidades financeiras do aluno ou se encontrar superlotado, impedindo a entrada do mesmo; ou para aqueles alunos os que possuam, fazer uso de um carro ou de uma bicicleta próprias. Surge da´ı a necessidade de se pensar em um novo modo de transporte público.

A cidade de Niterói possui uma cultura forte para o uso de bicicletas. Desde o ano de 2014, incentivos para a cria¸cão de novas ciclofaixas foram disponibilizados pela prefeitura, entretanto, a cidade de Niterói possui uma malha cicloviária subutilizada, a qual seria capaz de comportar um aumento grande de ciclistas.

1.2 Motiva¸

c˜

ao e Objetivo

Como já descrito na se¸cão anterior, as observa¸cões feitas revelaram um sistema de trans-porte público não condizente com as necessidades dos estudantes, verifica-se também um potencial não explorado para o uso da malha cicloviária urbana da cidade.

A aplica¸cão BikeUFF tem como objetivo ser a plataforma de um Sistema de bi-cicletas públicas para alunos da Universidade Federal Fluminense. Promovendo o acesso rápido e gratuito dos estudantes a bicicletas por um servi¸co de empréstimo, utilizando a carteira da UFF para valida¸cão. O software conta também com um site para que os estu-dantes tenham acesso a informa¸cões das localidades dos bicicletários e sobre a quantidade

(15)

3 de bicicletas dispon´ıveis.

1.3 Organiza¸

c˜

ao da monografia

Esta monografia está dividida em 6 cap´ıtulos e organizada da maneira descrita a seguir: O Cap´ıtulo 2 traz informa¸cões sobre trabalhos relacionados ao presente projeto. O Cap´ıtulo 3 mostra a arquitetura proposta para o presente projeto. O Cap´ıtulo 4 tem como objetivo apresentar as tecnologias relevantes. O Cap´ıtulo 5 contém informa¸cões sobre a implemen-ta¸cão do projeto-piloto. E, finalmente, no Cap´ıtulo 6, são apresentadas as conclusões do trabalho e sugestões para trabalhos futuros.

(16)

Cap´ıtulo 2

Trabalhos Relacionados

Este cap´ıtulo busca oferecer uma visão de trabalhos relacionadas ao tema deste projeto, visando dar uma base para compara¸cões com as proposi¸cões que foram colocadas ao longo deste trabalho. Com o objetivo de organizar as compara¸cões, o cap´ıtulo as divide em cinco se¸cões. As duas primeiras citam sistemas que englobam o mesmo tema desta monografia, a terceira apresenta uma compara¸cão com o projeto apresentado nesta monografia e a ´

ultima oferece uma revis˜ao do cap´ıtulo.

2.1 Bike Rio

“Bike Rio é um projeto de sustentabilidade da Prefeitura do Rio de Janeiro executado através de Termo de Concessão de Uso da Serttel em parceria com o banco Itaú e o sistema de bicicletas SAMBA.” [Mobilicidade, 2017].

O Bike Rio foi desenvolvido pela empresa Serttel como iniciativa da Prefeitura do Rio de Janeiro com apoio do banco Itaú. O sistema possui esta¸cões inteligentes espa-lhadas pela cidade que são conectadas via rede wireless à central de opera¸cões. Usuários cadastrados podem retirar e devolver bicicletas entre as diferentes esta¸cões

(17)

5

Figura 2.1: Tela inicial do aplicativo BikeRio

Os usuários se cadastram pelo aplicativo móvel, informando número de telefone e CPF e em seguida escolhem um plano de pagamentos. Para retirar a bicicleta devem ligar para o número da central de opera¸cões, digitar o número da esta¸cão que se encontram e o número da posi¸cão da bicicleta escolhida. Para realizar uma devolu¸cão o usuário deve apenas encaixar a bicicleta em uma posi¸cão, em qualquer esta¸cão.

Pontos positivos do sistema:

• Informa a quantidade de bicicletas dispon´ıveis por esta¸c˜ao em um mapa via aplica-tivo ;

(18)

6 • A retirada não exige do usuário cadastrado uma conexão com a internet ;

Pontos negativos do sistema:

• Caso o usu´ario que deseja se cadastrar n˜ao possua smartphone, ele deve se cadastrar previamente em um computador, o que prejudica a celeridade do processo;

• o usu´ario necessita de um telefone para liberar uma bicicleta para retirada;

2.2 Citi Bike

O Citi Bike foi desenvolvido pela empresa Motivate como iniciativa da Prefeitura de Nova Iorque com apoio do banco Citibank. Um modelo parecido tem sido adotado em in´umeras cidades ao redor do mundo, por exemplo, em Londres, Paris, etc.

Os usuários se cadastram pelo aplicativo móvel e escolhem um plano de paga-mentos. Para retirada o usuário deve inserir uma chave inteligente na posi¸cão da bicicleta escolhida. Após a valida¸cão da chave, a posi¸cão é destravada. Para realizar uma devolu¸cão o usuário deve apenas encaixar a bicicleta em uma posi¸cão, em qualquer esta¸cão.

Ap´os a retirada, os usu´arios podem utilizar a bicicleta por 30 minutos seguidos. Pontos positivos do sistema:

• a valida¸cão por chave elimina a dependência de outras formas de comunica¸cão, como internet e telefone;

• a aplica¸c˜ao funciona na web, o que facilita a consulta dos dados em tempo real.

2.3 Resumo do cap´ıtulo

Neste cap´ıtulo foram apresentados dois sistemas que estão relacionados ao tema do tra-balho descrito nesta monografia. O primeiro sistema apresentado foi desenvolvido pela empresa Serttel e utiliza plataformas web e mobile, entretanto, faz obrigatório o uso de aparelho celular para seu uso diário. O sistema apresentado na segunda se¸cão foi de-senvolvido pela companhia privada Motivate e faz uso de autentica¸cão por RFID (Radio Frequency Identification). A visualiza¸cão das informa¸cões armazenadas é feita por meio de interfaces web e mobile.

(19)

7

Figura 2.2: Tela inicial do aplicativo Citi Bike

O próximo cap´ıtulo descreve a arquitetura do sistema proposto, definindo o con-texto e estruturas relacionadas ao problema que se propõe a resolver. Apresenta detalhes sobre o estudo de caso, defini¸cão de requisitos e estabelecimento da estrutura necessária ao projeto. ’

(20)

Cap´ıtulo 3

Arquitetura proposta

O cap´ıtulo anterior apresentou sistemas implantados e em desenvolvimento que est˜ao buscando solucionar o mesmo problema do projeto de sistema sugerido neste trabalho.

3.1 Estudo de caso

Este projeto tem como finalidade principal desenvolver um sistema que permita os alunos da Universidade Federal Fluminense utilizar bicicletas públicas, retirando e devolvendo-as em esta¸cões espalhadas pelos campi da UFF, com valida¸cão a partir da carteira de estu-dante. O sistema também deve prover informa¸cões sobre a disponibilidade de bicicletas nas esta¸cões em tempo real.

O sistema foi desenvolvido de tal forma a permitir sua extensão, sendo assim pos-s´ıvel acoplar à solu¸cão outras funcionalidades e análises futuras. Mesmo vislumbrando a possibilidade de expansão, o foco deste trabalho é descrever um protótipo que visa a auxiliar o deslocamento de alunos entre os diferentes campi da UFF.

Esta se¸cão descreve o cenário as is da Universidade Federal Fluminense em Niterói, que foi definida como cliente alvo deste trabalho, apontando as principais dificuldades enfrentadas atualmente, seguido da solu¸cão proposta que visa resolver essas dificuldades.

3.1.1 A Institui¸

c˜

ao de Ensino

Neste per´ıodo de desenvolvimento foi utilizado como cliente-alvo deste trabalho os alunos da Universidade Federal Fluminense que cursam a universidade em Niter´oi. Atualmente,

(21)

9 a universidade possui aproximadamente cinquenta e um mil discentes sendo que, aproxi-madamente trinta mil cursam aulas presencias.

Apesar de possuir iniciativas para melhorar a mobilidade dos seus alunos e a cons-tru¸cão de prédios novos que podem facilitar o deslocamento entre as aulas, a UFF, que foi criada a partir da união de diversas faculdades diferentes, tem como caracter´ıstica ter seus campi espalhados pela cidade de Niterói. Essa dispersão de campi dificulta o acesso `

as aulas e pode prejudicar a frequˆencia e a pontualidade dos alunos.

3.1.2 Situa¸

c˜

ao atual

Como foi informado na sessão anterior, a UFF tem como caracter´ıstica a distância entre os seus campi podendo gerar caminhadas de até 5km. Outro fator inerente a existência da universidade é a grande quantidade de alunos que vem por dia do Rio de Janeiro usando catamarã e barcas, estes além de chegar no em Niterói ainda tem que deslocar até o campi. A universidade tem um sistema de ônibus, o BusUFF que presta apoio aos seus discentes no deslocamento diário para assistir as aulas. Muito elogiado quando foi im-plantado o sistema de ônibus entre campi possui dois itinerários, a Rota 1 e a Rota 2. Com ônibus de 25 em 25 minutos na Rota 1 e 45 em 45 minutos na Rota 2[UFF, 2016], o principal problema enfrentado hoje pelos alunos que optam por usar o BusUFF para se locomover no dia a dia é a lota¸cão dos ônibus, principalmente nos horários que coincidem com o término ou in´ıcio das aulas. Outro problema enfrentado pelos alunos é o recorrente atraso dos ônibus, o que normalmente ocorre nas horas do rush. Ainda que os problemas de lota¸cão e horário do BusUFF fossem resolvidos, ainda ter´ıamos a necessidade de buscar alternativas de locomo¸cão. O ônibus, mesmo sendo um meio de transporte coletivo (o que concede a ele uma posi¸cão favorável ao carro, por exemplo), vendo sobre o ponto de vista ambiental é um desastre que libera monóxido e dióxido de carbono na atmosfera (ônibus com um motor eletrico poderia resolver).

Então mesmo auxiliando o aluno no deslocamento diário, o BusUFF não atende como uma solu¸cão sustentável para transporte universitário, pois não atende a demanda, tem problemas com atrasos e não é ecologicamente saudável.

(22)

10

3.2 Solu¸

c˜

ao Proposta

A proposta consiste no desenvolvimento de sistema para localiza¸cão e loca¸cão de bicicletas no ambiente universitário e de um terminal com controle sobre a libera¸cão das bicicletas.

Os problemas a serem resolvidos s˜ao:

• Criar um meio de transporte seguro para os Alunos; • Criar um m´etodo que de transporte que evite atrasos;

• Dar visibilidade ao aluno quanto a disponibilidade de meios transporte; • Garantir que somente alunos terão acesso ao meio de transporte universitário; • Criar uma solu¸cão de transporte que não agride o meio ambiente.

Visando resolver os problemas anteriores e aliar tecnologia ao dia a dia dos alunos. Propomos para a retirada de bicicletas o seguinte:

1 O usu´ario verifica a disponibilidade de uma bicicleta em sua proximidade. 2 Em um terminal o usu´ario escolhe a bicicleta que deseja pegar.

3 O usu´ario se autentica no terminal usando sua carteira de estudante. 4 O terminal envia para o servidor uma requisi¸c˜ao de retirada de bicicleta

5 O Sistema verifica se o aluno possui matr´ıcula ativa, em seguida verifica se h´a alguma pendˆencia no aluguel da bicicleta.

6 Se não houver pendências, o sistema verifica se há alguma avaria relatada na bi-cicleta, não havendo nada o sistema retorna para o terminal uma mensagem de sucesso, caso contrário o sistema retorna uma mensagem de erro.

7 O terminal lê a mensagem recebida pelo servidor, caso sucesso libera a bicicleta selecionada, caso contrário avisa ao usuário que houve um problema.

8 O Usu´ario faz o translado com a bicicleta e identifica o terminal que deseja devolver a bicicleta.

(23)

11 10 O módulo lê o código RFID da bicicleta e a posi¸cão que ela foi devolvida e agradece

o aluno.

11 O sistema identifica qual bicicleta esta sendo devolvida e, em seguida, faz uma requisi¸cão de devolu¸cão informando qual é o terminal, a posi¸cão que a bicicleta foi devolvida e o identificador da bicicleta.

12 O servidor lê a requisi¸cão, identifica qual aluno devolveu a bicicleta e atualiza a o status da bicicleta, liberando ela para novas retiradas e tira a pendência de devolu¸cão do usuário.

Figura 3.1: Modelo de esta¸cão para retirada de bicicletas proposto O sistema tem restri¸cões a serem consideradas para perfeito funcionamento: • Um usuário não deve conseguir retirar uma bicicleta se não devolveu a última

bi-cicleta que retirou. Ou seja se houver uma retirada sem devolu¸cão o aluno fica impossibilitado de fazer uma nova retirada enquanto não quitar a sua pendência. • Fica restrita a retirada de bicicletas apenas por usuários que possuam carteira de

estudante.

3.3 Arquitetura do Sistema

A arquitetura planejada para o sistema ´e dividida em trˆes partes:

1 Aplica¸cão Web que conta com uma API (Application Programming Interface) para comunica¸cão com outros sistemas, web services e DAO’s (Data Access Objects) para comunica¸cão com o Sistema de Gerenciamento de Banco de Dados (SGBD);

(24)

12 2 Módulo em Arduino, que conta com um leitor de NFC para ler as carteiras de estudante, um teclado e uma antena para conexão com a internet, além de uma tela LCD. O módulo Arduino ficará em uma esta¸cão com uma quantidade de leitores RFID, que pode variar de esta¸cão para esta¸cão. A quantidade de leitores limita a quantidade de bicicletas por esta¸cão, pois cada uma ocupará um slot de leitura. 3 Base de dados para armazenamento das informa¸cões.

A aplica¸cão Web usa o padrão de projeto DAO para abstrair e encapsular os mecanismos de acesso aos dados. O padrão de projeto DAO permite criar as classes de dados independentemente do tipo de modelagem da base de dados. Todos os acessos aos dados devem ser por meio das classes DAO. Isto garante que haja separa¸cão entre as duas partes importantes da aplica¸cão que não devem conhecer muito uma da outra e devem evoluir de forma independente. Além disso usamos o padrão de projeto de projeto Business Objetc para fazer as regras de negócio da ferramenta. O padrão de projeto Business Object garante maior desacoplamento ao projeto, assim mantendo o código mais limpo e refatorável. Todas as regras de negócio são escritas nas classes Business assim melhorando o reuso de código.

O modelo de banco de dados escolhido para o desenvolvimento do sistema foi o modelo relacional. Para se escolher o sistema de gerenciamento de banco de dados (SGBD) mais adequado para cada aplica¸cão, deve-se levar em conta quais os dados serão acessados e como estes se ralacionam entre si. Como os dados utilizados no desenvolvimento do sistema são dados estruturados, ou seja, as entidades do modelo de dados se relacionam de maneira estruturada com uma ordem e grau, um SGBD relacional se faz necessário. Outro ponto importante a ser analisado na escolha do SGBD é se há controle de concorrência, que tenta evitar transa¸cões feitas acessando a mesma informa¸cão por usuários distintos ao mesmo tempo.

O módulo Arduino será desenvolvido para fazer interface com os usuários finais do sistema. A intera¸cão com o sistema deve ser projetada de forma a ser intuitiva, segura e funcional. Com inten¸cão de reduzir o trafego de dados na rede, o m´ınimo de requisi¸cões devem ser trocadas entre o módulo arduino e a aplica¸cão web, dessa maneira uma parte do processamento e da valida¸cão deve ser feita no próprio módulo, a fim de evitar requisi¸cões desnecessárias ao sistema web.

(25)

13 A escolha de pe¸cas e componentes para o módulo deste sistema foi feita visando a redu¸cão do custo total de implanta¸cão. Para isto projetamos um módulo controlando um conjunto de 8 bicicletas ou mais bicicletas, embora uma op¸cão com 1 (um) leitor de cartão para cada bicicleta seja mais simples, pois evita que o usuário tenha a intera¸cão de informar qual bicicleta deseja.

3.4 Requisitos do Sistema

No contexto do presente projeto, foi identificado apenas uma intera¸cão entre o usuário final e o sistema. Assim, fica descrito na imagem 3.2 as intera¸cões entre o usuário e a esta¸cão arduino.

(26)

14 As intera¸cões dos usuários com o módulo web são descritas pela figura 3.3. Neste caso de uso existem dois usuários, o Aluno e o Administrador do sistema, que possui todas as atividades do aluno e mais as atividades de cadastro e edi¸cão.

Figura 3.3: Casos de uso da aplica¸c˜ao WEB

Para estabelecer a prioridade dos requisitos nas se¸cões 3.4.1 e 3.4.2, foram adotadas as denomina¸cões “essencial”, “importante” e “desejável”:

• Essencial é o requisito sem o qual o sistema não entra em funcionamento. Requi-sitos essenciais são requisitos imprescind´ıveis, que devem que ser implementados impreterivelmente;

• Importante é o requisito sem o qual o sistema entra em funcionamento, mas de forma não satisfatória. Requisitos importantes devem ser implementados, mas, se não forem, o sistema poderá ser implantado e usado mesmo assim; e

• Desejável é o requisito que não compromete as funcionalidades básicas do sistema, isto é, o sistema pode funcionar de forma satisfatória sem ele. Requisitos desejáveis podem ser deixados para versões posteriores do sistema, caso não haja tempo hábil para implementá-los na versão que está sendo especificada.

(27)

15

3.4.1 Requisitos Funcionais

Para o funcionamento desejado do sistema ´e necess´ario que os seguintes requisitos sejam preenchidos:

FR01 - Selecionar Bicicleta check-in. Ator(es): Aluno.

Descri¸c˜ao: Usu´ario seleciona a bicicleta desejada Prioridade: Essencial.

Pré-condi¸cões: Não há pré-condi¸cões.

Pós-condi¸cões: O ator será encaminhado para a autentica¸cão. FR02 - Validar usuário.

Ator(es): Aluno portador da carteirinha. Descri¸c˜ao: Autentica o usu´ario no sistema. Prioridade: Essencial.

Pré-condi¸cões: O ator deve ter selecionado a bicicleta que deseja. Pós-condi¸cões: O ator terá será informado se pode retirar sua bicicleta. FR03 - Devolver a Bicicleta. Ator(es): Aluno.

Descri¸c˜ao: Devolve uma bicicleta para uma esta¸c˜ao. Prioridade: Essencial.

Pré-condi¸cões: Não há pré-condi¸cões

Pós-condi¸cões: Deverá ser exibido na tela uma mensagem de agradecimento. FR04 - Visualizar bicicletas dispon´ıveis.

Ator(es): Aluno.

Descri¸c˜ao: Aciona uma tela que indica a localiza¸c˜ao das bicicletas dispon´ıveis. Prioridade: Importante.

Pré-condi¸cões: Não há pré-condi¸cões

Pós-condi¸cões: Deverá ser exibido na tela um mapa com a posi¸cão de cada esta¸cão e a quantidade de bicicletas dispon´ıveis.

(28)

16 Ator(es): Aluno.

Descri¸c˜ao: O ator pode informar que uma bicicleta esta com problemas. Prioridade: Desej´avel.

Pr´e-condi¸c˜oes: O ator deve estar autenticado no sistema.

Pós-condi¸cões: O uma notifica¸cão criada informando a avaria da bicicleta e esta não poderá ser locada.

FR06 - Liberar bicicleta. Ator(es): Administrador.

Descri¸cão: Após o conserto da bicicleta disponibilizá-la novamente para uso mobile. Prioridade: Desejável.

Pr´e-condi¸c˜oes: O ator deve estar logado no sistema.

Pós-condi¸cões: A bicicleta ficará dispon´ıvel novamente para loca¸cão FR07 - Visualizar histórico de loca¸cões.

Ator(es): Aluno.

Descri¸cão: Visualizar o histórico de bicicleta retiradas. Prioridade: Desejável.

Pr´e-condi¸c˜oes: O ator deve estar autenticado.

Pós-condi¸cões: Uma lista com as bicicletas que o usuário já alugou será disponibili-zada.

FR08 - Visualizar rotas para uma esta¸c˜ao. Ator(es): Aluno.

Descri¸cão: Visuzizar uma rota para uma esta¸cão selecionada. Prioridade: Desejável.

Pré-condi¸cões: Não há pré-condi¸cões.

Pós-condi¸cões: Uma rota com o menor caminho entre a localiza¸cão do usuário e a esta¸cão selecionada deve ser exibida.

FR09 - Cadastrar Aluno. Ator(es): Administrador.

Descri¸c˜ao: Cadastrar alunos no sistema. Prioridade: Essencial.

(29)

17 Pós-condi¸cões: As informa¸cões do aluno são salvas no banco de dados.

FR10 - Cadastrar bicicletas. Ator(es): Administrador.

Descri¸c˜ao: Cadastrar uma nova bicicleta no sistema. Prioridade: Essencial.

Pr´e-condi¸c˜oes: O ator deve estar autenticado

Pós-condi¸cões: As informa¸cões da nova bicicleta serão salvas no banco de dados. FR11 - Cadastrar esta¸cões.

Ator(es): Administrador.

Descri¸c˜ao: Cadastrar uma nova esta¸c˜ao com uma capacidade escolhida pelo ator Prioridade: Essencial.

Pós-condi¸cões: Uma nova esta¸cão deve ser criada e salva no sistema. FR12 - Exclusão do aluno.

Descri¸c˜ao: O adminitrador pode desativar qualquer aluno do sistema. Prioridade: Importante.

Pós-condi¸cões: O aluno não conseguirá retirar bicicletas. FR13 - Verificar pendência.

Ator(es): Aluno.

Descri¸cão: O ator deve visualizar se existe pendência em seu nome. Prioridade: Desejável.

(30)

18 FR14 - Extrair relat´orio de uso.

Descri¸cão: Deverá extrair um relatório com as informa¸cões de uso de bicicleta por esta¸cão e rotas mais usadas.

Prioridade: Desej´avel.

Pós-condi¸cões: Um relatório ficará dispon´ıvel para download. FR15 - Alterar Esta¸cão.

Descri¸cão: Altera e corrige alguma informa¸cão da esta¸cão, colocando uma bicicleta ou corrigindo uma distor¸cão.

Pós-condi¸cões: As novas informa¸cões da esta¸cão são salvas no banco. FR16 - Editar Bicicleta.

Descri¸cão: Deve alterar as informa¸cões da bicicleta, como a esta¸cão salva ou o código RFID em caso de avaria.

Pós-condi¸cões: As novas informa¸cões da bicicleta devem estar dispon´ıveis.

3.4.2 Requisitos N˜

ao Funcionais

NFR01 - Usabilidade

Descri¸cão: A interface com o usuário é fundamental para o sucesso do sistema, principalmente porque será utilizada diariamente e o usuário poderá não receber treinamento prévio. A intera¸cão com o sistema deve ser clara e intuitiva para que usuários consigam usar mesmo sem aux´ılio e consigam retirar uma bicicleta com facilidade em menos de 20 segundos.

(31)

19

3.5 Resumo do cap´ıtulo

Neste cap´ıtulo foi definida a estrutura, os componentes e requisitos para implementa¸cão do sistema proposto. Na Se¸cão 3.1 foi feito um estudo do caso, onde foi definida a finali-dade principal do projeto, o cliente-alvo utilizado durante o per´ıodo de implementa¸cão e a situa¸cão em que o cliente-alvo se encontra em rela¸cão ao tema desta monografia. Posteri-ormente, na Se¸cão 3.2, uma solu¸cão foi proposta visando sanar as dificuldades citadas. Já na Se¸cão 3.3, foi definida uma estrutura abstrata com seus componentes, visando estabe-lecer uma arquitetura para o sistema. Por fim, na Se¸cão 3.4, foram levantados requisitos do sistema para implementa¸cão futura.

O próximo cap´ıtulo tratará das tecnologias relevantes utilizadas na implementa¸cão do projeto piloto ou sugeridas para implementa¸cão futura. Nele será descrito o que é e como funciona cada tecnologia, em que parte do sistema deve ser utilizado e quais os motivos para utiliza¸cão.

(32)

Cap´ıtulo 4

Tecnologias Relevantes

O cap´ıtulo anterior apresentou a estrutura e requisitos fundamentais para imple-menta¸cão da solu¸cão sugerida neste projeto. Este cap´ıtulo visa contribuir para uma melhor compreensão das tecnologias contempladas por este trabalho.

4.1 Arduino

Arduino é uma plataforma Open Source que tem como principal valor ser fácil de usar. As placas Arduino são capazes de ler sensores, acender luzes, ativar pequenos motores e até publicar algo online.[Arduino, 2017b] Para usar o Arduino, além de ter a placa é necessário que se tenha a IDE instalada. Arduino nasceu no Ivrea Interaction Design Institute como uma ferramenta para prototipa¸cão fácil e rápida, e tinha como público alvo alunos sem conhecimento profundo de eletrônica e programa¸cão. Conforme foi se espalhando, a placa Arduino foi se especializando adaptando para novas necessidades e desafios, e conseguiu-se diferenciar das outras placas 8-bits como um produto completo para aplica¸cões da IoT (Internet of Things). Arduino roda em Linux, Mac e Windows e é fácil de usar para iniciantes, mas também flex´ıvel o suficiente para que usuários avan¸cados consigam desenvolver projeto interessantes e poderosos nele. Seguem as principais vantagens de se usar Arduino:

• Barato: Placas Arduino s˜ao relativamente baratas se comparadas com outros mi-crocontroladores.

• Multi-plataforma: A IDE para desenvolver softwares para o Arduino funciona em 20

(33)

21 Windows, Macintosh OSX e Linus, enquanto a maioria dos microcontroladores fun-ciona somente no Windows.

• Simplicidade: A IDE ´e bem simples de usar

• Código Livre e software extens´ıvel: O software que compõe o Arduino é aberto. A linguagem de programa¸cão do Arduino foi baseada em C e pode ser expandida por meio de bibliotecas em C++.

• Hardware Livre: todos as plantas da placa do Arduino são abertas e possuem licen¸ca que permite que você produza e modifique suas próprias placas

Arduino foi escolhido para o desenvolvimento desse projeto exatamente por ser barato, possuir uma grande documenta¸cão e ser bastante expans´ıvel com bibliotecas. Nas suas versões mais poderosas é poss´ıvel ligar leitores de cartão, antenas wifi, sensores de proximidade, LEDs, telas LCD, teclados matriciais entre outros componentes. Essa flexibilidade nos permitiu desenvolver o projeto e incluir todas os componentes extras de maneira simples.

4.2 NFC

NFC (Near Field Communication) é uma tecnologia desenvolvida para comunica-¸cão de dois dispositivos sem a utiliza¸cão de fios. Criada em 2004, a partir de um fórum que tinha como objetivo criar uma tecnologia segura e fácil de se usar para comunica¸cão sem fios. Seu principal propósito é fazer a conexão entre um leitor e uma etiqueta (ou outro dispositivo qualquer que possua a teconologia NFC) a partir de radio frequência.

Em 2006, no NFC Forum, foi especificado um objeto chamado de NFC Tag, que seria um pequeno objeto que conteria informa¸cões que seriam compat´ıveis com dispositivos que contivessem a tecnologia NFC. Essas etiquetas são objetos de armazenamento onde dispositivos podem escrever ou ler informa¸cões. A tag NFC é ativada pelo leitor. O dispositivo leitor emite um sinal para a tag e se estiverem próximos o suficiente a tag é ativada ao receber o sinal. A partir de então a tag recebe uma requisi¸cão e testa se é válida. Se sim, a tag responde.

Com essa tecnologia foi poss´ıvel implementar muitas aplica¸cões e uma delas é a identifica¸cão. Um indiv´ıduo pode ser autenticado por meio de um cartão lido por

(34)

22 um dispositivo programado para testar a validade dos dados lidos. No caso do sistema desenvolvido neste projeto, nossa op¸cão de autentica¸cão é a leitura da carteirinha de estudante. No caso da Universidade Federal Fluminense (UFF) os alunos têm carteirinhas de estudante com tecnologia NFC que pode ser utilizada nesta autentica¸cão.

4.3 REST

REST é um acrônomo para Representational State Transfer, que em português signi-fica Transferência de Representa¸cão de Estado. Pode ser definido como uma arquitetura para comunica¸cão e foi desenvolvido por um dos criadores do protocolo HTTP, é lar-gamente usado no mercado e ainda é o protocolo padrão para troca de mensagens na internet. REST foi constru´ıdo com a objetivo de utilizar de maneira eficiente as caracte-r´ısticas do HTTP, explorando principalmente a semântica do protocolo e como resultado acabou-se criando um protocolo mais rápido, padronizado e eficiente para troca de men-sagens [TreinaWeb, 2017].

Para entender melhor o funcionamento do REST primeiro deve-se levar em conta algumas caracter´ısticas do protocolo HTTP que por consequência também são caracter´ıs-ticas da arquitetura REST.

• É um protocolo cliente-servidor, por exemplo quando um navegador acessa uma página, o cliente é o browser e o servidor é o site de onde os arquivos HTML serão baixados.

• A requisi¸cão é feita em ciclos de resquest e response, e não é necessário manter uma conexão ativa. O cliente faz um request e o servidor envia um response, não sendo necessária nenhuma outra mensagem.

• O protocolo funciona de maneira ass´ıncrona e independente, isto é se o cliente enviar mais do que um requests eles não precisam ser respondidos na mesma ordem que foram enviados e cada request não tem acesso a um outro que tenha sido enviado prévia ou posteriomente.

• O protocolo é stateless, como cada request é independente e elas são fechadas quando recebe sua response não é poss´ıvel guardar estados das requisi¸cões.

(35)

23 • O protocolo HTTP possui uma semântica com verbos e os Unique Resource Locators (URLs). As URLs indicam os objetos ou resources que serão acessados e os verbos as diferentes a¸cões que podem ser desempenhadas por cada request. Os principais verbos são GET, POST, DELETE e PUT e suas a¸cões fazem, respectivamente: obter, inserir, apagar e atualizar um resource.

Usamos o padrão REST pois é amplamente usado em solu¸cões comerciais e escolhe-mos a linguagem Java para desenvolver o web service. Quando um web server implementa a arquitetura REST, chamamos de um servi¸co RESTful. Para facilitar o desenvolvimento do web server usamos um framework chamado Jersey, também consolidado no mercado que tem algumas ferramentas que facilitam a implementa¸cão do protocolo HTTP junto com a arquitetura REST. O Jersey possui uma API e uma série de ferramentas que sim-plificam o desenvolvimento de clientes e servidores Java[Jersey, 2017].

4.4 RFID

A tecnologia data da Segunda Guerra Mundial, e tem origem nos radares usados para verificar a aproxima¸cão de aviões com alguma antededência. Entretanto o RFID só foi patenteado na décata de 1970, quando um sistema para desbloquear portas utili-zando uma etiqueta foi desenvolvido. RFID (Radio Frequency Identification) é uma tecnologia que tem objetivo localizar, identificar e gerenciar produtos de diferentes na-turezas. Uma de suas principais vantagens é a independência de campo visual para funcionar[Roberto Brauer di Renna, 2014]. Seu uso funciona com um leitor, uma eti-queta e um banco de dados e cada um desempenha sua fun¸cão. As etiquetas podem ter informa¸cões salvas e alteradas, e geralmente apontam para algum valor armazenado no banco. Então o leitor lê o identificador na etiqueta e consulta no banco a que tipo de produto aquela etiqueta se refere.

4.5 Resumo do cap´ıtulo

Neste cap´ıtulo foram apresentadas tecnologias relevantes ao sistema a ser desenvolvido. O próximo cap´ıtulo descreve os detalhes da implementa¸cão de cada componente do projeto piloto. Algumas tecnologias descritas neste cap´ıtulo serão utilizadas no próximo.

(36)

Cap´ıtulo 5

Implementa¸

c˜

ao

O cap´ıtulo anterior vimos tecnologias que são relevantes para o projeto proposto e definido no cap´ıtulo 3. Este cap´ıtulo consiste em detalhar o desenvolvimento implementa¸cão do módulo Arduino e do sistema web, descrevendo linguagens e ferramentas utilizadas, entre outras informa¸cões pertinentes ao desenvolvimento, utilizando tecnologias descritas no Cap´ıtulo 4.

5.1 Banco de dados

O modelo Entidade Relacionamento foi constru´ıdo utilizando a ferramenta MySQL Work-bench. O MySQL Workbench[MySQL, 2017] é uma ferramenta gráfica da empresa Oracle Corporation para desenvolver e operar bancos de dados.Esta ferramenta possui funcionali-dades para auxiliar o trabalho dos profissionais que tabalham com banco de dados, desde DBAs (Database administrators), passando por arquitetos de banco, até desenvolvedo-res. Entre suas funcionalidades, se destacam uma interface gráfica, que foi usada para projetar o banco deste projeto, uma interface para administrar conexões com servidores, scripts SQL, ferrametas para criar e carregar backups e ferramentas de monitoramento de desempenho.

O diagrama apresentado na figura 5.1 foi definido de forma a atender os requisitos do sistema.

(37)

25

Figura 5.1: Modelo Entidade Relacionamento do Banco de Dados

O modelo relacional é composto por 5 tabelas: USUARIO, BICICLETA, ESTA-CAO, ESTACAOSLOT E HISTORICO. A tabela USUARIO é responsável por armazenar dados pertinentes aos usuários do sistema, identificados por meio da chave primária IDU-SUARIO além disso nessa tabela está armazenado o código do NFC que esta na carteirinha de estudante do Aluno.

A tabela BICICLETA contem informa¸cões referentes a bicicleta, incluindo o seu ID, o Código RFID, responsável pela identifica¸cão da bicicleta, e um código para controle interno. Esta tabela possui uma chave estrangeira para a tabela USUARIO, para acom-panhar qual usuário esta com ela locada no momento, e outra chave estrangeira para a tabela ESTACAOSLOT, de onde é poss´ıvel obter a informa¸cão de qual esta¸cão a bicicleta se encontra e qual é o a sua posi¸cão dentro da esta¸cão.

Para armazenar as informa¸cões referentes as esta¸cões usamos duas tabelas, ESTA-CAO e ESTAESTA-CAOSLOT. A tabela ESTAESTA-CAO armazena as informa¸cões referentes a cada esta¸cão de bicicleta, com um código para controle interno a latitude e a longitude além

(38)

26 da capacidade de cada esta¸cão. Já a tabela ESTACAOSLOT representa cada posi¸cão aonde pode-se armazenar uma bicicleta dentro da esta¸cão, as duas tabelas se relacionam de maneira que cada esta¸cão tem a quantidade definida pelo campo capacidade de slots e cada slot pode pertencer a somente uma esta¸cão.

Todas as tabelas citadas anteriormente se se relaciona com a tabela HISTORICO, para que seja poss´ıvel armazenar qual usuário fez uma retirada ou devolu¸cão de bicicleta, se relaciona também com a tabela bicicleta

O modelo relacional para o banco de dados foi escolhido para o projeto pois nosso projeto apresenta uma conjunto de entidades que se relacionam, dessa maneira um modelo orientado a documentos não se encaixa. Ainda que fosse poss´ıvel replicar esse modelo com algumas altera¸cões em um modelo NoSql, por exemplo, optamos por seguir com o modelo relacional, já que este garante a consistência dos dados. Outro fator relevante para a ado¸cão do modelo relacional foi a maior praticidade de criar um banco de dados em compara¸cão com os outos modelos existentes.

5.2 M´

odulo Arduino

Nesta se¸cão apresentamos os componentes do modelo arduino e os esquemas usados para montar o módulo. Como foi citado no Cap´ıtulo 3, o projeto foi planejado para funcionar a partir da intera¸cão entre 3 componentes independentes, o módulo Arduino, o Sistema Web e o Banco de Dados. O módulo Arduino foi desenvolvido para ser a principal interface entre o usuário final (Aluno) e o sistema. Suas funcionalidades consistem em retirar e devoler uma bicicleta e para que fa¸ca isso de maneira correta foram usados uma série de componentes eletrônicos espec´ıficos para entrada, tratamento e sa´ıda de dados. Os principais componentes são: Arduino Mega, Teclado Matricial, LCD 16x2, Leitor RFID e Módulo WiFi esp8266 [ESP8266, 2017].

A figura 5.2 mostra o prot´otipo arduino montado para o desenvolvimento deste projeto.

5.2.1 Arduino Mega

A Placa Arduino Mega pertence plataforma Arduino e tem como base o microcontrolador ATmega2560, possui 54 pinos de entradas e sa´ıdas digitais, 16 entradas anal´ogicas e 4

(39)

27

Figura 5.2: Prot´otipo do m´odulo Arduino

portas serial[Arduino, 2017a]. É similar a placa mais comum e simples da plataforma, a Arduino UNO, mas possui mais memória, portas e suas dimensões são maiores.

A placa pode ser alimentada pela USB ou por uma fonte de alimenta¸cão externa. Optamos pela alimenta¸cão de fonte externa no nosso projeto, usando uma fonte de 12V. Assim como a UNO, a placa MEGA consegue fornecer sa´ıda de energia com tensão de 3,3V e de 5V, o que foi necessário para o projeto, pois temos componentes que possuem ranges de tensão diferentes. A placa MEGA foi escolhida no lugar da UNO por possuir maior quantidade de portas de entradas e sa´ıdas digitais e principalmente por possuir 4 portas serial.

(a) Arduino UNO (b) Arduino MEGA

Figura 5.3: Diferen¸ca na quantidade de portas entre Arduinos UNO e MEGA

5.2.2 Teclado Matricial 4x4

O Teclado Matricial 4x4 foi escolhido como método para o usuário selecionar a bicicleta que deseja. É um componente de baixo custo com funcionamento simplificado e possui 16 botões.Utilizamos 8 portas do Arduino para liga¸cão ao teclado matricial.

(40)

28

Figura 5.4: Schema do teclado matricial Pino Teclado Porta Arduino

1 23 2 25 3 27 4 29 5 31 6 33 7 35 8 37

Tabela 5.1: Pinos do Teclado Matricial.

Para controlar o teclado no sistema fizemos uso da biblioteca open source chamada keypad, pois ela simplifica a leitura de dados com fun¸cões já pré carregadas. O teclado foi ligado no arduino de acordo com a tabela 5.1.

(41)

29 Pino Ligado Em

1 Ground

2 +5V

3 Pino central do Potenciˆometro 4 Pino 11 5 GND 6 Pino 9 7 Pino 4 8 Pino 5 9 Pino 6 10 Pino 7 11 +5 V 12 GND Tabela 5.2: Pinagem do LCD

5.2.3 LCD 16x2 I2C

Como dito anteriormente o módulo Arduino, que é pe¸ca principal da esta¸cão para retirada de bicicletas, é a principal interface com o usuário, então foi necessário projetar uma maneira de dar feedbacks para o cliente sobre o andamento do processo de retirada da bicicleta.

o LCD 16x2 I2C funciona com o protocolo I2C e seu nome é dado pois se trata de um display LCD de 16 caracteres por coluna com duas colunas. Ou seja, podemos gracar até 32 caracteres no nosso LCD 16x2. O I2C encontra-se presente no nome, pois utilizaremos o protocolo de comunica¸cão I2C para envio de dados entre o Arduino e o dispositivo. Foi usado um potênciometro para fazer a regulagem do contraste

(42)

30

Figura 5.5: LCD 16x2

5.2.4 M´

odulo RFID

Leitores e tags RFID (Radio Frequency Identification, ou Identifica¸cão por Radiofrequˆ en-cia) costumam ser utilizados para controle de acesso e identifica¸cão de pessoas e equi-pamentos, seja por meio de crachás ou etiquetas aplicadas à produtos. Como foi visto no cap´ıtulo 3, esta tecnologia é usada no dia da dia dos brasileiros e estudantes e esta empregada em dispositivos que fazem parte de nosso cotidiano, como cartão de ônibus, cancelas do pedágio e estacionamentos.

Figura 5.6: M´odulo RFID

As etiquetas (ou tags) RFID, podem conter vários dados sobre o proprietário do cartão, como nome e endere¸co e, no caso de produtos, informa¸cões sobre procedência e data de validade. A carteira de estudante da UFF é usada como tag neste projeto, pois possui a tecnologia RFID e os alunos podem usá-la como bilhete único e método

(43)

31 Pino Arduino Pino RFID

N˜ao Conectado NC 3,3V VCC GND GND 5 RST 53 SDA 51 MOSI 50 MISO 52 SCK Tabela 5.3: Pinagem do RFID

de pagamento para o Restaurante Universit´ario. Nossa proposta ´e incluir mais um uso e possibilitar a retirada de bicicletas para usar no trajeto entre os campi da universidade.

As etiquetas (ou tags) RFID, podem conter vários dados sobre o proprietário do cartão, como nome e endere¸co e, no caso de produtos, informa¸cões sobre procedência e data de validade.

Escolhemos um leitor de RFID Mfrc522 Mifare para este projeto, que pode ser fácilmente adquirido em lojas online e é o modelo mais usado para esse tipo de prototi-pagem. Sua frequência de opera¸cão é de 13,56MHz, suficiente para ler a carteirinha de estudante da UFF. O leitor RFID tem 8 pinos e sua tensão de alimenta¸cão é de 3.3 volts. As conexões entre o módulo d RFID e o arduino são descritas na tabela 5.3.

5.2.5 esp8266

Para que consigamos fazer a valida¸cão do usuário e a coleta de informa¸cões, precisamos estabelecer uma conexão entre o Arduino e o web server. Como nos campi da UFF temos internet sem fio dispon´ıvel para todos os alunos, escolhemos fazer a conexão usando wifi, através do módulo esp8266 [ESP8266, 2017].

Ultimamente o módulo esp8266 esta sendo muito usado para protótipos e produtos, pois o conceito de IoT (Internet of Things) está em alta. Como é um módulo Open Source, barato e simples de montar ganhou a preferência dos desesnvolvedores. Por ter uma biblioteca grande, uma comunidade ativa para auxiliar com dúvidas, ser fácil de

(44)

32 ESP8266 Arduino GND GND VCC 3,3V CHPD 3,3V TXD 17 RX RXD 18 TX

Tabela 5.4: Pinagem do m´odulo Wifi

adquirir e com custo relativamente barato nós optamos por usar este módulo em nosso projeto. No desenvolvimento da aplica¸cão contamos com o apoio da biblioteca esp8266wifi

Figura 5.7: Esquema do m´odulo esp8266

e esp8266Rest para conectar com o servidor e enviar requisi¸cões. A conexão com o servidor é feita usando o protocolo de redes TCP/IP, para envio de pacotes com garantia de recebimento. As conexões da placa esp8266 e o Arduino estão descritas na tabela 5.4 Seguem algumas caracter´ısticas do módulo esp8266:

• Tens˜ao de entrada de 3,3V • Alcance m´edio de 91m.

• Conexão à redes padrão 802.11 B/G/N

• Modos de opera¸cão: Cliente, Access Point, Cliente+Access Point • Seguran¸ca: OPEN/WEP/WPAPSK/WPA2PSK/WPAWPA2PSK. • Suporta comunica¸cão TCP e UDP, com até 5 conexões simultâneas

(45)

33

5.3 Interfaces Web

Nesta se¸cão será apresentada as interfaces implementadas para o web na versão piloto. A aplica¸cão possui interfaces web para o setor administrativo da ferramenta e para ao aluno. As interfaces da aplica¸cão foram desenvolvidas usando HTML5 e CSS3, e executam scripts JavaScritp para o envio das requisi¸cões. HTML é o padrão utilizado para represen-tar páginas web e CSS é um stylesheet, que define o layout da página em questão. Estas interfaces se comunicam com o web server por meio da API REST que foi desenvolvida. Optamos por fazer dessa maneira para garantir maior desacoplamento, desta maneira a API pode passar por modifica¸cões e melhorias sem a necessidade de alterar as interfaces, e vice-versa (desde que a assinatura dos métodos da API não sejam modificados).

5.3.1 Interface Aluno

Desenvolvemos uma página web como landing page informando sobre o projeto e suas funcionalidades. Nessa página, descrita na figura 5.8, contém o logo do projeto e uma barra de navega¸cão para utilizar as outras interfaces dispon´ıveis.

Figura 5.8: Home Page

A Figura 5.9 representa a principal interface web desenvolvida para intera¸cão entre aluno e sistema. Nela você consegue verificar facilmente onde se encontram as bicicletas dispon´ıveis e os lugares vazios para devolvê-las.

Para verificar se existe bicicleta dispon´ıvel em uma esta¸cão, o aluno deve selecionar no mapa esta¸cão desejada e clicar nela. Um box se abrirá, como indicado na figura 5.9,

(46)

34 mostrando a capacidade da esta¸c˜ao e a quantidade de bicicletas dispon´ıveis para retirada.

Figura 5.9: Mapa com bicicletas dispon´ıveis

Ainda na interface do mapa, é poss´ıvel calcular a rota entre a posi¸cão atual do usuário e uma esta¸cão selecionada. Basta clicar em uma esta¸cão e em seguida no botão ”Tra¸car Rota”.

O feedback sobre a qualidade das bicicletas é importante para o funcionamento do sistema. Para facilitar a manunte¸cão, criamos uma tela para o usuário dar feedback sobre problemas encontrados nas bicicletas . A interface pode ser verificada na imagem 5.10. Nessa tela, das funcionalidades listadas no Cap´ıtulo 3, foi conclu´ıdo o requisito funcional FR04.

5.3.2 Interface Administrativa

O projeto contempla protótipos de interfaces administrativas para ilustrar o que pode ser feito pelo web server RESTfull que foi desenvolvido. Foi desenvolvida uma tela para análise de histórico, aonde o responsável pela admnistra¸cão poderá selecionar um aluno pela matr´ıcula e consultar seu histórico de loca¸cões. Esta tela está indicada na figura 5.11. Como nas outras telas do sistema, esta foi desenvolvida para ser simples e funcional, para facilitar o seu uso, mesmo sem a necessidade de manual.

Desenvolvemos uma tela de cadastro de alunos. No futuro, o ideal é que o sistema tenha integra¸cão com o banco de dados do iduff para verificar se o aluno esta cadastrado, assim dispensando a tela de cadastro criada. Esta tela é demonstrada na figura 5.12.

(47)

35

Figura 5.10: Tela para relatar problemas com as bicicletas

5.4 An´

alise de requisitos atendidos

Foram definidos no cap´ıtulo 3 os requisitos que dirigiriam o desenvolvimento deste projeto. Durante o per´ıodo de evolu¸cão do projeto piloto alguns destes requisitos foram atendidos e outros, por conta do prazo, não puderam sem implementados. Os requisitos atendidos ao fim do desenvolvimento do projeto foram os seguintes, de acordo com o código de iden-tifica¸cão definido na Se¸cão 3.4: [FR01], [FR02], [FR03], [FR04], [FR05], [FR07], [FR08], [FR09], [FR10], [FR12], [FR13].

(48)

36

Figura 5.11: Tela com o Hist´orico de um aluno.

(49)

Cap´ıtulo 6

Conclus˜

ao

O trabalho teve como objeto de pesquisa a implementa¸c˜ao de sistema de compartilhamento de bicicletas para alunos da Universidade Federal Fluminense (UFF), com intuito de prover alternativa verde, sustent´avel e eficiente aos modais de transporte existentes.

O desenvolvimento do protótipo para este projeto teve um custo aproximado de 350 reais. Com isto estima-se que para desenvolvimento do projeto será necessário um investi-mento superior a 54600 reais, detalhados na tabela 6.1. O valor das bicicletas foi calculado com base numa licita¸cão de 2010 e reajustado com o ´ındice IPCA do per´ıodo[FNDE, 2017]. Partindo da problemática da mobilidade urbana sustentável, foram desenvolvidas aplica¸cões com objetivo de promover e facilitar o uso de bicicletas utilizando o sistema de bicicletas públicas. Utilizando como ponto de partida da pesquisa as principais solu¸cões em uso na atualidade, foram analisados os requisitos necessários para implememta¸cão de um sistema semelhante, porém adequado à realidade da UFF. Observando as caracter´ısti-cas de outras ferramentas já implementas e implantadas, citadas no Cap´ıtulo 2, percebe-se que há uma tendência a informatizar este modelo. Para tal, a utiliza¸cão das tecnologias atuais, como as citadas no Cap´ıtulo 4, plataforma e RFID são aspectos fundamentais

Descri¸cão Quantidade Valor Unitário Total Arduino Mega 13 100 1300 Componentes Eletrônicos 13 100 1300 Bicicletas 130 400 52000

Tabela 6.1: Tabela detalhada de custos para implanta¸c˜ao do projeto (em reais) 37

(50)

38 para a constru¸c˜ao de um sistema interativo de seguran¸ca e, ao mesmo tempo, atrativo ao p´ublico-alvo.

O intuito desta pesquisa é se tornar o primeiro passo na contru¸cão de um sistema para utiliza¸cão dos corpos discente e docente da UFF, promovendo melhores e mais efi-cientes deslocamentos entre os Campi. Com a inten¸cão de facilitar o prosseguimento do desenvolvimento, todo o código-fonte da aplica¸cão se encontra dispon´ıvel para download pelo link: https://github.com/vrempto/BikeUFF.

Em trabalhos futuros, seria interessante concluir a implementa¸cão de todo o sis-tema, realizando testes de campo com usuários, para conhecer melhor o impacto sobre o usuário final e ser capaz de moldar o conjunto funcionalidades de forma atrativa e funcional para o corpo discente da UFF.

(51)

Gloss´

ario

API Application Programming Interface - É um conjunto de rotinas e padrões estabele-cidos por um software para a utiliza¸cão das suas funcionalidades por aplicativos que não pretendem envolver-se em detalhes da implementa¸cão do software, mas apenas usar seus servi¸cos.. 11

DAO - É um padrão de projetos que permite criar as classes de dados independentemente da base de dados ser modelada de forma relacional ou não relacional. Qualquer acesso aos dados que deseja-se fazer deve ser através das classes DAO.. 12

IDE - Integrated Development Environment. E um conjunto de ferramentas que tra-´ balham de forma integrada para auxiliar no desenvolvimento de programas.. 20, 21

IoT - Internet of Things. É um conceito tecnológico em que todos os objetos da vida cotidiana estariam conectados à internet, agindo de modo inteligente e sensorial.. 20, 31

SGBD - Sistema de Gerenciamento de Banco de Dados. ´E um conjunto de programas de software que permite aos usu´arios criar, editar, atualizar, armazenar e recuperar dados em tabelas de banco de dados.. 11, 12

(52)

40

Siglas

API Application Programming Interface. 11 DAO Data Access Object. 11

IoT Internet of Things. 20, 31

NFC Near Field Communication. 21, 25 REST Representational State Transfer. 22, 23

RFID Radio Frequency Identification. 6, 18, 23, 26, 30, 31, 37 SGBD Sistema de Gerenciamento de Banco de Dados. 11, 12 UFF Universidade Federal Fluminense. 2, 22, 37, 38

(53)

Referˆ

encias Bibliogr´

aficas

[Arduino, 2017a] Arduino (acessado em: 16 de mar¸co de 2017a). Arduino mega. Dispo-n´ıvel em: https://www.arduino.cc/en/Main/arduinoBoardMega.

[Arduino, 2017b] Arduino (acessado em: 20 de junho de 2017b). What is arduino? Dis-pon´ıvel em: https://www.arduino.cc/en/Guide/Introduction.

[ESP8266, 2017] ESP8266 (acessado em: 16 de mar¸co de 2017). Esp8266 arduino core. Dispon´ıvel em: ttp://www.http://esp8266.github.io/Arduino/versions/2.3.0/.

[FNDE, 2017] FNDE (acessado em: 10 de junho de 2017). Preg˜ao eletrˆonico. Dispon´ıvel

em: http://www.fnde.gov.br/portaldecompras/index.php/component/phocadownload/category/22-pregoes-eletronicos?download=204:pe-040-2010-rp-pregao-e-extrato-das-atas.

[Jersey, 2017] Jersey (2013 (acessado em 15 de junho de 2017)). Jersey api. Dispon´ıvel em:https://jersey.github.io/documentation/latest/getting-started.html.

[Mobilicidade, 2017] Mobilicidade (acessado em: 10 de mar¸co de 2017)). Bikerio. Dispo-n´ıvel em: http://www.mobilicidade.com.br/bikerio.asp.

[MySQL, 2017] MySQL (acessado em: 11 de julho de 2017). Mysql workbench. Dispon´ıvel em: http://www.https://dev.mysql.com/doc/workbench/en/.

[Roberto Brauer di Renna, 2014] Roberto Brauer di Renna, Thiago Elias Bitencourt Cu-nha, T. C. C. (2014). Tutorial sobre sistema de controle de acesso rfid. Dispon´ıvel em:

http://www.telecom.uff.br/pet/petws/downloads/tutoriais/rfid/Tut Sistema Acesso RFID.pdf. [TreinaWeb, 2017] TreinaWeb (acessado em 26 de maio de 2017). Rest n˜ao ´e

simples-mente retornar json. Dispon´ıvel em: https://www.treinaweb.com.br/blog/rest-nao-e-simplesmente-retornar-json-indo-alem-com-apis-rest/.

(54)

42 [UFF, 2016] UFF (acessado em: 10 de novembro de 2016). Transporte da uff - busuff.