universidade federal rural do rio de janeiro instituto...
Post on 27-Jun-2020
4 Views
Preview:
TRANSCRIPT
UNIVERSIDADE FEDERAL RURAL DO RIO DE JANEIRO
INSTITUTO DE CIÊNCIAS EXATAS DEPARTAMENTO DE MATEMÁTICA
CURSO DE GRADUAÇÃO EM SISTEMAS DE INFORMAÇÃO
Mário Júnior Ribeiro da Costa
SMART CAMPUS UFRRJ: MAPAS INTERATIVOS PARA APOIO A MOBILIDADE
NO PAVILHÃO CENTRAL DO CAMPUS SEROPÉDICA
Seropédica - RJ
2017
MÁRIO JÚNIOR RIBEIRO DA COSTA
SMART CAMPUS UFRRJ: MAPAS INTERATIVOS PARA APOIO A MOBILIDADE
NO PAVILHÃO CENTRAL DO CAMPUS SEROPÉDICA
Monografia Apresentada à Banca Examinadora da UFRRJ, como requisito parcial para obtenção do título de Graduado em Sistemas de Informação, sob a orientação do professor André Luiz de Castro Leal, D. Sc.
Orientador: Prof(a) . Dr(a). ................................................
Seropédica - RJ
2017
FICHA CATALOGRÁFICA
Obs: Os detalhes de como fazer essa ficha serão fornecidos individualmente, na
Biblioteca Central da UFRRJ. O aluno (a) deve procurar a bibliotecária quando
terminar todo o texto da monografia. Lá irá obter o número/registro CDU
UNIVERSIDADE FEDERAL RURAL DO RIO DE JANEIRO INSTITUTO DE CIÊNCIAS EXATAS
DEPARTAMENTO DE MATEMÁTICA
COORDENAÇÃO DO CURSO DE GRADUAÇÃO EM SISTEMAS DE INFORMAÇÃO
Monografia “SMART CAMPUS UFRRJ: MAPAS INTERATIVOS PARA APOIO A MOBILIDADE NO PAVILHÃO CENTRAL DO CAMPUS SEROPÉDICA” apresentada e defendida por Mário Júnior Ribeiro da Costa matrícula 201039014-6 foi aprovada pela Banca Examinadora, com conceito “S”, recebendo o número _____________ .
Seropédica, 17 de Julho de 2017.
BANCA EXAMINADORA:
___________________________________ André Luiz de Castro Leal, D. Sc.
Orientador
__________________________________
Nilton José Rizzo, M. Sc.
__________________________________ Tiago Cruz de França, M. Sc.
SEROPÉDICA
2017
Dedico este trabalho aos meus
familiares, que muitos
incentivaram e colaboraram para
sua realização.
AGRADECIMENTOS
À Deus, pela saúde, orientação e força nos momentos de dificuldade.
Aos meus familiares pelo apoio e carinho recebido durante a elaboração deste
projeto.
Ao professor orientador André Castro, pelas valiosas contribuições durante a vida
acadêmica e para com este trabalho.
Agradeço aos meus amigos, que sempre estiveram ao meu lado nos momentos de
dúvida.
Enfim, agradeço a todos que de uma forma ou de outra contribuíram para a
elaboração deste trabalho.
“No meio da dificuldade encontra-se a
oportunidade. ”
(Albert Einstein)
RESUMO
Este trabalho objetivou reduzir a dificuldade daqueles relacionados com o campus Seropédica da UFRRJ em obter informações sobre estruturas funcionais do local através de uma solução de software. Após o estudo na área de tecnologia para desenvolvimento de aplicativos, optou-se por utilizar uma vertente de construção de aplicativos híbridos, cujo foco visa atender uma maior parcela de usuários de uma única vez e com um maior nível de manutenibilidade. Mediante tal necessidade, a solução do aplicativo proposto visou disponibilizar informações dos serviços oferecidos, inicialmente pelo pavilhão central (P1), diretamente na tela de smartphones e tablets dos usuários através do uso de mapas do Google Indoor Maps. Infelizmente, houveram impedimentos quanto à utilização desta tecnologia e uma solução baseada em sobreposição de imagens foi desenvolvida com intuito de reproduzir seu funcionamento. Desta maneira, as plantas baixas do prédio foram obtidas junto à equipe competente da universidade e alguns serviços, de exemplo, foram mapeados textualmente. Em seguida, um esquema de banco de dados foi desenhado, um serviço web foi criado para servir de ponte e disponibilizar as informações cadastradas na base de dados e, por fim, o aplicativo final foi desenvolvido refletindo sua facilidade e utilidade. Palavras-chave: google maps; mapeamento; estrutura funcional; aplicativos; mobile; ionic;
ABSTRACT
This work aimed to reduce the difficulty of those related to the campus of UFRRJ (Seropédica) in obtaining information about functional structures of the University through a software solution. After the study in the area of technology for application development has been done, the hybrid application building approach was chosen. Its focus is to serve a larger portion of users at a single time within a higher level of maintainability. Due to this needs, the proposed application solution aimed to provide information about the services offered, initially by the central pavilion (P1), directly on the user smartphones and tablets’ screens with the use Google Indoor Maps’ maps. Unfortunately, there were impediments to the use of this technology and an image-overlay solution was developed with the purpose of reproducing its operation. In this way, the floor plans of the building were obtained from the competent university team at first and some example services were text-mapped. Next, a database schema was designed, a web service was created to serve as a bridge and make available the information registered in the database, and finally, the final application was developed reflecting its ease and utility. Key-words: google maps; mapping; functional structure; apps; mobile; ionic
LISTA DE ABREVIATURAS
API Application Programming Language
CMS Content Managment System
CSS Cascading Style Sheets
ER Entidade e Relacionamento
JS JavaScript
JSON JavaScript Object Notation
HTML HyperText Markup Language
HTTP Hypertext Transfer Protocol
MVC Model-View-Controller
PHP PHP: Hypertext Preprocessor
P1 Pavilhão Central
SGBD Sistema Gerenciador de Banco de Dados
TS TypeScript
URL Uniform Resource Locator
UFRRJ Universidade Federal Rural do Rio de Janeiro
LISTA DE TABELAS
Tabela 1 - Estruturas funcionais do Pavilhão Central da UFRRJ ............................. 33
LISTA DE QUADROS
Quadro 1 - Detalhes sobre a tabela edificacao. ........................................................ 36 Quadro 2 - Detalhes sobre a tabela edificacao_tipo. ................................................ 37 Quadro 3 - Detalhes sobre a tabela comodo. ........................................................... 39 Quadro 4 - Detalhes sobre a tabela comodo_tipo. .................................................... 40 Quadro 5 - Detalhes sobre a tabela servico. ............................................................. 42
LISTA DE FIGURAS
Figura 1: Resumo das Atividades do Projeto ............................................................ 18 Figura 2: Planta baixa de uma casa .......................................................................... 22 Figura 3: Visão satélite da UFRRJ ............................................................................ 23 Figura 4: Visão interna do Shopping Estação BH utilizando Google Indoor ............. 24 Figura 5: Comparativo dos diferentes tipos de aplicações. ....................................... 26 Figura 6: Planta baixa do Pavilhão Central - Primeiro Pavimento ............................ 27 Figura 7: Planta baixa do Pavilhão Central - Segundo Pavimento ........................... 28 Figura 8: Planta baixa do Pavilhão Central - Terceiro Pavimento ............................. 28 Figura 9: Primeiro passo para cadastrar uma planta baixa no Google Indoor Maps 29 Figura 10: Segundo passo para cadastrar uma planta baixa no Google Indoor Maps
........................................................................................................................... 30 Figura 11: Terceiro passo para cadastrar uma planta baixa no Google Indoor Maps
........................................................................................................................... 30 Figura 12: Quarto passo para cadastrar uma planta baixa no Google Indoor Maps 31 Figura 13: Quinto passo para cadastrar uma planta baixa no Google Indoor Maps . 31 Figura 14 - Modelo ER do SmartCampus Maps ....................................................... 34 Figura 15 - Website do SmartCampus, página inicial. .............................................. 44 Figura 16 - Página de Login do Painel Administraivo do SmartCampus .................. 45 Figura 17 - Página Inicial do Painel Administrativo do SmartCampus ...................... 46 Figura 18 - Tela de listagem de Edificações do SmartCampus Maps ...................... 47 Figura 19 - Passo a passo para cadastro de novo tipo de edificação ....................... 48 Figura 20 - Cadastro de nova edificação .................................................................. 49 Figura 21 - Obtenção de latitude e longitude via Google Maps ................................ 50 Figura 22 - Cadastro de novo cômodo ...................................................................... 51 Figura 23 - Lista de Serviços cadastrados ................................................................ 52 Figura 24 - Cadastro de novo serviço ....................................................................... 52 Figura 25 - Trecho do retorno do endpoint de edificações ........................................ 53 Figura 26 - Trecho do retorno do endpoint de cômodos ........................................... 54 Figura 27 - Trecho do retorno do endpoint de serviços ........................................... 55 Figura 28 - Trecho do retorno do endpoint NearMe .................................................. 56 Figura 29 - Trecho do retorno do endpoint NearMe - Primeiro andar ....................... 56 Figura 30 - Estrutura geral de arquivos SmartCampus Maps ................................... 58 Figura 31 - Estrutura das páginas do SmartCampus Maps ...................................... 60 Figura 32 - Estrutura dos 'providers' do SmartCampus Maps ................................... 61 Figura 33 - Tela inicial do SmartCampus Maps ........................................................ 62 Figura 34 - Tela inicial do SmartCampus Maps com menu expandido ..................... 62 Figura 35 - Tela de mapa do SmartCampus Maps ................................................... 63 Figura 36 - Tela de Mapa do SmartCampus Maps com serviço selecionado ........... 64 Figura 37 - Tela de Mapa do SmartCampus Maps com serviço selecionado e zoom
........................................................................................................................... 65 Figura 38 - Filtro de busca na tela de Mapa do SmartCampus Maps ....................... 66 Figura 39 - Tela de Mapa do SmartCampus Maps - segundo andar ........................ 67 Figura 40 - Tela de listagem de Serviços do SmartCampus Maps ........................... 68 Figure 41 - Tela de detalhes do Serviço do SmartCampus Maps ............................. 69
SUMÁRIO
1 INTRODUÇÃO ................................................................................................... 15 2 OBJTETIVO ....................................................................................................... 17 2.1 OBJETIVO GERAL ............................................................................................ 17 2.2 OBJETIVOS ESPECÍFICOS.............................................................................. 17 2.3 METODOLOGIA ................................................................................................ 18 2.4 TRABALHOS CORRELATOS ........................................................................... 19 3 FUNDAMENTAÇÃO TEÓRICA ......................................................................... 21 3.1 MAPEAMENTO DE ESPAÇOS FÍSICOS ......................................................... 21 3.2 GOOGLE MAPS E GOOGLE INDOOR MAPS ................................................. 22 3.3 SOFTWARE DE CÓDIGO ABERTO ................................................................. 25 3.4 DESENVOLVIMENTO MOBILE ........................................................................ 25 4 ARQUITETURA E DESENVOLVIMENTO ......................................................... 27 4.1 OBTENÇÃO DE PLANTAS BAIXAS ................................................................ 27 4.2 UPLOAD PARA GOOGLE MAPS INDOOR ..................................................... 29 4.2.1 LIMITAÇÕES SOBRE ESTE PROCESSO ...................................................... 32 4.3 MAPEAMENTO DE ESPAÇOS FÍSICOS E FUNCIONAIS ............................... 33 4.4 MODELOS DO BANCO DE DADOS PROPOSTO ........................................... 34 4.5 ESTRUTURA WEB DO SMARTCAMPUS ........................................................ 43 4.5.1 WEB SITE SMARTCAMPUS ........................................................................... 43 4.5.2 PAINEL ADMINISTRATIVO DO SMARTCAMPUS ......................................... 44 4.5.3 API DO SMARTCAMPUS ................................................................................ 53 4.6 IMPLEMENTAÇÃO DA APLICAÇÃO COM IONIC 2 ........................................ 57 4.6.1 TIPO DE ABORDAGEM ESCOLHIDA ............................................................ 57 4.6.2 CODIFICAÇÃO ................................................................................................ 57 5 CONCLUSÃO .................................................................................................... 70 6 REFERÊNCIAS BIBLIOGRÁFICAS .................................................................. 72
15
1 INTRODUÇÃO
Encontrar os espaços físicos e estruturas funcionais na Universidade Federal
Rural do Rio de Janeiro (UFRRJ) nem sempre é uma tarefa fácil. Em parte, porque
no campus localizado na cidade de Seropédica, interior do Rio de janeiro, eles estão
em grande número e dispersos em vários pontos do campus. Soma-se a isso, o fato
deles estarem distribuídos de forma não convencional, sem endereço padrão como
estamos acostumados a encontrar no dia a dia nos municípios.
Devido a este motivo, viu se a necessidade de melhorar a localização e
locomoção interna do campus Seropédica que é reconhecido como o maior da
América Latina em extensão ocupando uma área de 3.024 hectares, num conjunto
arquitetônico com 131.346 m² de área construída e está localizado no Km 7 da
Rodovia BR 465 (ORTRANTO, 2000) e contendo cerca de 12.327 alunos
matriculados (UFRRJ, 2010).
Com a facilidade de acesso a internet nos dias de hoje e o mercado de
celulares crescendo cada vez mais (LECHETA, 2009), se tornou necessária à
criação de uma aplicação que auxilie os alunos a se localizarem no campus dando-
os autonomia para se locomoverem com rapidez e precisão.
É objetivo deste trabalho o estudo de tecnologias web e mobile, para
disponibilizar informações do Campus Seropédica da UFRRJ através de mapas
interativos, com o objetivo de facilitar a localização de prédios, pavimentos, salas e
demais dependências físicas para alunos, docentes e demais público que trafegam
pelo campus universitário. Isso será possível através da disponibilização de
informações sobre serviços oferecidos dentro de cada prédio, por exemplo, o
pavilhão central (P1), diretamente na tela do smartphone ou tablet de cada usuário.
A solução desenvolvida tem como base aplicações já existentes que
disponibilizam informações de suas composições físicas como a Universidade de
Harvard 1 e a Universidade de Indiana 2 nos Estados Unidos. Porém, além de
disponibilizar informações das dependências físicas, essa proposta visa adicionar a
funcionalidade de listar estruturas funcionais e serviços administrativos da UFRRJ,
de uma forma mais rápida e precisa.
Esta ideia é um passo inicial para criação de um portal maior que visa acoplar
diversos outros serviços como Bus Tracking, Mural de Eventos, Notícias do Campus,
1 https://map.harvard.edu 2 http://map.iu.edu/iub/
16
Classificados entre outros baseando-se na proposta da Universidade de Trento3 na
Itália dando assim uma filosofia de Smart Campus ou campus inteligente, que possa
estar presente virtualmente no cotidiano das pessoas que transitam pelo campus.
Quanto à Metodologia empregada, registra-se que, na fase de Investigação,
pesquisas bibliográficas na área foram feitas com intuito de identificar problemas
semelhantes e também as possíveis e melhores soluções para o problema tratado.
Também, exercendo o papel de aluno, foi observado no dia a dia do campus a
necessidade de melhorias no campus referente à falta de informações por parte da
UFRRJ. Informações estas de cunho básico, por exemplo, falta de placas e/ou
balcão de informações no campus que impactam direto na qualidade da mobilidade
do campus.
Dessa maneira, o presente trabalho aborda uma das necessidades elencados
pela pesquisa que é a da construção de um software que oriente a mobilidade no
campus para permitir uma melhor localização de espaços físicos e serviços. Como
há a necessidade de consultas a partir da mobilidade, o software foi construído para
uso em smartphones. Porém, para aqueles que utilizem a seguintes versões
mínimas de sistema operacional: Android 4.4 ou superior, iOS 8 ou superior e
Windows Phone 10 ou superior.
Para tanto, no Capítulo 2, são apresentados os objetivos deste trabalho, tanto
gerais quanto específicos. O capítulo 3 discorre sobre as tecnologias disponíveis e
teorias sobre mapeamento de espaços físicos necessárias para o entendimento da
solução de software construída. No capítulo 4 é apresentado em detalhes o
processo de construção da solução de software criada, assim como seu escopo e
suas limitações. O capítulo 5 é reservado para as conclusões finais e considerações
sobre esse trabalho.
3 http://www.smartcampuslab.it
17
2 OBJETIVO
Nesta seção serão apresentados os objetivos do trabalho realizado, tantos os
gerais quanto os específicos.
2.1 OBJETIVO GERAL
O presente trabalho tem como objetivo construir uma solução de software
para fornecer informações do Campus Seropédica da UFRRJ, através de mapas
interativos que possam ser acessados por smartphones ou tablets para facilitar a
localização de espaços e estruturas funcionais4 dentro do campus. Vale a pena
ressaltar que o presente trabalho tem o foco de mapear, a critério de demonstração
de viabilidade da ferramenta, limitação de escopo e maior importância perante aos
outros prédios, somente o pavilhão central (P1) da UFRRJ por esse concentrar o
maior volume de estruturas funcionais (serviços) da universidade.
2.2 OBJETIVOS ESPECÍFICOS
• Mapeamento de espaços físicos e estruturas funcionais disponíveis no
pavilhão central;
• Aquisição de mapas de espaços físicos com setores responsáveis;
• Estudo das tecnologias de criação de mapas visuais e sua disponibilização
para acesso interativo em quiosques, smartphones e web;
• Mapeamento dos espaços físicos e suas estruturas funcionais para desenho
dos modelos de mapas;
• Criação de mapas;
• Estabelecimento de buscas textuais de espaços físicos e estruturas
funcionais para servirem de opção de pesquisa de localização;
• Descrição de pelo menos dois cenários de uso, um por pesquisa diretamente
pelos modelos do mapa e outro por busca textual;
• Implementação do aplicativo SmartCampus Maps;
• Implementação da plataforma web SmartCampus para disponibilização e
suporte ao aplicativo SmartCampus Maps;
• Desenvolvimento de monografia de final de curso.
4 Serviços disponíveis no campus como Coordenadorias, Departamentos, Recursos Humanos, Residência estudantil, Matrícula, Hospital Veterinário, Biblioteca, etc.
18
2.3 METODOLOGIA
A estratégia adotada na metodologia da pesquisa é de definir pequenas
atividades que atinjam objetivos específicos identificados para que o objetivo geral
seja atingido. A metodologia baseia-se nas macro atividades de realização de
pesquisa bibliográfica para melhor entendimento da área, mapeamento da UFRRJ,
modelagem de funcionamento da aplicação e implementação do software.
A execução desse trabalho foi dividida nas seguintes atividades e pode ser
vista na Figura 1.
Figura 1: Resumo das Atividades do Projeto
Fonte: elaborado pelo autor
De forma mais detalhada, as atividades podem ser descritas como segue:
19
• A1 – Estudar projetos na área de mapas: Realizar um levantamento
bibliográfico sobre projetos voltados para criação de mapas em geral.
• A2 – Estudar tecnologias disponíveis para implementação de mapas:
Realizar uma pesquisa a fim de identificar as melhores tecnologias existentes
nos dias de hoje para criação de mapas.
• A3 – Mapeamento de espaços físicos e estruturas funcionais
disponíveis: Realizar o levantamento através de pesquisa e observação dos
espaços físicos e estruturas funcionais da UFRRJ.
• A4 – Organização dos espaços físicos e estruturas funcionais para
desenho dos modelos de mapas: Organizar de maneira estruturada as
informações coletadas no passo A3.
• A5 – Estabelecimento de esquema para buscas textuais dos espaços
físicos e estruturas funcionais: Criar tags e associá-las ao espaços físicos
e estruturas funcionais a fim de permitir uma busca textual com palavras
chaves.
• A6 – Diagramação: Criar diagrama para ilustrar o funcionamento da
aplicação.
• A7 – Definição da tecnologia a ser utilizada: Definir com base na atividade
A2 e A6 as tecnologias que serão utilizadas para o desenvolvimento da
aplicação.
• A8 – Codificação: Fase de criação da aplicação e de suas dependências.
• A9 – Verificação e Validação: Fase de integração, onde o código criado será
verificado e validado utilizando dados reais.
2.4 TRABALHOS CORRELATOS
Ao realizar algumas pesquisas sob utilização prática do Google Indoor Maps,
pode-se encontrar alguns trabalhos como o projeto de “mapeamento de um Hospital
Universitário Irlandês para visitantes e pacientes” (Designing and Publishing Indoor
Maps for Patients and Visitors in an Academic Teaching Hospital) que tem como
20
objetivo aumentar a experiência de, aproximadamente, 600 usuários que
frequentemente ficam ‘perdidos’ dentro do hospital, resultando em uma perda de
18h/dia de trabalho da equipe de gestão que precisam ficar orientando os visitantes
(RYDER, 2015).
Outro trabalho correlato é encontrado como estudo de caso feito pela própria
equipe do Google Indoor Maps no Mission College5, um Colégio Público de Santa
Clara, Califórnia, US. Segundo o estudo, “ao criar o mapa interno dos prédios do
campus, a diretoria poderia reduzir custos com impressão de mapas das salas e
realocar equipes de informação para outros setores”. Também é dito pelo Petter
Anning, diretor de Marketing e Relações Públicas do Colégio, “Isso dá aos alunos
um nível de independência. Porque ajusta em tempo real aos locais reais, as
pessoas podem sempre encontrar onde estão. Não somente entre qualquer edifício
ou andar em particular, mas também dentro de todo o campus...". (ANNING, 2012).
Outros trabalhos de sucesso também estão disponíveis na página web de
casos de estudo6 do Google Indoor e abrangem lojas de departamentos, colégios,
aeroportos, shoppings e hotéis.
Todavia, nota-se que não foram encontrados explicitamente trabalhos que
envolvem a construção de aplicativos híbridos com utilização do Google Indoor
Maps para facilitar a obtenção de informações e proporcionar melhor orientação
dentro do campus universitário.
5 http://www.missioncollege.edu/ 6 https://maps.google.com/help/maps/indoormaps/casestudies.html
21
3 FUNDAMENTAÇÃO TEÓRICA
3.1 MAPEAMENTO DE ESPAÇOS FÍSICOS
Entende-se por mapeamento a aplicação do processo cartográfico sobre
uma coleção de dados ou informações, com vistas à obtenção de uma
representação gráfica da realidade perceptível, comunicada a partir da associação
de símbolos e outros recursos gráficos que caracterizam a linguagem cartográfica
(IBGE, 2015).
O mapeamento de espaço físico geralmente é feito pelo profissional
engenheiro agrimensor e cartográfico através de um processo de levantamento e
representação da superfície terrestre utilizando imagens aéreas ou de satélites, bem
como da locação de um projeto de engenharia da planta para o terreno (SILVA &
GESSER, 2017).
Atualmente, o mapa é um elemento fundamental para a compreensão de um
fenômeno espacial; para o conhecimento, ocupação e exploração organizada, justa
e sustentável da superfície física da Terra. Mapas, mais do que instrumentos de
segurança nacional, são hoje instrumentos de desenvolvimento econômico e social
sustentável. (SILVA & GESSER, 2017).
Planta baixa é um desenho técnico esquemático feito a partir do corte
horizontal a 1,5m a partir da base do edifício. Nela é possível visualizar o ambiente
como se estivesse olhando de cima, sem o telhado. Nesta representação, é possível
mostrar a dimensão da área construída, largura e comprimento dos elementos
internos e externos, relacionar a disposição recomendada para itens de
acabamento, etc. (PAIXÃO, 2017). Um prédio residencial, por exemplo, possui
várias camadas de planta. Sendo a planta baixa o nível de acesso e as outras
plantas representando os outros andares. A visualização e o entendimento de um
projeto são facilitados pelo uso das maquetes e dos cortes.
22
Figura 2: Planta baixa de uma casa
Fonte: Google Images7
A UFRRJ não possui as plantas baixa de seus edifícios disponibilizadas
online, portanto, para a realização deste trabalho de monografia, a planta baixa do
prédio principal (P1) foi obtida diretamente com a Divisão de Obras da Prefeitura
Universitária.
3.2 GOOGLE MAPS E GOOGLE INDOOR MAPS
Google Maps é uma aplicação de localização e navegação utilizando mapas
que pode ser utilizado tanto em computadores quanto em dispositivos móveis. A
aplicação provê direções passo-a-passo até um determinado destino utilizando
visões 2D ou 3D dos satélites. O Google Maps também disponibiliza informações
sobre trânsito e visões fotográficas reais das ruas através da funcionalidade
chamada Street View.
A primeira versão da aplicação para dispositivos móveis utilizando o sistema
Android foi disponibilizada em 2008, estando logo em seguida disponível para outras
plataformas móveis incluindo Symbian, BlackBerry e Palm. Os mapas do aplicativo
da Apple também são alimentados pelos dados do Google Maps. O aplicativo do
7 Disponível em http://www.tudoconstrucao.com/wp-content/uploads/2015/03/Planta-Baixa.jpg. Acesso em jun.
2017.
23
Google Maps utiliza localização GPS do dispositivo e também a conexão Wi-Fi para
determinar a geolocalização do usuário.
Diante das funcionalidades apresentadas pelo Google Maps, podemos acessar
a aplicação via navegador ou celular, como pode ser visto na figura 2, e perceber
que já existe o mapeamento externo da UFRRJ. Porém, o foco deste trabalho de
monografia foi mapear os espaços físicos internos da UFRRJ através da ferramenta
Google Indoor Maps.
Figura 3: Visão satélite da UFRRJ
Fonte: Google Maps8
O Google Indoor Maps é uma ferramenta que oferece mapas detalhados de
edifícios relevantes. No Brasil já é possível visualizar informações detalhadas de
alguns aeroportos, por exemplo, o Aeroporto de Brasília - Juscelino Kubitschek,
Aeroporto do Rio de Janeiro - Santos Dumont e Aeroporto de São Paulo/Congonhas.
Também é possível ver detalhadamente shoppings como o Shopping Estação BH
em Belo Horizonte - MG, alguns estádios de futebol e teatros. A figura 3 mostra a
visão do Google Indoor Maps no celular, nela é possível identificar nomes das lojas,
sua localização, e através do menu inferior esquerdo é possível mudar a visão entre
os diferentes andares disponíveis.
8 Disponível em https://www.google.com.br/maps/place/Pavilh%C3%A3o+Central+-+P1/@-22.7651298,-
43.6891924,416m/data=!3m1!1e3!4m12!1m6!3m5!1s0x9955d8251e415f:0x613581ba0a2b68bd!2sUniversidade+Federal+Rural+do+Rio+de+Janeiro!8m2!3d-22.7684765!4d-43.6850354!3m4!1s0x0:0x73847052edfbed05!8m2!3d-22.7648544!4d-43.6898133?hl=pt-BR. Acesso em: jan. 2017.
24
Figura 4: Visão interna do Shopping Estação BH utilizando Google Indoor
Fonte: print screen do Google Maps do Iphone 6
A Google explica que esta funcionalidade permite "aos utilizadores
visualizarem mapas interiores detalhados, encontrarem pontos de interesse
relevantes no interior e obterem informação relevante útil". Os mapas interiores vão
estar disponíveis na versão "web" e "mobile" do Google Maps, aparecendo
automaticamente sempre que o utilizador fizer uma ampliação de um local com
mapa incluído. Através da ferramenta, vão estar identificados os pontos de interesse
de cada local, que podem ser, por exemplo, "as lojas e secções presentes num
centro comercial", "o número de cada sala em cada edifício da universidade" ou os
terminais Multibanco "disponíveis num determinado local". "Sempre que um edifício
tiver mais de um piso, o utilizador pode selecionar o andar bastando clicar no
número do piso a que pretende aceder", é dito.
Para que seja feito o mapeamento interno de uma estrutura é necessário que
se faça o upload da planta baixa do mesmo nos seguintes formatos: JPG, PNG,
PDF, BMP ou GIF.
25
3.3 SOFTWARE DE CÓDIGO ABERTO
Software de código aberto significa que o código fonte do mesmo está
disponível para o público fazer melhorias, customizações e redistribuição (OPEN
SOURCE INITIATIVE, 2015). O código fonte é a parte do software que a maioria dos
usuários nem sequer veem. Principalmente são os usuários programadores que
fazem modificações no código fonte da aplicação.
Alguns exemplos notáveis são o Linux, o ambiente gráfico KDE, o compilador
GCC, o servidor web Apache, o OpenOffice.org, o navegador web Firefox, entre
muitos outros (CAMPOS, 2006).
Muitas pessoas preferem software de código aberto porque eles têm mais
controle sobre aquele tipo de software. Um exame minucioso pode ser feito no
código-fonte para garantir que aplicação funcione como o esperado. Os usuários
que não são programadores muitas das vezes se beneficiam de software de código
aberto porque eles podem usar o determinado software para qualquer finalidade.
3.4 DESENVOLVIMENTO MOBILE
Um dos desafios encontrados nesse trabalho foi escolher qual ferramenta
utilizar para se construir a solução de software. Nesta seção, são mostradas quais
ferramentas estão disponíveis para uso e qual foi utilizada para o desenvolvimento
do resultado deste trabalho de monografia.
Aplicações nativa são aquelas que podem ser encontradas nas lojas de
aplicativos dos principais sistemas operacionais de celulares, com Android, IOS e
Windows Phone. Normalmente desenvolvidas utilizando linguagens de programação
de nível superior, como o Java para o Android, Objective-C para iOS, ou C# para
Windows Phone (da Silva et al. 2014). Ao utilizar o ambiente nativo significa que
você terá acesso a todos os recursos, por exemplo, câmera, GPS, bússola,
acelerômetro, etc. do hardware onde o aplicativo está sendo instalado.
Possivelmente, o melhor desempenho é obtido utilizando uma solução nativa. No
entanto, isso também significa que você precisará manter uma versão do seu código
para cada plataforma que você decida disponibilizar seu software, diminuindo assim
a capacidade de manutenção e tornando mais difícil qualquer um contribuir para o
projeto. Aplicações web são aquelas feitas utilizando tecnologias como: HTML5,
CSS e JavaScript, especialmente desenhadas para que se adaptem e funcionem
nos diversos tipos de tamanhos de telas e navegadores. Este é um ponto positivo
26
pois as aplicações não estão presas à plataforma de sistema operacional. Porém,
não tem acesso aos recursos do hardware e não funcionam off-line. O último tipo de
aplicação a ser apresentado é o híbrido. Um aplicativo híbrido é praticamente todo
construído utilizando HTML5 e JavaScript. Como uma aplicação nativa, o aplicativo
híbrido é executado dentro de um componente nativo do dispositivo. Esses
aplicativos, tipicamente, envolvem o conteúdo HTML dentro de uma espécie de
navegador, funcionando em tela cheia, sem a barra de endereço visível ou outras
funcionalidades embutidas do navegador [da Silva et al. 2014]. As aplicações
híbridas utilizam o JavaScript como ponte de comunicação com o sistema e
conseguem acessar recursos do hardware como GPS e câmera. Assim como as
aplicações nativas, elas também podem ser disponibilizadas nas lojas de aplicativos
e, geralmente, não precisam de internet para que funcionem. A figura 5 apresenta
um comparativo entre as diferentes formas ou ferramentas de desenvolvimento de
aplicativos móveis, demonstrando em quais quesitos cada tipo de aplicação oferece
suporte.
Figura 5: Comparativo dos diferentes tipos de aplicações.
Fonte: Prezotto e Boniati 2014
Utilizando-se do background mobile apresentado, o Ionic é um framework
licenciado pelo MIT9 para criar aplicativos móveis híbridos, que foi feito e está sendo
mantido pela mesma empresa, Drifty. O Ionic também é um módulo do Node.js que
ajuda com o processo de criação, construção e empacotamento de aplicativos
híbridos. O Ionic permite que os desenvolvedores utilizem de suas habilidades em
9 http://web.mit.edu/
27
Angular.JS, HTML5 e CSS3 para a construção de aplicativos mais bonitos e de alto
desempenho.
4 ARQUITETURA E DESENVOLVIMENTO
4.1 OBTENÇÃO DE PLANTAS BAIXAS
Para obter sucesso no projeto SmartCampus Maps, primordialmente foi
necessário obter a planta baixa do P1 diretamente com a Divisão de Obras da
Prefeitura Universitária, pois a UFRRJ não possui as plantas baixa de seus edifícios
disponibilizadas online.
A figura 6 abaixo representa a planta baixa do primeiro pavimento do P1, onde
existem salas de aulas (Ex: itens 17,33), um auditório (Ex: item 58/59/60), banheiros
(Ex: itens 9, 11 e 57), escadas localizadas nas 4 extremidades, o Hall principal (Ex:
item H), a Coordenadoria de informática (Ex: itens 26,27,28), entre outros.
Figura 6: Planta baixa do Pavilhão Central - Primeiro Pavimento
Fonte: Divisão de Obras da UFRRJ10
As plantas do segundo e terceiro pavimento podem ser vistas na figura 7 e 8 abaixo.
10 http://www.ufrrj.br/pu/paginas/divisao_obras/divisao_obras.html
28
Figura 7: Planta baixa do Pavilhão Central - Segundo Pavimento
Fonte: Divisão de Obras da UFRRJ11
Figura 8: Planta baixa do Pavilhão Central - Terceiro Pavimento
Fonte: Divisão de Obras da UFRRJ12
As plantas baixas foram obtidas em formato PDF e possuindo uma escala de
1/200. Os arquivos originais estarão disponíveis no CD entregue junto à este
trabalho para a UFRRJ.
11 http://www.ufrrj.br/pu/paginas/divisao_obras/divisao_obras.html 12 http://www.ufrrj.br/pu/paginas/divisao_obras/divisao_obras.html
29
4.2 UPLOAD PARA GOOGLE INDOOR MAPS
O processo de upload dos arquivos para o Google Maps se dá pela criação
de uma conta do Google e em seguida é necessário acessar, via navegador web, a
seguinte URL (https://maps.google.com/floorplans/find)13.
Figura 9: Primeiro passo para cadastrar uma planta baixa no Google Indoor Maps
Fonte: print screen do primeiro passo para Upload de planta baixa no Google Maps
A figura 9 acima representa o primeiro passo tomado para fazer o upload da
planta do Pavilhão Central da UFRRJ. É necessário procurar por um determinado
endereço e marca-lo para uso clicando no botão verde (Use this building).
Após a seleção é necessário informar um rótulo (label), que aparecerá como
opção selecionável quando acessar o mapa via celular. Também é necessário
informar qual o andar real que a planta representa. Em seguida, existe um campo
para que seja selecionado o arquivo que contém a planta baixa no computador.
Esses passos podem ser vistos na figura abaixo.
13 Note que o conteúdo a ser cadastrado deve estar de acordo com as políticas de direitos autorais do Google.
30
Após
Figura 6: Segundo passo para cadastrar uma planta baixa no Google Indoor Maps
Fonte: print screen do segundo passo para Upload de planta baixa no Google Maps
Após o término do upload, a seguinte tela da figura 10 é apresentada. Nela é
necessário ajustar e posicionar a imagem da planta baixa com o prédio já existente
na interface do Google Maps. Em seguida é necessário salvar o alinhamento
clicando no botão (Save Alignment).
Figura 7: Terceiro passo para cadastrar uma planta baixa no Google Indoor Maps
Fonte: print screen do terceiro passo para Upload de planta baixa no Google Maps
31
O último passo, figura 12, é a confirmação das informações inseridas. Nessa
tela é possivel verificar tudo que foi cadastrado, e caso tenha algo errado, é possivel
voltar e fazer alterações. Caso tudo esteja correto, só é preciso clicar no botão de
enviar (Submit for processing) e aguardar o processamento da planta baixa.
Figura 8: Quarto passo para cadastrar uma planta baixa no Google Indoor Maps
Fonte: print screen do quarto passo para Upload de planta baixa no Google Maps
A última imagem, figura 13, representa a tela de confirmação do envio com
sucesso para processamento. Um e-mail deve ser enviado pela equipe do Google
Indoor Maps para a caixa de e-mail da conta em qual se foi feito o upload assim que
as plantas estiverem disponíveis no sistema principal do Google Indoor Maps.
Figura 9: Quinto passo para cadastrar uma planta baixa no Google Indoor Maps
Fonte: print screen do quinto passo para Upload de planta baixa no Google Maps
32
O mesmo processo foi repetido para o cadastramento das plantas baixa do
segundo e terceiro pavimento do Pavilhão Central da UFRRJ.
4.2.1 LIMITAÇÕES SOBRE ESTE PROCESSO
Um dos limites para o desenvolvimento do trabalho se diz respeito à demora
para processar as plantas baixas e disponibilizá-las por parte da equipe do Google
Maps. Apesar de várias tentativas de contato via e-mail, nenhuma resposta foi obtida
quanto à aceleração do processo de disponibilização da planta baixa que gira em
torno de 6 meses. Ao buscar ajuda no fórum oficial, somente um contribuidor, cujo
codinome é Treebles 14 , respondeu minhas dúvidas e confirmou 15 a demora no
processamento. Treebles afirmou que o processo pode demorar vários meses e que
o foco da equipe do Google está em mapear shoppings, estádios e aeroportos.
Um segundo fator limitante foi em relação às políticas do Google. Somente o
Business Owner, ou dono do negócio, pode fazer o upload da planta baixa. O dono
do negócio é quem registra e verifica a determinada empresa no Google através do
Google Meu Negócio16. Como o Pavilhão Central não é registrado, e/ou, não é um
negócio, o mesmo não pode ser registrado e verificado por mim pois cabe à
universidade realizar tal processo.
Note que, com a impossibilidade de trabalhar com o Google Indoor Maps, foi
necessário buscar soluções que simulariam o funcionamento do mesmo. Ou seja,
simularia a visão interna de uma determinada edificação. Identificou-se que havia a
possibilidade de adicionar uma camada (layer) com a imagem real da planta baixa
exatamente acima da edificação já cadastrada no Google Maps. Este processo é
chamado pelo Google de overlay17 e tile overlay18.
Para obter um carregamento correto da imagem acima da edificação de acordo
com o zoom visualizado é necessário que se tenha diversas imagens das plantas
baixas em escalas19 diferentes. Portanto, para efetuar tais recortes das imagens foi
14 https://goo.gl/mFBCTk 15 https://goo.gl/uHHSQx 16 https://www.google.com.br/business/ 17 https://developers.google.com/maps/documentation/javascript/examples/overlay-simple?hl=pt-br 18 http://www.microimages.com/documentation/TechGuides/78googleMapsStruc.pdf 19 https://developers.google.com/maps/documentation/android-api/tileoverlay
33
necessário a utilização do software MapTiler20, um software com licença paga e
gratuita, porém a segunda opção tem recursos limitados. Por exemplo, limitações
que não permitem o recorte de imagens para zoom menor que 17 e maior que 23.
Consequentemente, o aplicativo do SmartCampus Maps só consegue exibir imagens
da planta baixa caso o zoom da tela esteja entre 17 e 23.
Esta foi a solução encontrada que mais se assemelhou ao funcionamento do
Google Indoor Maps, e pode ser uma opção para aqueles que também encontraram
impedimentos quanto às politicas do Google em outros trabalhos relacionados a
este.
4.3 MAPEAMENTO DE ESPAÇOS FÍSICOS E FUNCIONAIS
O processo de mapeamento dos espaços físicos e estruturas funcionais foi
executado de duas maneiras distintas. Primeiramente, foi efetuado uma visita
pessoal ao prédio principal da UFRRJ com intuito de identificar e validar visualmente
os espaços físicos com aqueles disponibilizados nas plantas baixas. Em seguida, na
segunda etapa foram buscadas informações sobre as estruturas funcionais e
serviços oferecidos no prédio principal através do site da Instituição21.
Estruturas Funcionais Localização Tags Secretaria de Assuntos Acadêmicos e Registro Geral – DAARG
Sala 96 DAARG;
Pró-Reitoria de Assuntos Financeiros
Sala 80 PROAF;
Divisão de Estágio Sala 61 DEST; Departamento de Matemática Sala 80 DEMAT; Coordenadoria de Informática Salas 28, 27, 26 COINFO; Seção de Venda de Tíquetes Sala 35 TICKETS; RU Seção de Bolsas Sala 37 BOLSAS; Núcleo de Apoio à Administração da Pesquisa – NAAP
Sala 116 NAAP;
Divisão Multidisciplinar de Assistência ao Estudante - DIMAE
Salas 34, 35 DIMAE;
Centro de Memória Sala 7 MEMORIA;
Tabela 1 - Estruturas funcionais do Pavilhão Central da UFRRJ
Fonte: elaborado pelo autor
A tabela acima foi montada representando o mapeamento direto efetuado com
alguns exemplos de estruturas funcionais disponíveis no prédio principal da UFRRJ.
20 https://www.maptiler.com/ 21 www.ufrrj.br
34
Para o presente trabalho, foram listados 10 serviços que servirão de exemplo e
insumo para testes de funcionalidade da solução proposta.
4.4 MODELOS DO BANCO DE DADOS PROPOSTO
Diante das estruturas funcionais apresentadas, partiu-se para a idealização
de como transformar tais informações em algo palpável, ou seja, que estivesse
associado à uma estrutura física. Para que fosse possível associar tais informações
às estruturas físicas dentro do Google Maps, foi necessário identificar alguns pontos
de padronização de informação geográfica definidos pelo Google Maps. Por
exemplo, definição para identificar curvas de níveis através de algarismos numéricos
inteiros.
Tendo o conhecimento das estruturas funcionais apresentadas na seção
anterior, dos padrões mínimos de estrutura de informação definidos pelo Google e
com o auxilio da ferramenta MySQLWorkbench22, foi possível diagramar um modelo
relacional, cuja arquitetura pode ser visualizada na figura 14.
Figura 10 - Modelo ER do SmartCampus Maps
22 https://dev.mysql.com/doc/workbench/en/
35
Fonte: elaborado pelo autor
Foram identificadas 5 entidades, comumente chamadas de tabelas, que se
relacionam entre si, sendo elas: edificacao, edificacao_tipo, comodo, comodo_tipo e
servico. Cada entidade possui um conjunto particular de propriedades que a
descreve chamado “atributos”, e pode ou não estar relacionada umas com as outras.
Em adição, cada atributo possui um conjunto de valores possíveis denominado
“domínio” (MEIRA, 1997). A seguir, os detalhes da cada tabela serão descritos
através dos quadros abaixo.
Edificacao
Atributos Descrição Regra de negócio
Exemplos de domínios possíveis
id_edificacao Identificador único de uma determinada edificação.
É um campo obrigatório cujo valor deve ser numérico, inteiro e positivo.
Qualquer número de 1 a 4294967295.
fk_edificacao_tipo Identificador externo referente ao tipo de edificação
É um campo obrigatório cujo valor deve ser numérico, inteiro e positivo.
Qualquer número de 1 a 4294967295.
nome Nome amigável da edificação.
É um campo obrigatório cujo valor pode ser números, símbolos ou letras. Possui uma limitação de 45 caracteres.
“Pavilhão Central”
resumo Descrição curta da edificação.
É um campo obrigatório cujo valor pode ser números, símbolos ou letras. Possui uma limitação de 255 caracteres.
“O pavilhão central é o prédio principal da UFRRJ.”
nick Um apelido único para a edificação. Visa facilitar a buscar textual ao invés do identificador numérico.
É um campo obrigatório cujo valor pode ser números ou letras. Possui uma limitação de 45 caracteres. Normalmente não possui acentos e são separados por “-” para
“P1”
36
melhor indexação.
descricao Descrição longa para a edificação.
É um campo opcional cujo valor não restringe nenhum tipo de caractere.
“O pavilhão central é o prédio principal da UFRRJ e fica localizado logo à frente da entrada principal”
data_criacao Data de criação da edificação no banco de dados.
É um campo opcional cujo valor é um texto composto de Data e Hora.
“2017-01-23 10:00:00”
deleted Representa se a edificação foi marcado como apagada.
É um campo opcional, numérico, inteiro e limitado de 0 a 1.
1
google_place_id Identificador da edificação (local) no sistema do Google Maps, se houver.
É um campo obrigatório cujo valor pode ser números, símbolos ou letras. Possui uma limitação de 255 caracteres.
“ChIJN1t_txtz”
latitude Latitude correspondente da edificação.
É um campo obrigatório, numérico decimal com tamanho de 10 caracteres. Possui um precisão de 6 casas decimais.
-22.768471
longitude Longitude correspondente da edificação.
É um campo obrigatório, numérico decimal com tamanho de 10 caracteres. Possui um precisão de 6 casas decimais.
-43.687229
Quadro 1 - Detalhes sobre a tabela edificacao.
Fonte: elaborado pelo autor
A primeira entidade, vide quadro 1, como o próprio nome já diz refere-se à
uma edificação qualquer no mundo real. Para a realidade da UFRRJ, a edificação
pode representar qualquer construção física dentro do campus, por exemplo,
prédios, estacionamentos, casas. Serão utilizadas coordenadas geográficas (latitude
e longitude) para mapear o espaço físicos dentro do Google Maps. Tais
coordenadas servem para identificar a localização da edificação a nível externo
perante às outras edificações no Google Maps, permitindo assim expandir a busca
não somente por serviços, mas também por edifícios na aplicação apresentada.
37
Edificacao_tipo Atributos Descrição Regra de
negócio Exemplos de domínios possíveis
id_edificacao_tipo Identificador único de um determinado tipo de edificação.
É um campo obrigatório cujo valor deve ser numérico, inteiro e positivo.
Qualquer número de 1 a 4294967295.
nome Nome amigável do tipo de edificação.
É um campo obrigatório cujo valor pode ser números, símbolos ou letras. Possui uma limitação de 45 caracteres.
“Prédio”
nick Um apelido único para o tipo de edificação. Visa facilitar a buscar textual ao invés do identificador numérico.
É um campo obrigatório cujo valor pode ser números ou letras. Possui uma limitação de 45 caracteres. Normalmente não possui acentos e são separados por “-” para melhor indexação.
“predio”
data_criacao Data de criação do tipo de edificação no banco de dados.
É um campo opcional cujo valor é um texto composto de Data e Hora.
“2017-01-23 10:00:00”
deleted Representa se o tipo de edificação foi marcado como apagada.
É um campo opcional, numérico, inteiro e limitado de 0 a 1.
1
Quadro 2 - Detalhes sobre a tabela edificacao_tipo.
Fonte: Elaborado pelo autor
A segunda entidade exibida no quadro 2 é a edificacao_tipo. Tem como
principal função representar os domínios possíveis de edificações que existem no
mundo real. Por exemplo, podem ser cadastrados como valores para esta entidade
os prédios, estacionamentos, galpões, torres, etc. Vemos que os atributos são
similares aos da entidade edificacao, dispensando assim maiores explicações.
Cabe, neste momento, descrever o relacionamento entre as duas entidades, sendo
representado pelo traço pontilhado entre os dois elementos da figura 14. Diante da
38
imagem, nota-se que uma edificação qualquer tem um e somente um tipo associado
à mesma, que está mapeado na tabela edificacao_tipo. O segundo relacionamento
está na entidade comodo, que será descrita em seguida.
Comodo
Atributos Descrição Regra de negócio
Exemplos de domínios possíveis
id_comodo Identificador único de um determinado cômodo.
É um campo obrigatório cujo valor deve ser numérico, inteiro e positivo.
Qualquer número de 1 a 4294967295.
fk_edificacao Identificador externo referente à qual edificação o cômodo pertence.
É um campo obrigatório cujo valor deve ser numérico, inteiro e positivo.
Qualquer número de 1 a 4294967295.
fk_comodo_tipo Identificador externo referente ao tipo de cômodo.
É um campo obrigatório cujo valor deve ser numérico, inteiro e positivo.
Qualquer número de 1 a 4294967295.
nome Nome amigável do cômodo.
É um campo obrigatório cujo valor pode ser números, símbolos ou letras. Possui uma limitação de 45 caracteres.
“Sala 96”
nick Um apelido único para o cômodo. Visa facilitar a buscar textual ao invés do identificador numérico.
É um campo obrigatório cujo valor pode ser números ou letras. Possui uma limitação de 45 caracteres. Normalmente não possui acentos e são separados por “-” para melhor indexação.
“sala-96”
latitude Latitude correspondente do cômodo.
É um campo obrigatório, numérico decimal com tamanho de 10 caracteres. Possui um precisão de 6 casas decimais.
-22.768471
longitude Longitude correspondente do cômodo
É um campo obrigatório, numérico decimal
-43.687229
39
com tamanho de 10 caracteres. Possui um precisão de 6 casas decimais.
extra_info Informações extras que pode ser úteis para o cômodo.
É um campo opcional cujo valor não restringe nenhum tipo de caractere.
data_criacao Data de criação do cômodo no banco de dados.
É um campo opcional cujo valor é um texto composto de Data e Hora.
“2017-01-23 11:00:00”
deleted Representa se o cômodo foi marcado como apagado.
É um campo opcional, numérico, inteiro e limitado de 0 a 1.
0
google_place_id Identificador do cômodo (local) no sistema do Google Maps, se houver.
É um campo obrigatório cujo valor pode ser números, símbolos ou letras. Possui uma limitação de 255 caracteres.
“ChIJN1t_txtz”
google_floor Representa o andar de alocação do cômodo na edificação.
É um campo obrigatório, numérico, inteiro e positivo para este trabalho.
2
tags São palavras chaves do cômodo.
É um campo opcional cujo valor pode ser números, símbolos ou letras. Possui uma limitação de 255 caracteres.
“sala96;p1;secretaria”
Quadro 3 - Detalhes sobre a tabela comodo.
Fonte: Elaborado pelo autor
Assim como nas outras entidades, para o comodo também existe identificador
único, descrições básicas e referências para as chaves identificadoras de outras
entidades (edificacao e comodo_tipo). Alguns novos itens são apresentados, sendo
eles extra_info, responsável por representar de maneira textual quaisquer
informações extras do cômodo. Tags, responsável por representar palavras chaves
para critérios de buscas. E, por último, o google_floor que também faz parte de
gearreferenciamento sendo importante para identificar curvas de níveis, altitudes ou
andares dos cômodos.
40
A quarta entidade a ser descrita é a comodo_tipo, cujos atributos são
idênticos aos atributos da entidade edificacao_tipo, exceto o nome da chave
idenfiticadora. Esta entidade tem função de representar os domínios possíveis de
cômodos que existem no mundo real. Por exemplo, podem ser cadastrados como
valores para esta entidade: salas de aula, salas comuns, auditórios, banheiros, etc.
Os detalhes da entidade podem ser vistos no quadro 4 abaixo.
Comodo_tipo Atributos Descrição Regra de
negócio Exemplos de domínios possíveis
id_comodo_tipo Identificador único de um determinado tipo de cômodo.
É um campo obrigatório cujo valor deve ser numérico, inteiro e positivo.
Qualquer número de 1 a 4294967295.
nome Nome amigável do tipo de cômodo.
É um campo obrigatório cujo valor pode ser números, símbolos ou letras. Possui uma limitação de 45 caracteres.
“Prédio”
nick Um apelido único para o tipo de cômodo. Visa facilitar a buscar textual ao invés do identificador numérico.
É um campo obrigatório cujo valor pode ser números ou letras. Possui uma limitação de 45 caracteres. Normalmente não possui acentos e são separados por “-” para melhor indexação.
“predio”
data_criacao Data de criação do tipo de cômodo no banco de dados.
É um campo opcional cujo valor é um texto composto de Data e Hora.
“2017-01-23 10:00:00”
deleted Representa se o tipo de cômodo foi marcado como apagada.
É um campo opcional, numérico, inteiro e limitado de 0 a 1.
1
Quadro 4 - Detalhes sobre a tabela comodo_tipo.
Fonte: Elaborado pelo autor
41
Diante dos dados apresentados para essas duas entidades, pode-se explicar
o relacionamento entre as mesmas. Primordialmente, como mencionado acima,
pode perceber que a entidade comodo possui uma chave estrangeira que referencia
a entidade edificacao. Portanto, ao observar os traços que ligam as duas entidades
na figura 14, lê-se que uma edificação possui um ou mais cômodos, e que, um
cômodo possui uma e somente uma edificação. Também é observado que um
cômodo possui um tipo, assim como uma edificação também possui um tipo. Ainda
mais, um terceiro relacionamento é identificado entre comodo e servico,
explicitamente caracterizado por um cômodo possui um ou mais serviços.
Acrescentando-se, a última entidade servico da figura 14 é apresentada e
representada pelo quadro 5 abaixo. Tal qual seu próprio nome já diz, esta entidade
representa quaisquer serviços, administrativos ou não, oferecidos pela UFRRJ e
mapeados na aplicação apresentada.
Servico
Atributos Descrição Regra de negócio
Exemplos de domínios possíveis
id_servico Identificador único de um determinado serviço.
É um campo obrigatório cujo valor deve ser numérico, inteiro e positivo.
Qualquer número de 1 a 4294967295.
fk_comodo Identificador externo referente ao qual cômodo o serviço pertence.
É um campo obrigatório cujo valor deve ser numérico, inteiro e positivo.
Qualquer número de 1 a 4294967295.
nome Nome amigável do serviço.
É um campo obrigatório cujo valor pode ser números, símbolos ou letras. Possui uma limitação de 45 caracteres.
“Divisão de Estágio”
resumo Descrição curta do serviço.
É um campo obrigatório cujo valor pode ser números, símbolos ou letras. Possui uma limitação de 255 caracteres.
“A divisão de estágio é responsável por tratar assuntos de estágio externos e internos dos alunos da UFRRJ .”
nick Um apelido único para o serviço.
É um campo obrigatório cujo
“dest”
42
Visa facilitar a buscar textual ao invés do identificador numérico.
valor pode ser números ou letras. Possui uma limitação de 45 caracteres. Normalmente não possui acentos e são separados por “-” para melhor indexação.
descricao Descrição longa para o serviço.
É um campo opcional cujo valor não restringe nenhum tipo de caractere.
“A divisão de estágio é responsável por tratar assuntos de estágio externos e internos dos alunos da UFRRJ. Mais detalhes podem ser consultados através da página web http://ufrrj.br/dest ou através dos telefones de contato 1234-4566”
extra_info Informações extras que pode ser úteis para o serviço.
É um campo opcional cujo valor não restringe nenhum tipo de caractere.
data_criacao Data de criação do serviço no banco de dados.
É um campo opcional cujo valor é um texto composto de Data e Hora.
“2017-01-23 11:00:00”
deleted Representa se o serviço foi marcado como apagado.
É um campo opcional, numérico, inteiro e limitado de 0 a 1.
0
google_place_id Identificador do serviço (local) no sistema do Google Maps, se houver.
É um campo obrigatório cujo valor pode ser números, símbolos ou letras. Possui uma limitação de 255 caracteres.
“ChIJN1t_txtz”
disponivel Representa se o serviço está disponível ou não.
É um campo obrigatório, numérico, inteiro e limitado de 0 a 1.
1
tags São palavras chaves do serviço.
É um campo opcional cujo valor pode ser números, símbolos ou letras. Possui uma limitação de 255 caracteres.
“sala61;p1;dest;estagio”
Quadro 5 - Detalhes sobre a tabela servico.
43
Fonte: Elaborado pelo autor
Seus atributos são similares à entidade edificacao, pertencendo a um cômodo
como pode ser visto pela presença do identificador externo fk_comodo. Possui
também um item que não presente nas outras entidades, disponível, que ao ser
definido como 0 ou 1 caracteriza se o serviço está ou não disponível.
Para concluir esta seção, diante do modelo de dados construído na
ferramenta MySQLWorkbench foi possível efetuar a criação das tabelas dentro do
Sistema Gerenciador De Banco de Dados, ou SGBD, escolhido (MySQL) e,
posteriormente cadastrar novos registros através do painel administrativo criado
para auxiliar e gerir as informações que alimentam a aplicação do SmartCampus
Maps.
4.5 ESTRUTURA WEB DO SMARTCAMPUS
Além da construção de um aplicativo que visa aumentar a qualidade de
mobilidade no campus, uma estrutura mais complexa teve que ser criada para dar
suporte ao mesmo. Alguns componentes criados, configurando a estrutura, foram:
um website responsivo de apresentação expondo a ideia geral do que é o
SmartCampus, um painel administrativo online para gerir as informações de maneira
amigável, tanto do website do SmartCampus quanto do aplicativo SmartCampus
Maps, e também uma API para servir de ponte de comunicação entre o aplicativo e
o website. Tais itens serão descritos em mais detalhes nas seções a seguir.
4.5.1 WEB SITE SMARTCAMPUS
O website23 servirá para apresentar a ideia geral do SmartCampus mencionada
na introdução deste trabalho. Ainda, será possível publicação de notícias, eventos,
seminários de utilidade pública geral do campus Seropédica e também descrições e
links dos futuros aplicativos e/ou serviços web parceiros que farão parte do
SmartCampus.
23 http://smarcampus.mariojr.com.br
44
Figura 11 - Website do SmartCampus, página inicial.
Fonte: elaborado pelo autor
Na figura 15 é possível identificar os elementos básicos contidos no website do
SmartCampus. Para o mesmo, foi utilizado um layout24 HTML5 responsivo com
licença grátis25 simplista, composto de um topo onde a identidade da aplicação é
exibida, seguido por um menu horizontal de fácil acesso e um banner com uma
chamada para detalhes sobre o aplicativo Maps, do SmartCampus.
4.5.2 PAINEL ADMINISTRATIVO DO SMARTCAMPUS
Diferente do website de apresentação do SmartCampus, para se ter acesso ao
painel de administrativo 26 do portal SmartCampus, é necessário ter um usuário
previamente cadastrado no sistema pelo administrador. De posse de um e-mail e
senha válidos, é possível efetuar o login no painel administrativo como pode ser
visto na figura 16.
24 https://html5up.net/arcana 25 https://html5up.net/license 26 http://adminsmartcampus.mariojr.com.br/admin/login
45
Figura 12 - Página de Login do Painel Administraivo do SmartCampus
Fonte: elaborado pelo autor
Para o website do painel administrativo, foi escolhido um outro layout27 que se
diferencie do website de apresentação, que podemos chamar de back-end e front-
end respectivamente. O layout do back-end também é responsivo, fazendo uso de
tecnologias web como HTML5, CSS3 e JavaScript para facilitar o acesso através de
qualquer dispositivo (computadores, tablets ou celulares). Para a construção do
back-end, foram utilizadas tecnologias open-source de desenvolvimento web
havendo PHP 28 como linguagem e processamento principal, MySQL 29 como
tecnologia de acesso e armazenamento de dados e Zend Framework 330 junto de
uma arquitetura MVC31 como framework de desenvolvimento web.
Após efetuado o login com sucesso, a página principal a ser exibida é
representada na figura 17. Alguns elementos são listados no menu lateral esquerdo,
sendo eles o item de Backup que é responsável por efetuar um backup completo ou
parcial da base de dados. Seguido pelo item Cache, responsável por permitir a
exclusão de consultas pré-armazenadas no servidor, que são criadas a fim de evitar
acesso constante a base de dados e aumentar o tempo de resposta do servidor e
aplicação. Subsequentemente, os itens CMS e BgTask aparecem na lista, sendo
27 https://adminlte.io/ 28 https://secure.php.net/manual/pt_BR/intro-whatis.php 29 https://www.mysql.com/ 30 https://framework.zend.com/learn 31 https://tableless.com.br/mvc-afinal-e-o-que/
46
eles responsáveis por gerenciar o conteúdo do front-end, assim como possíveis
tarefas que podem ser agendadas para executar em segundo-plano. Por fim, e mais
importante, vem o item Maps, responsável por gerenciar as Edificações, Cômodos e
Serviços.
Figura 17 - Página Inicial do Painel Administrativo do SmartCampus
Fonte: elaborado pelo autor
Ao clicarmos na seção Maps três opções são listadas para acesso. Ao
acessarmos a seção Edificações no menu do painel administrativo nos deparamos
inicialmente com as edificações já cadastradas32, como poder ser visto na figura 18
abaixo.
32 Caso não haja registros cadastrados na base de dados, uma mensagem de “Nenhum item cadastrado” é exibida.
47
Figura 18 - Tela de listagem de Edificações do SmartCampus Maps
Fonte: elaborado pelo autor
Duas opções são oferecidas acima da listagem de edificações cadastradas,
sendo elas a opção de cadastrar uma nova edificação e a opção de visualizar os
tipos de edificações cadastrados no sistema. Para que seja efetuado um novo
cadastro de edificação é obrigatoriamente necessário que se tenha um tipo
cadastrado. Portanto, é necessário acessar o link “Ver tipos”, e seguir os passos
indicados na figura 19.
48
Figura 19 - Passo a passo para cadastro de novo tipo de edificação
Fonte: elaborado pelo autor
Em seguida, é necessário inserir uma nova edificação clicando no link ‘Novo’
exibido na figura 18. Na tela apresentada deve-se inserir as informações solicitadas
mapeadas para a entidade edificacao explicada anteriormente na seção “Modelo de
Dados Proposto”. Note que, na figura 20, os tipos de edificação disponíveis são os
mesmos cadastrados no passo anterior.
49
Figura 20 - Cadastro de nova edificação
Fonte: elaborado pelo autor
A figura acima representa o cadastro do Pavilhão de Aulas Práticas no sistema.
Alerta-se que o mesmo não possui planta baixa registrada na aplicação, portanto, o
cadastro fica apenas à critério de exemplo. Para obtenção das coordenadas de
latitude e longitude, foi utilizado o Google Maps via navegador web, identificado
visualmente a edificação e colocando um marcador em cima da mesma. Quando se
executa esse processo, a interface do Google Maps nos retornar as informações de
latitude e longitude tanto na URL quanto na parte esquerda da tela, como pode ser
visto na figura 21 abaixo.
50
Figura 21 - Obtenção de latitude e longitude via Google Maps
Fonte: print screen da aplicação do Google Maps
Continuando, será exemplificado o processo de cadastro de um novo cômodo.
Deve-se acessar o menu principal e selecionar o item “Cômodos”. Similarmente à
tela exibida para Edificações, uma lista também é exibida com os cômodos
cadastrados no sistema. Duas opções também são exibidas, a de cadastro de novo
cômodo e de visualização de tipos de cômodos. Note que também é necessário o
cadastro de tipos de cômodos previamente ao cadastro de um cômodo, caso não
haja nenhum no sistema. Sendo assim, é necessário repetir os passos da figura 19,
entretanto, repete-se para um novo tipo de cômodo. Ao finalizar o cadastro do novo
tipo de cômodo cadastraremos um novo cômodo, que será referente à Seção de
Bolsas listada na tabela 1 deste projeto podendo ser vista na figura abaixo.
51
Figura 22 - Cadastro de novo cômodo
Fonte: elaborado pelo autor
Observar-se que também há referencia automática à entidade comodo_tipo
quando se abre a caixa de seleção denominada ‘Tipo’. Da mesma maneira acontece
na caixa de seleção denominada Edificação. Uma particularidade disponível no
cadastro de cômodo é a opção ‘Google Floor’ e ‘Tags’. O primeiro deve ser um
número que representa em qual andar o cômodo está alocado, e o segundo deve
ser uma lista com palavras-chaves separadas por vírgula. Ao término do cadastro o
novo cômodo é exibido na listagem de cômodos.
O último item que precisa ser cadastrado para o mínimo funcionamento da
aplicação é o serviço. Podemos visualizar os serviços disponíveis acessando o item
‘Serviços’ no menu lateral esquerdo. Após a listagem de serviços cadastrados,
clicamos no botão ‘Novo’ localizado na parte superior da listagem. O novo serviço à
ser cadastrado é associado ao cômodo 37 previamente inserido na etapa anterior. O
resultado do cadastro pode ser visto na figura 24.
52
Figura 23 - Lista de Serviços cadastrados
Fonte: elaborado pelo autor
Figura 24 - Cadastro de novo serviço
Fonte: elaborado pelo autor
Diante dos elementos cadastrados nessa seção é possível ter registros
mínimos suficiente para viabilizar o funcionamento da aplicação. Entretanto, os
mesmos precisam ser disponibilizados de alguma forma para acesso externo do site.
A seção a seguir descreve a abordagem utilizada para disponibilização dos dados.
53
4.5.3 API DO SMARTCAMPUS
Para viabilizar o acesso aos dados, foi utilizado uma estrutura de API baseada
em JSON (Javascript Object Notation). Um formato de serialização de dados legível
por humanos baseado em texto com especificação padronizada e parcialmente
descritivo. Foi desenvolvido por Douglas Crockford com o objetivo de representar
dados de uma maneira simples, leve e flexível através da redução na sobrecarga de
marcações comparado ao formato XML.
A API do SmartCampus está acoplada ao mesmo servidor e projeto do painel
administrativo do SmartCampus, porém não necessita de acesso via usuário e
senha. A API é simplista e não chega a ser considerada uma arquitetura RESTFul
completa, pois só faz uso de um dos verbos do protocolo HTTP, sendo ele o GET.
Possui URIs únicos para acesso de leitura aos dados da seção Maps do Painel
Administrativo, e são comumente chamadas de endpoints.
Em primeiro lugar vem o endpoint de acesso aos dados de edificações que
pode ser acessado através da seguinte URL
http://smartcampus.mariojr.com.br/api/maps/edificacoes. Para uma melhor
visualização, a consulta foi efetuada utilizando o programa Postman33, e o trecho do
resultado retornado pela aplicação poder ser visto na figura abaixo.
Figura 25 - Trecho do retorno do endpoint de edificações
33 https://www.getpostman.com/
54
Fonte: elaborado pelo autor
Observa-se que o retorno dos dados do endpoint de edificações traz uma lista
com todas as edificações cadastradas, sendo que, para cada item também é
retornando o nome e o nick do tipo associado. Isto é possível pois a consulta que
busca os dados na base é composta por um LEFT JOIN, termo utilizado para
retornar juntar dados de uma tabela que estão presentes em uma outra tabela,
identificando-os por chaves.
Continuando, o segundo endpoint disponível diz respeito aos cômodos
cadastrados no sistema. Com ele podemos obter informações dos cômodos assim
como informações da edificação ao qual o cômodo pertence. A figura 26 abaixo
exemplifica o trecho dos dados retornado pela aplicação através da URI
http://smartcampus.mariojr.com.br/api/maps/comodos .
Figura 26 - Trecho do retorno do endpoint de cômodos
Fonte: elaborado pelo autor
O próximo endpoint é responsável por disponibilizar informações sobre os
serviços cadastrados na aplicação. Vemos na figura 27 que todas as informações
relevantes a cada serviço são retornadas. Tais informações são o próprio nome,
resumo e descrição do serviço, o cômodo ao qual o serviço está alocado e o prédio
onde o serviço é oferecido.
55
Figura 27 - Trecho do retorno do endpoint de serviços
Fonte: elaborado pelo autor
Em adição aos três endpoints descritos, cabe afirmar que também existem
mais outros três endpoints para acesso direto ao recurso através de seu identificador
único. Ou seja, caso seja necessário acessar somente um determinado serviço,
pode-se utilizar a seguinte URI
http://smartcampus.mariojr.com.br/api/maps/servicos/{ID}, sendo {ID} o identificador
do serviço. De forma análoga, as URIs
http://smartcampus.mariojr.com.br/api/maps/edificacoes/{ID} e
http://smartcampus.mariojr.com.br/api/maps/comodos/{ID} são para acesso direto à
um item de edificação e cômodo, respectivamente.
Por fim, um endpoint de acesso aos serviços localizados dentro de um
determinado raio, denominando NearMe, está disponível através da URI
http://smartcampus.mariojr.com.br/api/maps/nearme . Para que se faça uso deste
endpoint é necessário informar alguns parâmetros obrigatórios e adicionais via URL.
Os dois primeiros parâmetros são lat e lng, abraviações para latitude e longitude.
Caso não sejam enviados, uma mensagem de “Erro” é retornada. O terceiro
parâmetro, radius, é opcional e define o raio de busca. Deve ser enviado em
quilômetros e por padrão, caso nenhum valor seja enviado, seu valor é definido para
0.5 (500 metros). O quarto parâmetro, floor, também opcional, refere-se ao andar
que se deseja buscar os serviços. Por padrão, a busca é efetuada em todos os
andares disponíveis.
56
Por exemplo, utilizando as latitudes -22.7672547 e longitude -43.688018, que
são a localização de um ponto central do campus da UFRRJ relativamente perto do
Pavilhão Central, podemos acessar o endpoint NearMe através da URI
http://smartcampus.mariojr.com.br/api/maps/nearme?lat=-22.7672547&lng=-
43.688018 e obter como trecho de resposta o conteúdo da figura abaixo.
Figura 28 - Trecho do retorno do endpoint NearMe
Fonte: elaborado pelo autor
Nota-se que 5 serviços foram encontrados para os parâmetros enviados.
Caso necessitemos restringir a busca e listar somente serviços do primeiro andar,
podemos enviar o parâmetro floor = 1. A figura abaixo representa o retorno da
consulta http://smartcampus.mariojr.com.br/api/maps/nearme?lat=-
22.7672547&lng=-43.688018&floor=1.
Figura 29 - Trecho do retorno do endpoint NearMe - Primeiro andar
Fonte: elaborado pelo autor
57
Conclui-se que a interface de apoio para busca de informações dos elementos
de dados do SmartCampus Maps supri as necessidades básicas e viabilizou a
construção do aplicativo mobile que visa ajudar na informação e locomoção interna
dentro do campus da UFRRJ.
4.6 IMPLEMENTAÇÃO DA APLICAÇÃO COM IONIC 2
4.6.1 TIPO DE ABORDAGEM ESCOLHIDA
Não há uma abordagem que é completamente melhor do que a outra para a
implementação de um projeto mobile, a melhor dependerá do que se está tentando
obter como resultado final.
A abordagem utilizando aplicação nativa é mais adequada quando o acesso a
recursos nativos de cada plataforma é muito importante para a aplicação. Também
está incluso e explicito que o desenvolvimento terá maiores custos por exemplo,
com orçamentos separados para desenvolvedores em iOS e Android.
A abordagem web responde positivamente à quase todos os pontos negativos
da abordagem nativa. Uma vantagem de aplicações móveis baseadas na web é a
mesma funciona em diversos dispositivos de diversos sistemas operacionais.
Também, não há uma necessidade de atualizar a aplicação constantemente caso
uma nova versão do sistema operacional seja disponibilizada.
Finalmente, a abordagem híbrida é melhor usada quando se quer obter
resultados rápidos e precise-se fazer atualizações frequentes na aplicação. Com ela,
é possível extrair somente os pontos positivos das outras duas abordagens citadas.
Este projeto se enquadra na última abordagem, pois é necessário haver uma
certa agilidade no desenvolvimento e após sua implementação, a possibilidade de
inserção de novas informações sobre serviços e prédios com atualização em tempo
real. Também visa atender o maior número de usuários com diferentes sistemas
operacionais através do desenvolvimento multiplataforma oferecido pelo HTML5,
CSS5 e JavaScript.
4.6.2 CODIFICAÇÃO
A solução de software descrita nesta seção foi escrita utilizando o kit de
desenvolvimento de software (SDK) híbrido, Ionic, em sua versão 234. O ambiente de
34 http://ionicframework.com/
58
desenvolvimento foi composto de um MacBook com sistema operacional macOS
Sierra versão 10.12.5 e Visual Studio Code35 versão 1.12 como editor de textos.
Para se iniciar o desenvolvimento com Ionic foi preciso seguir o tutorial de
instalação básica disponível no website36 do produto. O SDK Ionic está disponível
para as principais versões de sistemas operacionais do mercado, Windows, MacOS
e Linux. Basicamente, para começar a utilizá-lo foi necessário instalar o Node.JS37,
e em seguida instalar o Ionic através do comando ‘npm install –g ionic cordova’.
Diante dos detalhes básicos apresentados seguimos para a apresentação da
estrutura de arquivos do SmartCampus Maps através da figura abaixo.
Figura 30 - Estrutura geral de arquivos SmartCampus Maps
Fonte: elaborado pelo autor
35 https://code.visualstudio.com/ 36 https://ionicframework.com/docs/intro/installation/ 37 https://nodejs.org/en/
59
Perante a imagem da figura 30 podemos observar que a estrutura do projeto é
extensa. Porém, a maior parte do desenvolvimento é feita dentro da pasta ‘src’. Note
que, caso seja necessário obter maiores detalhes sobre cada componente de
configuração do projeto é possível acessar a documentação no site oficial do Ionic.
O primeiro item do nosso diretório de desenvolvimento é o ‘src/app’. Esta
pasta é onde os "componentes raiz" do aplicativo estão localizados. Existem os
arquivos main.dev.ts e main.prod.ts que são responsáveis pelo processo de
inicialização do aplicativo. O main.dev.ts é ativo no modo de desenvolvimento e
main.prod.ts deve ser usado somente no ambiente de produção.
Em seguida vem o diretório ‘src/assets’, local onde é armazenado os arquivos
de recursos estáticos. Por exemplo, arquivos de imagens, áudios e vídeos que pode
ser utilizado no projeto.
A pastas ‘src/components’ e ‘src/pages’ são responsáveis por armazenar cada
página que existe no aplicativo. Por exemplo, caso seja necessário criar uma página
de login, será preciso criar uma pasta chamada login (ou qualquer outro nome
exclusivo) e, em seguida, armazenar o modelo de login (.html), o arquivo de
definição de classe de login (.ts) e o arquivo de definição de estilo de login (.scss)
dentro dessa pasta. O Ionic CLI pode ser usado para automatizar este processo
através da inserção do comando ‘ionic generate [page|component] login’ na linha de
comando, ou terminal para aqueles que utilizam sistemas baseado em UNIX38.
Para o aplicativo do SmartCampus Maps foram criadas 4 páginas, sendo elas a
página principal (src/pages/home), a página de listagem de serviços (src/pages/list),
a página do mapa (src/pages/map) e a página de visualização de um determinado
serviço (src/components/view-service). A estrutura pode ser vista na figura abaixo.
38 http://www.ppgia.pucpr.br/~laureano/puc_2007/asu/sistema_historico.html
60
Figura 31 - Estrutura das páginas do SmartCampus Maps
Fonte: elaborado pelo autor
Continuando, a pasta ‘src/providers’ vide figura 32 foi criada para armazenar
componentes que fazem acesso externo ao aplicativo e proveem dados para o
mesmo. Por exemplo, o arquivo ‘src/provides/connectivity-service.ts’ é responsável
por identificar se o aplicativo está conectado ou não a Internet, assim como o
arquivo ‘src/providers/google-maps.ts’ é responsável por carregas as informações do
Google Maps, adicionando pinos/marcadores, por exemplo. Por último, mas não
menos importante, vem o arquivo ‘src/providers/locations.ts’ cuja função é acessar
os diversos endpoints da API do SmartCampus mencionada anteriormente.
61
Figura 32 - Estrutura dos 'providers' do SmartCampus Maps
Fonte: Elaborado pelo autor
A pasta ‘src/theme’ contém as configurações globais de cores e estilos das
páginas. Acrescentando, a pasta ‘src/validators’ foi criada para armazenar validação
de dados criadas além das existentes oferecidas pela SDK do Ionic. Validações
estas são, por exemplo, não permitir inserir número negativo para o raio de busca e
só permitir inserir valor de 1 a 3 para buscar serviços por andar.
Por último, o arquivo ‘src/index.html’ possui algumas configurações mínimas e
links para alguns arquivos de biblioteca de JS. O aplicativo Ionic 2 procura por tags
específicas que podem estar presentes dentro do corpo do index.html para iniciar os
componentes visuais do projeto.
Diante das apresentações dos arquivos é possível mostrar, através da figura
abaixo, o resultado obtido com após o processo de codificação e construção
(building). Primeiramente é exibindo a tela principal do aplicativo visível nas três
versões de sistemas operacionais para smartphones, sendo elas Android, IOS, e
Windows Phone.
62
Figura 33 - Tela inicial do SmartCampus Maps
Fonte: elaborado pelo autor
A tela principal é composta por uma descrição de página no topo precedida de
um ícone para abrir o menu lateral e uma descrição simples no restante da página. A
imagem a seguir demostra as opções disponíveis ao abrir o menu lateral.
Figura 34 - Tela inicial do SmartCampus Maps com menu expandido
Fonte: elaborado pelo autor
O primeiro item do menu é ‘Home’, onde mediante a clique direciona o usuário
para a página inicial da aplicação. Em seguida vem o item ‘Mapa’ e ‘Serviços’,
63
responsáveis por exibir o mapa da UFRRJ e listar os serviços oferecidos pela
UFRRJ, respectivamente.
Figura 35 - Tela de mapa do SmartCampus Maps
Fonte: elaborado pelo autor
Ao navegarmos para a seção Mapa através do menu nos deparamos com a
visão da figura 35. Como o foco deste trabalho é mapear as estruturas físicas e
funcionais do P1, ao término de carregamento do mapa o aplicativo foca e posiciona
a visão automaticamente em cima da edificação. Observa-se de modo geral que
nesta tela temos a opção de filtrar por andar ou raio através das caixas de seleção
correspondentes. Também é observado que dois pinos, em vermelho, estão
posicionados e representam dois serviços diferentes.
Para sabermos informações básicas de um serviço podemos clicar em cima do
marcador em vermelho que em seguida uma janela se abrirá, como pode ser visto
na figura abaixo.
64
Figura 36 - Tela de Mapa do SmartCampus Maps com serviço selecionado
Fonte: elaborado pelo autor
Para termos uma melhor visão da localização é necessário aproximar a imagem
clicando nos ícones de ‘+’ no canto inferior da tela. Após a execução deste processo,
o resultado é apresentado na figura 37 abaixo.
65
Figura 37 - Tela de Mapa do SmartCampus Maps com serviço selecionado e zoom
Fonte: elaborado pelo autor
Através da figura 37 podemos observar a localização exata cadastrada ao
darmos zoom no aplicativo. O serviço selecionado foi o Seção de bolsas e está
localizado na sala 37 do P1. As informações que aparecem são referentes ao título e
resumo da entidade servico já descrita nas seções anteriores.
A seguir, será exemplificado as funções de filtro disponíveis. Ao clicar na caixa
de seleção do andar e raio obtermos o resultado mostrado na figura 38 abaixo.
66
Figura 38 - Filtro de busca na tela de Mapa do SmartCampus Maps
Fonte: elaborado pelo autor
Selecionado o andar de número 2, temos dois novos serviços filtrados 39
representados por dois pinos em vermelho. Também é notável através da imagem
39 que os pinos existentes antes do filtro foram removidos e que a imagem referente
ao primeiro andar também foi removida, sendo adicionada a imagem do andar
correspondente. Portanto, ao clicarmos no pino que está mais acima da tela é
exibido as informações do Departamento de Matemática, localizado na sala 80 do
P1.
39 Não se efetuou filtro por um raio maior que 500 metros pois não faria sentido mostrar serviços fora do foco
deste trabalho.
67
Figura 39 - Tela de Mapa do SmartCampus Maps - segundo andar
Fonte: elaborado pelo autor
Prosseguindo, foi efetuado o acesso à página de listagem de serviços através do
menu. Está página foi criada com intuído de dar opção de busca textual aos
serviços, pois ter que ficar abrindo cada pino da página do mapa pode ser um pouco
desconfortável. A figura abaixo exemplifica o momento em que se acessa a lista de
serviços e em seguida se efetua um filtro através da caixa de busca disponibilizada
na parte superior de tela.
68
Figura 40 - Tela de listagem de Serviços do SmartCampus Maps
Fonte: elaborado pelo autor
A listagem de serviços é composta pelo nome e distância. Esta distância é
referente ao ponto central mencionado na explicação do endpoint NearMe, cuja
latitude é -22.7672547 e longitude -43.688018. Esta funcionalidade foi pensada,
exemplificada, e poderá ser implementada no futuro para permitir calcular a distância
entre a posição do GPS do dispositivo móvel e o determinado serviço.
Ao clicar em um determinado serviço da lista, a página carregada, figura 41,
exibe as informações detalhadas do mesmo.
69
Figure 41 - Tela de detalhes do Serviço do SmartCampus Maps
Fonte: elaborado pelo autor
Nesta tela de detalhes do serviço exemplificada pela figura acima pode-se
observar informações completas do serviço qualquer selecionado. No caso, o
serviço selecionado foi o Seção de Bolsas. É visível que também é exibida a
informação de localização diretamente no mapa, a fim de facilitar a vida do usuário
final do aplicativo.
Por sua vez, este capítulo teve como objetivo concretizar os objetivos propostos
por este aplicativo. Apresentando sua arquitetura, os requisitos necessários ao seu
funcionamento, e os detalhes da aplicação. Em seguida, serão discutidos os
detalhes finais.
70
5 CONCLUSÃO
Como foi visto ao longo deste trabalho, existe uma dificuldade para aqueles
ligados a UFRRJ se locomoverem internamente. Isso se dá devido a qualidade de
distribuição de informação sobre dependências físicas e funcionais da UFRRJ, para
com seus alunos, professores e funcionários, comparada com sua proporção física
ser baixa. Em adição a este fato, vimos que o universo dos aplicativos para
computadores, tablets e celulares é um campo de estudo promissor e que vem
produzindo um número elevado de pesquisas a respeito nos últimos anos.
Sendo assim, esta pesquisa teve como objetivo diminuir essa dificuldade de
obter informações e se locomoverem encontradas por aqueles que fazem parte do
meio do meio que é a UFRRJ através da construção de um aplicativo interativo, com
mapas que exibisse tais informações. Focando naqueles serviços que são mais
básicos e mais procurados, identificou-se que o pavilhão central (P1) era o candidato
perfeito para ser mapeado funcionalmente e estruturalmente pelo aplicativo.
Para fazermos uso da tecnologia a favor da comunidade do campus, uma ideia
de rede de aplicativos foi pensada, para que, futuramente novos aplicativos possam
fazer parte desta, criando uma filosofia de campus inteligente e estando no cotidiano
das pessoas.
Diante dessa filosofia, um website de apresentação foi desenvolvido para
auxiliar e divulgar o aplicativo apresentado neste trabalho.
A abordagem híbrida escolhida para a construção do aplicativo teve como peça
decisória a possibilidade de ser multiplataforma, ou seja, ser acessível ao maior
número de usuários. Sabendo-se desta informação, um serviço de disponibilização
de dados centralizado também foi criado com intuito de reduzir a redundância e
aumentar a manutenibilidade da informação.
Como foi mencionado neste trabalho, a utilização do Google Indoor Maps não foi
implementada como recurso nativo da aplicação, mas foi efetuado uma simulação
de visualização interna utilizando recursos de sobreposição de imagens não
comprometendo o atingimento do objetivo geral do trabalho.
71
Em suma, o aplicativo criado40 atingiu todo os objetivos propostos, pesquisando
e exibindo informações dos serviços oferecidos pela UFRRJ diretamente na tela do
celular ou tablet. Cabe agora, garantir que mais informações sejam cadastradas no
mesmo afim de torna-lo essencial na vida das pessoas.
Outra pesquisa poderá ser feita diretamente com o a equipe do Google Indoor
Maps e a equipe responsável pela área tecnologia da UFRRJ, para verificar se as
disponibilizações das plantas baixas poderiam estar disponíveis diretamente no
serviço do Google Maps, assim o ‘look and feel’, ou aparência geral, do aplicativo
seria muito mais homogêneo.
40 Nota: o código fonte do aplicativo SmartCampus Maps será entregue em formato digital através de um CD no
momento da entregua deste trabalho para a Universidade Federal Rural do Rio de Janeiro.
72
6 REFERENCIAS BIBLIOGRAFICAS
ANNING, P.: Mission College helps students find their way with indoor Google Maps, 2012. Disponível em: <https://static.googleusercontent.com/media/maps.google.com/en//help/maps/indoormaps/assets/casestudies/missioncollege-cs-20120516-v4.pdf>. Acesso em 08 de abril de 2017. BELL, D., UML Basics: An introduction to the Unified Modeling Language, 2013. Disponível em:<http://www.ibm.com/developerworks/rational/library/769.html>. Acesso em: 28 de junho de 2015. BELL, D., UML’s Sequence Diagram. The Rational Edge, Jan. 2014. Disponível em: <http://carolina.terna.net/ingsw3/datos/UML2.0_Sequence_Diagrams.pdf>. Acesso em: 28 de junho de 2015. DATE, C.J. Introdução a sistemas de banco de dados. 4ª ed. Rio de Janeiro: Campus, 1990. da SILVA, L. L. B., PIRES, D. F., and NETO, S. C. (2014). Desenvolvimento de aplicações para dispositivos móveis: Tipos e exemplo de aplicação na plataforma ios. II Workshop de Iniciacão Científica em Sistemas de Informacão. Goiania, 2015. DEBUG IS ON THE TABLE. Google Maps: Traçando Rotas. Disponível em: <http://nglauber.blogspot.com.br/2011/10/google-maps-tracando-rotas.html>. Acesso em: 06 de junho de 2015. IBGE. Noções básicas de Cartografia. Disponível em: <http://www.ibge.gov.br/home/geociencias/cartografia/manual_nocoes/processo_cartografico.html>. Acesso em: 28 de junho de 2015. IDEALIZE TECH. Android Básico com Fundamentos de Java. Apresentação: Android_Básico_Fundamentos_Java.pdf. Curitiba, 2012. KHOSHAFIAN, S. Banco de dados orientado a objeto. Rio de Janeiro: Infobook, 1994. KORTH, H. F., SILBERSCHATZ, A. Sistema de banco de dados. 2ª ed. São Paulo: Makron Books, 1997. LECHETA, R. R. Google Android: Aprenda a criar aplicações para dispositivos móveis com Android SDK. São Paulo: Novatec Editora, 2009. FORWARD, A., LETHBRIDGE, T, C., The Relevance of Software
73
Documentation, Tools and Technologies: A Survey. In: ACM Symposium on Document Engineering. New York, NY, USA. Proceedings. New York, 2002. p. 26-33. GRECHANIK, M., MCKINLEY, K.S., PERRY, D.E.: Recovering And Using Use-Case-Diagram-To-Source-Code Traceability Links, In: ESEC-FSE ’07 Proc. of the 6th joint meeting of the European softw. eng. conference and the ACM SIGSOFT symposium on The foundations of softw. eng., pp. 95–104 ACM New York (2007) GOOGLE MAPS API. Disponível em: <https://developers.google.com/maps/?hl=pt-BR>. Acesso em: 16 abril de 2012. GOOGLE (2012). Nosso planeta mobile: Brasil. Como entender o usuário de celular. Disponível em: <http://www.thinkwithgoogle.com/mobileplanet/pt-br/>. Acesso em 10 de janeiro de 2016. MEDNIEKS, Z.; DORNIN, L.; MEIKE, G. B.; NAKAMURA, M. Programando o Android. Novatec Editora Ltda, 2012. MEIRA, F. (1997). Introdução às Bases de Dados para Pesquisa. Disponível em: <https://chasqueweb.ufrgs.br/~paul.fisher/apostilas/basdad/unimar/index.htm>. Acesso em: 16 de junho de 2017. OTRANTO, C. R.: Os Cursos de Licenciatura da Universidade Federal Rural do Rio de Janeiro: a busca de novos caminhos. Disponível em:< http://www.celia.na-web.net/pasta1/trabalho6.htm >. Acesso em: 02 maio de 2015. Open Source Initiative (2015). The Open Source Definition. Disponível em: <http://opensource.org/osd>. Acesso em: 28 de junho de 2015. PAIXÃO, L.. Planta Baixa – O que é e para que serve? Disponível em: <http://www.aarquiteta.com.br/blog/projetos-de-arquitetura/planta-baixa-o-que-e/>. Acesso em 17 de fevereiro de 2017. PEREIRA, L. C. O.; SILVA, M. L. da. Android para Desenvolvedores. Rio de Janeiro: Brasport Editora, 2009. PILONE, B., PITMAN, N.: UML 2.0 in a Nutshell. O’Reilly, Jun. 2005. 234 p. PRESSMAN, ROGER S. Engenharia de Software. 5 ed. Rio de Janeiro: Editora McGraw Hill, 2002. PREZOTTO, E.; BONIATI, B. Estudo de Frameworks Multiplataforma Para Desenvolvimento de Aplicações Mobile Híbridas. 2014.
74
RYDER, K. J.: Designing and Publishing Indoor Maps for Patients and Visitors in an Academic Teaching Hospital [Masters dissertation]. Dublin: Royal College of Surgeons in Ireland; 2015. Disponível em: < http://epubs.rcsi.ie/cgi/viewcontent.cgi?article=1076&context=mscttheses>. Acesso em: 08 de abril de 2017. SILVA, I. L. da; GESSER, S. Engenharia de Agrimensura e Cartografia. Disponível em: <http://r1.ufrrj.br/agricart/>. Acesso em: 04 de janeiro de 2017 SOUZA, C. M. de. Integração de ferramentas de código aberto (Java, Pentaho e Android) e mapas, aplicada a projetos de inteligência de negócios. 2010. 57 f. Monografia (Especialização) – Programa de Pós-graduação em Tecnologia,Universidade Tecnológica Federal do Paraná. Curitiba, 2010. UFRRJ. Rural em Números: Estudantes Matriculados em 2010. Disponível em <http://www.ufrrj.br/rural_em_numeros/estudantes.php >. Acesso em: 02 de maio de 2015.
top related