Você está na página 1de 85

UNIVERSIDADE METODISTA DE ANGOLA

FACULDADE DE ENGENHARIA
Engenharia Informática

“CaixaMóvel”
Desenvolvimento de uma Aplicação Móvel para a Localização de Multicaixas
na Cidade de Luanda

Belmira Nahary Veríssimo e Costa de Matos

Orientador: Msc. Hugo Santos

Maio de 2017
Belmira Nahary Veríssimo e Costa de Matos

“CaixaMóvel”
Desenvolvimento de uma Aplicação Móvel para a Localização de Multicaixas
na Cidade de Luanda

Trabalho de Fim de Curso


apresentado a Faculdade de
Engenharia da Universidade
Metodista de Angola, como
requisito parcial para obtenção
do grau de Licenciatura em
Engenharia Informática.

Maio de 2017
Belmira Nahary Veríssimo e Costa de Matos

“CaixaMóvel”
Desenvolvimento de uma Aplicação Móvel para a Localização de Multicaixas
na Cidade de Luanda

Esta Monografia foi julgada e aprovada para obtenção do grau


___________________________, no curso de _____________________________________,
da faculdade de Engenharia da Universidade Metodista de Angola.

Luanda, aos ____ de _____________ de _______.

BANCA EXAMINADORA

________________________________________
Presidente

________________________________________
1º Vogal

________________________________________
2º Vogal
Agradecimentos

Primeiramente agradeço à Deus pelas bênçãos, consolo, saúde, sabedoria e força que me
permitiu concluir este projecto com êxito, ao senhor devo todo o meu mérito.

Agradeço também aos meus pais (Anatilde e Agostinho) pelos conselhos, ensinamentos e toda
força que me deram durante o meu percurso acadêmico, às minhas irmãs por todo conforto e
compreensão, ao meu grande amor (Marco Cirilo) não sei se palavras são suficientes para
descrever o quão importante és para a minha vida, foste uma peça fundamental para a realização
deste projecto.

Ao meu orientador Me. Hugo Santos pelo incentivo, paciência e dedicação, o meu muito
obrigada por todo apoio e ajuda prestada no decorrer deste projecto, aos meus companheiros e
irmãos que a vida me proporcionou (Eurídice, Vinício, Júnior, Valina, Maria e Celeste)
perdoem-me se me esqueci de alguém, foram muitos os momentos que erguemos as mãos e
oramos, e graças ao nosso senhor ultrapassamos todas as barreiras juntos, obrigada a todos de
coração. Aos meus familiares destacadamente a minha prima Jandira, aos amigos por estarem
sempre comigo, em especial a Marta Xavier que mesmo longe sempre esteve perto, me dando
forças, e sem esquecer os meus queridos e amados professores por todos ensinamentos e
dedicação, em especial ao Pr. Gabriel Patrício pela confiança que sempre depositou em mim

Ao Sr. Rui Andrade e aos colaboradores da empresa Proit Consulting, expresso o meu profundo
agradecimento pela ajuda que me prestaram e a forma como me receberam. O resultado deste
projecto comtempla o empenho de todos.

Dedico este projecto a todas as pessoas que directa ou indirectamente contribuíram e continuam
a contribuir para o meu sucesso pessoal e profissional a todos o meu muito obrigada do fundo
do meu coração.

iv
Resumo

O mercado de dispositivos móveis vem crescendo cada vez mais, e com isso as funcionalidades
dos aparelhos se tornam essenciais na hora da escolha dos mesmos. Nesse sentido a computação
móvel vem ganhando espaço considerável no desenvolvimento de aplicações que visam
facilitar a vida das pessoas em suas atividades diárias, sendo assim a busca por aplicações
simples e que fornecem informações úteis que ajuda na vida em sociedade tem cada vez mais
importância.

O presente trabalho tem como objectivo, o estudo e desenvolvimento de uma solução móvel
para proporcionar aos utilizadores informações sobre a localização e estado dos Multicaixas na
cidade de Luanda, para ajudar nas dificuldades que muitas pessoas encontram quando precisam
efectuar alguma transação no mesmo, principalmente quando estamos em um local
desconhecido e até mesmo quando existe a falta de dinheiro ou avaria destes caixas.

Para solucionar este problema, surgiu o interesse em criar um aplicativo “CaixaMóvel”, para a
plataforma Android, que ajudará os utilizadores a encontrarem os multicaixas mais próximos
da sua localização actual em um mapa e através da partilha de informações de outros usuários
poderão aceder às informações do estado do mesmo (se está avariado, enchente, sem sistema
ou sem dinheiro).

Para desenvolver este sistema utilizou-se a plataforma Android que juntamente com a API do
GoogleMap foram necessárias para o seu desenvolvimento, o Firebase para armazenamento de
dados, a ferramenta de modelagem StarUML para a criação dos diagramas apresentados no
relatório e a linguagem de programação Java para a sua implementação.

Palavras-Chave: Android; Multicaixa, Geolocalização, GoogleMap.

v
Abstract

The market for mobile devices is growing more and more, and with that the functionalities of
the devices become essential when choosing them. In this sense mobile computing has been
gaining considerable space in the development of applications aimed at facilitate the life of
people in their daily activities, so the search for simple applications and providing useful
information that helps in life in society is increasingly important.

The present work aims to study and develop a mobile solution to provide users with information
about the location and state of ATM in the city of Luanda, to help in the difficulties that many
people encounter when they need to carry out some transaction in it, especially when We are in
an unknown location and even when there is a shortage of money or breakdown of these ATM.

For the solution of this issue, there was an interest in creating a "CaixaMovel" app for the
Android platform, which will help users find the multi-tapes closest to their current location on
a map, and by sharing information from other users, they can access the Information about the
state of the same (if it is damaged, flood, without system or without money).

To develop this system was used the Android platform that together with the API of GoogleMap
were necessary for its development, Firebase for data storage, the modeling tool StarUML to
create the diagrams presented in the report and the Java programming language For its
implementation.

Keywords : Android ; ATM ; Geolocation; GoogleMap

vi
Sumário
Agradecimentos ....................................................................................................................... iv
Resumo ...................................................................................................................................... v
Abstract .................................................................................................................................... vi
Lista de Figuras ....................................................................................................................... ix
Lista de Tabelas ....................................................................................................................... xi
Acrónimos ............................................................................................................................... xii
Capítulo 1 .................................................................................................................................. 1
1. Considerações Iniciais ..................................................................................................... 1
1.1. Introdução .................................................................................................................... 1
1.2. Identificação do problema ........................................................................................... 2
1.3. Delimitação do Problema ............................................................................................ 3
1.4. Justificativa .................................................................................................................. 3
1.5. Objectivos .................................................................................................................... 4
1.5.1. Objectivo Geral ........................................................................................................ 4
1.5.2. Objectivos Específicos ............................................................................................. 4
1.6. Metodologia ................................................................................................................. 5
1.7. Resultados Esperados .................................................................................................. 5
1.8. Organização do Projecto .............................................................................................. 6
1.9. Conclusão do Capítulo................................................................................................. 6
Capítulo 2 .................................................................................................................................. 7
2. Estado da Arte ................................................................................................................. 7
2.1.1. Localizador de ATM para plataforma iOS (MayBank) ........................................... 7
2.1.3. Localização de ATM (LocATM) ............................................................................. 9
2.1.4. Aplicação móvel baseada na localização (Place Me) ............................................ 10
2.3. Conclusão do Capítulo............................................................................................... 12
Capítulo 3 ................................................................................................................................ 13
3. Estudo das Tecnologias ................................................................................................. 13
3.1. Plataforma Android ................................................................................................... 13
3.1.1. Conceitos básicos ................................................................................................... 13
3.1.2. Arquitetura Android ............................................................................................... 15
3.2. Banco de dados não-relacional .................................................................................. 16
3.2.1. Firebase .................................................................................................................. 16

vii
3.3. Google Maps API ...................................................................................................... 17
3.3.1. Localização e Mapas no Android .......................................................................... 18
3.4. Conclusão do Capítulo............................................................................................... 19
Capítulo 4 ................................................................................................................................ 20
4. CaixaMóvel ................................................................................................................... 20
4.1. Descrição do Sistema................................................................................................. 20
4.2. Módulos do Sistema .................................................................................................. 20
4.2.1. Módulo Administrativo .......................................................................................... 20
4.2.2. Módulo Usuário ..................................................................................................... 21
4.3. Análise de Requisitos ................................................................................................ 21
4.3.1. Requisitos Funcionais ............................................................................................ 21
4.3.2. Requisitos não funcionais ...................................................................................... 22
4.3.3. Diagramas de Casos de uso.................................................................................... 23
4.3.3.1. Narração de Casos de Uso .................................................................................. 24
4.3.4. Diagrama de Actividade ........................................................................................ 29
4.3.5. Diagrama de Sequência.......................................................................................... 33
4.3.6. Diagrama de colaboração ....................................................................................... 37
4.4. Protótipo do sistema .................................................................................................. 39
4.4.1. Desenho de dados ....................................................................................................... 39
4.4.2. Mapeamento de Modelo Relacional para NoSQL ................................................. 42
4.4.3. Desenho de Software ............................................................................................. 43
4.4.4. Desenho de Hardware ............................................................................................ 44
4.4.5. Modelo Arquitectural ............................................................................................. 45
4.5. Conclusão do Capítulo............................................................................................... 45
Capítulo 5 ................................................................................................................................ 46
5. Conclusão ...................................................................................................................... 46
5.1. Trabalhos Futuro........................................................................................................ 47
5.2. Recomendações ......................................................................................................... 47
Referências Bibliográficas ..................................................................................................... 48
Apêndices ................................................................................................................................ 52
Anexo A- Interface do sistema .............................................................................................. 52
Anexo B- Trechos de Código da Aplicação .......................................................................... 65
Anexo C- Questionário de Pesquisa ...................................................................................... 69

viii
Lista de Figuras

Figura 1- Interface do aplicativo MayBank.............................................................................. 6

Figura 2- Interface do mapa com os diferentes pontos de ATM do sistema Bancário.............. 6

Figura 3- Interfaces do aplicativo LocATM.............................................................................. 7

Figura 4- Interface do aplicativo PlaceMe.................................................................................8

Figura 5- Ciclo de vida de uma atividade.................................................................................. 8

Figura 6- Camadas da arquitetura android................................................................................. 9

Figura 7- Arquitetura do Firebase............................................................................................ 10

Figura 8- Aplicação utilizando o Google Maps API no android.............................................. 14

Figura 9- Modelo de Casos de uso geral do sistema................................................................ 14

Figura 10- Diagrama de actividade do caso de uso registar administrador……...................... 15

Figura 11- Diagrama de actividade do caso de uso registar ponto de localização.................. 15

Figura 12- Diagrama de actividade do caso de uso criar conta de usuário............................. 16

Figura 13- Diagrama de Actividade do caso de uso inserir informação dos pontos................ 16

Figura 14- Diagrama de Sequência do caso de uso registar administrador.............................. 17

Figura 15- Diagrama de Sequência do caso de uso registar ponto........................................... 18

Figura 16- Diagrama de sequência do caos de uso registar usuário......................................... 19

Figura 17- Diagrama de Sequência do caso de uso inserir informação no ponto..................... 20

Figura 18- Diagrama de colaboração do caso de uso registar administrador........................... 21

Figura 19- Diagrama de colaboração do caso de uso registar ponto........................................ 22

Figura 20- Diagrama de colaboração do caso de uso registar usuário..................................... 22

Figura 21- Diagrama de colaboração do caso de uso inserir informação................................. 23


ix
Figura 22- Modelo Conceitual da base de dados …………..................................................... 23

Figura 23- Modelo lógico de base de dados............................................................................. 24

Figura 24- Diagrama de classes............................................................................................... 25

Figura 25- Entidade usuário representada na base de dados Firebase...................................... 26

Figura 26- Arquitectura de Software do CaixaMóvel............................................................. 26

Figura 27- Desenho de Hardware. CaixaMóvel....................................................................... 27

Figura 28- Diagrama Hierárquico de Funções......................................................................... 27

Figura 29- Tela de autenticação............................................................................................... 48

Figura 30- Diagrama de relacionamento com outras interfaces-Tela Autenticação................. 49

Figura 31- Tela de Registo de usuário...................................................................................... 50

Figura 32- Diagrama de relacionamento com outras interfaces-Tela de Registo de usuário... 51

Figura 33- Tela do Menu Principal.......................................................................................... 53

Figura 34- Diagrama de relacionamento com outras interfaces-Tela de Menu……................ 54

Figura 35- Tela de Informação dos pontos............................................................................... 55

Figura 36- Diagrama de relacionamento com outras interfaces-Tela de Informação.............. 55

Figura 37- Tela de Registo de Administrador.......................................................................... 56

Figura 38- Tela de Registo dos pontos..................................................................................... 58

Figura 39- Diagrama de relacionamento com outras interfaces-Tela Registo de pontos...........59

x
Lista de Tabelas

Tabela 1- Análise comparativa dos trabalhos relacionado..................................................... 11

Tabela 2- Requisitos Funcionais do sistema........................................................................... 12

Tabela 3- Requisitos não funcionais....................................................................................... 12

Tabela 4- Descrição da operação de registo de administradores no sistema.......................... 13

Tabela 5- Descrição da operação de registo dos pontos do multicaixa no sistema................. 13

Tabela 6- Descrição da operação de registo do usuário no sistema........................................ 12

Tabela 7- Descrição da operação de inserir informação no sistema....................................... 12

Tabela 8- Descrição dos campos da tela de autenticação…………………........................... 49

Tabela 9- Descrição de comandos da tela de Autenticação.....................................................50

Tabela 10- Descrição dos campos da tela de registo............................................................... 51

Tabela 11- Descrição dos comandos da tela de registo........................................................... 52

Tabela 12- Descrição dos campos da tela de menu……………............................................. 54

Tabela 13- Descrição de comandos da tela de Informação......................................................57

Tabela 14- Descrição dos campos da tela de registo............................................................... 58

Tabela 15- Descrição dos comandos da tela de registo........................................................... 58

Tabela 16- Descrição dos campos da tela de registo de Pontos.............................................. 59

Tabela 17- Descrição de comandos da tela de Registo de pontos........................................... 60

xi
Acrónimos

GPS Global Positioning System

ATM Automated Teller Machine

API Application programming interface

JSON JavaScript Object Notation

LBS Location Based Services

iOS iPhone Operating System

UML Unified Modeling Language

SDK Software Development Kit

NoSQL Not Only Structured Query Language

DER Diagrama Entidade Relacionamento

xii
Capítulo 1
1. Considerações Iniciais

Este capitulo apresenta o enquadramento do problema, os principais objectivos a serem


alcançados, as metodologias utilizadas bem como a estrutura do documento.

1.1. Introdução

Desde os tempos primórdios que o homem vem procurando formas de melhorar a sua qualidade
de vida, e nos dias que correm tem-se notado que os prestadores de serviços moveis estão cada
vez mais preocupados em garantir a comodidade dos seus clientes, procurando antecipar as suas
necessidades de modo a mantê-los sempre satisfeitos. Os dispositivos móveis já contam com
mais de 4 bilhões de usuários no mundo e ganharam status de ferramenta indispensável. Por
outro lado, a venda de smartphones tem superado a de laptops, o que indica que os mesmos
devem ganhar espaço como computador pessoal nos próximos anos (LECHETA, 2010).

A utilização da tecnologia de redes de dados sem fio e de smartphones será maior durante os
próximos anos, devido à facilidade em tirar fotos, gravar vídeos, realizar compartilhamento das
informações em redes sociais e assistir os jogos em tempo real (EMBRATUR, 2010). Resultado
disso o uso de aplicativos móveis tem apresentado altas taxas de crescimento ao redor do
mundo. Isso porque as pessoas estão cada vez mais conectadas aos seus tablets e smartphones,
utilizando os aplicativos seja para se comunicar, para jogar ou para comprar produtos. Tendo
em vista esse cenário, as empresas têm percebido a importância de desenvolver aplicativos
móveis caso queiram estar presentes na vida das pessoas e atender às necessidades de seus
clientes.

Os aplicativos móveis que utilizam a geolocalização propõem o espaço urbano não apenas
como um receptáculo no qual se dará a vida social, mas também como um elemento de fomento
a criatividade, uma rica fonte de informação e de elementos conjunturais para uma experiência
pautada na visibilidade do quotidiano. (ABREU; SOUSA, 2012). Atualmente, muitas das
aplicações baseadas na localização fazem o uso do Sistema de Posicionamento Global (GPS).
Este sistema conhecido comumente por GPS trouxe a tecnologia utilizada pelo posicionamento
de satélites utilizados, pelas Forças Armadas Americanas, para o ambiente quotidiano, com a

1
função de definir o local onde o dispositivo móvel que utiliza suas funcionalidades, possa
identificar onde o indivíduo se encontra. (EDUCAUSE, 2008).

Assim, o uso combinado do GPS com os sistemas de localização de antenas de celular fez da
geolocalização uma funcionalidade capaz de ser integrada ao modelo convergente da internet
móvel. (BRONSZTEIN; PIMENTA, 2011). A partir destes serviços de localização é possível
que os usuários de dispositivos móveis possam descobrir, aceder e aproveitar de uma forma
melhor o ambiente que os rodeia, no entanto seria um bom aproveitamento a sua utilização
efectiva para a localização de multicaixas nomeadamente ATM (do inglês: Automated Teller
Machine) próximos em uma cidade, bairro ou localidade.

Diante do exposto é de referir que as oportunidades de desenvolvimento de aplicativos moveis


que permitem solucionar problemas do dia-a-dia do utilizador tem-se tornado viável devido à
grande demanda do mercado, e é com base em tudo isso que se viu que seria uma mais valia
desenvolver uma aplicação para dispositivos móveis usando o sistema operacional Android,
que oferecerá para o usuário auxílio na localização de multicaixas próximos a sua localização
actual, fornecendo informações do estado do mesmo.

1.2. Identificação do problema

Actualmente tem se verificado uma grande procura de caixas automáticos a nível nacional, o
que apresentou um maior crescimento dos mesmos nos últimos anos. Segundo a EMIS, durante
os 15 anos da sua existência tem-se registrado um volume de transações nos caixas automáticos
de mais de 1 milhão de operações diárias. Com este elevado crescimento da procura dos
multicaixas, as pessoas encontram diversas dificuldades nomeadamente:

• Na Localização do multicaixa mais próximo – muita das vezes as pessoas têm


dificuldades a encontrar multicaixas próximos a sua localização actual, isto faz com que
percorram grandes distâncias desnecessariamente.

• Na obtenção de informação do estado atual do multicaixa – infelizmente inúmeras


vezes as pessoas perdem muito tempo ao deslocar-se de um ponto para o outro, para se
conseguir fazer qualquer movimentação bancária e acabam por fazer em locais muito

2
distantes da sua localização e outras vezes nem conseguem faze-lo pois encontram os
serviços indisponíveis.

• Enchentes nos multicaixas – várias pessoas quando encontram uma fila enorme nos
multicaixas, preferem desistir e voltar para a casa ou, então, procurar multicaixas noutros
bairros com menos pessoas.

• Na Localização e Direções dos multicaixas em zonas desconhecidas- há situações em


que as pessoas se encontram em zonas desconhecidas, e precisam de localizar
multicaixas, até mesmo por alguma emergência, têm que procurar por alguém que os
oriente para conseguir fazer o uso do multicaixa.

1.3. Delimitação do Problema

Este projeto visa dar respostas aos problemas definidos acima dando melhorias ao dia-a-dia do
usuário de multicaixas, permitindo maior facilidade na localização dos mesmos em diferentes
tipos de bancos e áreas. Porém haverá algumas limitações tais como: o aplicativo será funcional
em todo país, mas apenas apresentará em uma primeira fase, alguns multicaixas da cidade de
Luanda.

1.4. Justificativa

A geolocalização tem um alto potencial de poder social, isto é, devido ao facto de que permite
aos usuários ter conhecimento da própria localização geográfica de modo automático. Podemos
assim defini-la como um mecanismo que permite a localização de um objecto (computador,
tablet e telefone) em um sistema determinado de coordenadas.

Este processo é geralmente empregado pelos sistemas de informação geográfica, um conjunto


organizado de hardware e software, mais dados geográficos, que são projetados para capturar,
armazenar, manipular e analisar todas as informações possíveis de maneira geográfica
referenciada, com a clara missão de resolver problemas de gestão e planejamento.

Os sistemas de geolocalização estão baseados principalmente na tecnologia GPS (Global


Positioning System), um sistema de navegação por satélite dependente do governo norte-
3
americano. Recentemente, o desenvolvimento de sistemas de redes sem fio de dados e de
telefonia celular, wifi, 3G e bluetooth permitem também posicionar o dispositivo desde que este
se conecte a um usuário mediante triangulação. Em todo caso, estes sistemas alternativos não
apresentam a mesma cobertura nem permitem a mesma precisão de dados como os baseados
em GPS.

A inclusão da geolocalização no desenvolvimento de aplicativos móveis e web permite que


estes aumentem a sua velocidade de aquisição dos usuários, o que de facto é de suma
importância, pois através da mesma pode-se ter facilidade e comodidade em encontrar inúmeros
multicaixas, com maior rapidez e eficácia. Para os usuários em geral, a geolocalização faz cada
vez mais parte do quotidiano com obtenção de informações e rotas optimizadas, localização de
serviços e localidades próximas ao usuário.

1.5. Objectivos

1.5.1. Objectivo Geral

O projecto tem como objectivo geral desenvolver um protótipo de um aplicativo para


smartphones com sistema operacional Android que permita ao utilizador localizar o multicaixa
de diferentes tipos de banco e em qualquer área através da sua localização atual utilizando API
do Google Maps.

1.5.2. Objectivos Específicos

Os objectivos específicos a serem alcançados neste projecto são destacados a seguir:

• Desenvolver um protótipo que permite a localização dos multicaixas mais próximos da


localização actual do usuário.
• Mostrar a localização dos multicaixas no Mapa.
• Localizar os multicaixas existentes em um determinado local.
• Disponibilizar informações do estado actual dos multicaixas.
• Disponibilizar as direções para que o usuário consiga chegar ao seu destino.
• Permitir que o usuário troque informações com outros usuários.

4
1.6. Metodologia

A metodologia de desenvolvimento de software pode ser considerada um marco para iniciar as


melhorias no sistema, estabelecer uma linguagem comum para todos, definir metas de melhoria
contínua, trazer facilidade na manutenção de sistemas e facilitar o processo de testes.

O processo de desenvolvimento está estruturado nas seguintes fases:

• Análise de requisitos: nesta fase de levantamento e especificação de requisitos foi


definido os requisitos do software, necessários para a documentação do mesmo, através
de entrevistas a usuários de multicaixas (ver anexo III), consultas a manuais de apoio e
pesquisas em jornais locais.
• Desenho do projecto: nesta fase desenvolveu-se uma estrutura modular do software para
representar as relações de controlo entre os módulos.
• Implementação: para esta fase foi feita a concepção do sistema, utilizando a linguagem
de programação Java e com ajuda do Firebase foi feita a recolha e leitura dos dados da
base de dados.
• Validação e Verificação: nesta fase foi realizado os testes e optimizações em termos de
qualidade e adequação aos objectivos do sistema.

1.7. Resultados Esperados

Os principais objectivos esperados com a concepção deste protótipo se destacam a seguir:

• Evitar que as pessoas percorram longas distâncias, experimentar vários terminais para se
conseguir fazer qualquer movimentação bancária.
• Permitir que as pessoas que não conheçam uma determinada área possam localizar
multicaixas próximos a sua localização.
• Permitir que as pessoas saibam o estado atual antes de se deslocarem até aos mesmos.

5
1.8. Organização do Projecto

Este relatório encontra-se dividido em cinco capítulos, como se segue:

• Capítulo 1: apresentamos o enquadramento do problema, os principais objectivos a serem


alcançados e as metodologias utilizadas para atingir as metas desejadas.

• Capítulo 2: apresentamos o estado da arte e a contextualização do trabalho, com


investigações relacionadas aos trabalhos realizados com enquadramento fundamental para
o desenvolvimento do sistema.

• Capítulo 3: apresenta um estudo das tecnologias empregadas no desenvolvimento do


aplicativo, foi descrito a evolução do sistema operativo Android e a importância das
aplicações móveis no quotidiano.

• Capítulo 4: apresenta uma visão global do sistema, as principais funções implementadas


e de qualidade, o desenho do sistema e a arquitetura de hardware.

• Capítulo 5: são apresentadas as considerações finais, perspectivas de evolução de


projecto, assim como referências bibliográficas e alguns anexos, onde se encontram as
imagens de telas, documentos, código do programa e outros que contribuem para
esclarecer ou ilustrar determinados pontos do trabalho.

1.9. Conclusão do Capítulo

Neste capítulo fez-se uma apresentação ao projecto proposto, mostrando os seus objectivos,
enquadramento do problema, os resultados esperados e como está organizado o projecto.

6
Capítulo 2
2. Estado da Arte

Neste capítulo são abordados estudos aos principais trabalhos realizados com objectivos
semelhantes que serão utilizados para auxiliar no processo de desenvolvimento deste projecto.

2.1.1. Localizador de ATM para plataforma iOS (MayBank)

[Lim Yen Leng, 2012], este sistema foi desenvolvido para plataforma iOS com o objectivo de
acompanhar os ATM Bank que estão disponíveis em Kuantan, Malásia usando GPS. Este sistema
inclui a funcionalidade de calcular a distância actual do usuário para o caixa electrónico mais
próximo. A condição principal deste sistema é de que os usuários devem possuir um iPhone para
o seu uso.

O sistema tem como funcionalidades:

• Rastrear a localização de ATM usando GPS baseada na web suportado na plataforma iOS
• Localizar ATM próximo da posição actual do usuário.
• Mostrar a localização do ATM no Google Maps.

O processo de desenvolvimento foi estruturado nas seguintes fases:

• Fase 1: Planeamento e Análise do sistema.


• Fase 2: Modelagem e Desenho.
• Fase 3: Implementação, para esta fase foi usada a linguagem HTML5, JavaScript e
JqueryMobile, incluindo o Google Maps, Web Services e o JSON para intercâmbio dos dados
• Fase 4: O Teste foi efectuado a um smartphone com a plataforma iOS.

7
Figura 1- Interfaces do aplicativo MayBank. Fonte: (Lim Yen Leng, 2012)

2.1.2. Sistema Bancário com rastreamento de localização de ATM (Mobile Banking)

[Gugapriya A, Vaitheki J e Kaviyarasi S, 2013], desenvolveram um sistema para uma instituição


financeira, na qual fornece os números dos seus clientes através de dispositivos móveis. Este
sistema inicia com a criação de serviços de bancos que podem ser acessados através de um
telemóvel. Além disto dá a possibilidade ao usuário de localizar os ATMs mais próximos da sua
localização. O sistema bancário em aplicações móveis tem várias dimensões de execução, todas
representam um novo canal de distribuição que permite que as instituições financeiras e outras
instituições comerciais para oferta de serviços financeiros fora das instalações tradicionais do
banco.

O sistema foi implementado para o sistema operativo Android, usando as tecnologias de GPS para
fornecer a localização actual do usuário, o Google Maps para as informações de mapas e
actualização da localização do usuário e o LBS (Location Based Services) utilizado para identificar
a localização e navegar para as indicações dos Bancos e ATMs mais próximos.

8
Figura 2- Interface do sistema Bancário. Fonte: (Kaviyarasi S, 2013)

2.1.3. Localização de ATM (LocATM)

[Akas, Nishant, Sharma e Ayush, 2016], este sistema é desenvolvido principalmente para pessoas
em geral que utilizam um iphone. Um aplicativo para dispositivos móveis do iOS usando o Google
Maps para rastrear todos os ATMs em torno de uma localização actual dentro do raio especificado.
Este trabalho proposto é projetado para fornecer uma nova maneira de acessar o local do ATM por
dispositivos iOS. Portanto, é uma maneira fácil de acessar o local ATM em área desconhecida.
Aqui, o serviço baseado em identificar Centros ATM mais próximos usando o GPS. Assim, a
procura de Localização ATM torna-se mais fácil. Os objectivos para o localizador de ATMs com
o uso do GPS no aplicativo para dispositivos móveis são os seguintes:

• Desenvolver um rastreador de localização de ATM usando o Sistema de Posicionamento


Global (GPS) para a plataforma iOS.
• Localizar o local do ATM próximo da posição actual do usuário.
• Mostrar a localização do ATM no Google Maps.

A implementação deste sistema inclui a utilização de tecnologias como GPS e Google Maps para
localização do usuário em tempo-real e fornecer informações no mapa.

9
Figura 3- Interfaces do aplicativo LocATM. Fonte: (Ayush, 2016)

2.1.4. Aplicação móvel baseada na localização (Place Me)

[Aman Singhal, BSEE, 2010], desenvolveu o Place Me: uma aplicação móvel baseada em
Geolocalização para a plataforma Android com o objectivo de fornecer serviços de localização
úteis como restaurantes, hotéis, bancos, entre outros, quando o utilizador está em movimento. Para
tal, foram reunidas as tecnologias Android, GPS e Google Maps, para criar dois aplicativos.

O sistema apresenta como funcionalidades os seguintes serviços:

• Map me: um serviço que mostra no mapa apenas a área onde o utilizador está localizado;
• Reminder me: com esta função o utilizador tem a possibilidade criar lembretes para
determinados lugares;
• Search Nearby: conduz uma busca baseada em palavra-chave para lugares próximos da sua
localização actual.
• BookMark: para a marcação de favoritos.

10
O processo de desenvolvimento foi estruturado em 3 fazes descritas a seguir:

• Fase 1: Análise e especificação de requisitos do sistema;


• Fase 2: Desenho e Implementação do Sistema. A modelagem do sistema foi feita através da
linguagem UML. Para a implementação foi usada a ferramenta Android Studio, em
linguagem JAVA e para a persistência de dados foi seleccionado o banco de dados SQLite,
que já vem integrado no sistema da android.
• Fase 3: Teste e Avaliação, PlaceMe foi testado em campo, MyTouch 3G [25], um telefone
com Android 1.6 OS. Usando o aplicativo em um telefone real em cenários da vida real
revelou algumas informações interessantes que teriam sido de outra forma difíceis de
detectar em um ambiente simulado. Algumas das questões envolvidas foram: (1) a
codificação geográfica de um endereço postal do país de origem nem sempre produz uma
coordenada GPS exclusiva (2) a coordenada GPS retornada pode ser desligada por vários
metros do endereço físico (3) metros é muito fino para definir zonas de lembrete. Isso nos
levou a usar milhas, e definir o raio de lembrete padrão para um quarto de milha.

Figura 4 - Interface do aplicativo PlaceMe. Fonte: (Aman Singhal, BSEE, 2010)

11
2.2. Análise Comparativa dos Trabalhos Apresentados

A tabela 1 apresenta uma análise comparativa dos trabalhos apresentados na subsecção anterior,
destacando as principais características referentes a cada um dos sistemas desenvolvidos referentes
a localização baseada em serviços ligados a temática de geolocalização.

Aplicação Plataforma Objectivo Linguagem de Armazenamento de


Programação Dados
MayBank iOS Localização de HTML5, Banco de Dados
ATM a través JavaScript e(MySql)
de aplicações JqueryMobile
móveis
MobileBanking Android Transacções Java Banco de Dados
financeiras e (SQLite)
localização de
Bancos e ATMs
através de
dispositivos
móveis.
LocATM iOS Localização de Objective-C Banco de Dados
ATMs próximos (MySql)
ao usuário
PlaceMe Android serviços baseados Java Banco de Dados
em localização (SQLite)
pessoal, como
localização
Lembretes,
bookmarking,
mapeamento e
pesquisa nas
proximidades.

Tabela 1- Análise comparativa dos trabalhos relacionados

2.3. Conclusão do Capítulo

Neste capítulo foi feita uma introdução dos aplicativos que possuem uma proposta similar ao
CaixaMóvel, abordando suas funcionalidades e singularidades, e ao final foi apresentada uma
tabela comparativa das funcionalidades atendidas pelos aplicativos apresentados.

12
Capítulo 3
3. Estudo das Tecnologias

Este capítulo apresenta um estudo das tecnologias empregadas no desenvolvimento deste


aplicativo, na qual serão apresentadas as características da plataforma Android que é voltada
principalmente para dispositivos móveis, assim como o sistema de banco de dados não-
relacional pertencente à ferramenta Firebase e o estudo da API do Google Maps biblioteca da
localização e mapas, todas atualmente desenvolvidas pela Google.

3.1. Plataforma Android

O Android é uma plataforma aberta (open source) desenvolvida visando um vasto conjunto de
dispositivos com características diferentes. Seu objetivo principal é criar uma plataforma onde
desenvolvedores, operadoras e fabricantes possam inserir suas ideias e inovações resultando
em um produto que realmente aprimora a experiência do usuário (ANDROID, 2016). Nesta
subseção as principais camadas da arquitetura Android serão ilustradas juntamente com os
principais conceitos de uma aplicação Android e sua anatomia.

3.1.1. Conceitos básicos

As aplicações Android são escritas utilizando a linguagem Java, e cada aplicativo tem seu
próprio recipiente fechado de segurança, que o protege e o impede de executar funções fora de
seu domínio. Um aplicativo Android possui quatro tipos de componentes, que serão descritos
logo abaixo, são eles: atividades, serviços, provedores de conteúdo e receptores de transmissão.

Atividades: atividade é uma das classes mais importantes de um aplicativo Android, é ela que
gerencia a interface visual apresentada ao usuário. Uma aplicação pode ter várias atividades e
normalmente cada atividade representa uma funcionalidade do aplicativo. O entendimento do
ciclo de vida de uma atividade é essencial para que o desenvolvedor possa construir um
aplicativo que se comporte conforme desejado. Os estados em que uma atividade pode ser
encontrada na figura a seguir:

13
Figura 5- Ciclo de vida de uma atividade. Fonte: (ANDROID DEVELOPERS, 2016)

Receptores de transmissão broadcast: os receptores de transmissão broadcast de uma


aplicação funcionam de modo que ela precise ficar rodando para que ela executa alguma
instrução caso um evento específico ocorra, basta ela configurar um receptor de transmissão
para esse determinado evento, que o sistema faz o tratamento e anuncia à aplicação sempre que
ele ocorrer, fazendo com que as instruções configuradas no receptor sejam executadas.

Provedores de conteúdo: os provedores de conteúdo cuidam da parte de gerenciamento de


acesso a um conjunto de dados. Os provedores são projetados para serem utilizados por outras
aplicações através de um cliente, podendo fazer com que duas aplicações diferentes
compartilhem dos mesmos dados.

14
3.1.2. Arquitetura Android

O SDK do Android fornece 60 APIs assim como ferramentas necessárias para o


desenvolvimento das aplicações móveis, utilizando para isso a linguagem Java. A Figura 6
apresenta as várias camadas da arquitetura do sistema operativo Android.

Figura 6- Camadas da Arquitetura Android. Fonte: (ANDROID DEVELOPERS, 2014)

Aplicações: camada onde são encontradas as aplicações que ficam à disposição do usuário,
essas aplicações podem ser tanto os aplicativos nativos do sistema operacional como os
aplicativos baixados pelo usuário, todos ficam localizados nesta camada.

Android framework: nesta camada se encontram as funções básicas do telefone tais como o
sistema de localização, o sistema de chamadas, notificações, etc. A camada de aplicações
interage diretamente com essa camada para utilizar essas funções básicas.

15
Bibliotecas nativas e Android runtime: neste nível de camadas do Android são encontradas
os níveis de bibliotecas nativas e a camada de execução (Android Runtime).

Camada de abstração de hardware: essa camada providencia as interfaces para acesso aos
componentes de hardware do smartphone por meio de bibliotecas, assim quando a camada de
framework faz uma requisição para utilizar um elemento como, por exemplo, o bluetooth, essa
camada é que trata deste serviço.

Kernel Linux: como camada mais profunda, temos a do kernel do Linux, que nunca interage
com os usuários ou desenvolvedores, mas é o coração de todo o sistema. Ela garante a maioria
das funcionalidades essenciais tais como: segurança, gerenciamento de memória, configurações
de segurança, etc.

3.2. Banco de dados não-relacional

Nesta seção serão fornecidas informações sobre o banco de dados utilizado, no qual pertence a
classe de bancos não relacionais NoSQL (Não apenas SQL), uma tecnologia de banco de dados
projetada para suportar os requisitos de aplicações em nuvem e arquitetado para superar a
escala, desempenho, modelo de dados e as limitações de bancos de dados relacionais
(DATASCIENCE ACADEMY 2016). São diferentes sistemas de armazenamento que vieram
para suprir necessidades nas quais os bancos de dados relacionais eram ineficazes. O banco
utilizado foi o Firebase Realtime Database que consistem em um banco de dados não-relacional
localizado na nuvem fornecido pela Firebase (FIREBASE DATABASE 2016).

3.2.1. Firebase

O Firebase é uma plataforma criada em 2009 para a construção de aplicativos mobile e web
através de ferramentas e infra-estruturas que visam ajudar desenvolvedores a construir
aplicativos de qualidade (FIREBASE DATABASE 2016), onde são agrupados diversos
serviços importantes tais como o sistema de análise (Firebase Analytics), sistema de
autenticação de usuário (Firebase Auth), armazenamento de arquivos (Firebase Storage), banco
de dados (Firebase Realtime Database), hospedagem (Firebase Hosting) entre outros. Porém,

16
para este trabalho foi utilizado apenas o serviço de autenticação, de arquivos e o serviço de
banco de dados não relacional hospedado em nuvem, o Firebase Realtime Database.

Esse banco de dados nada mais é do que uma árvore JSON (Javascript Object Notation) gigante
em que todos seus dados estão armazenados nos nodos, o que facilita uma modelagem simples
de dados. O JSON é um modelo muito utilizado para armazenamento e transmissão de
informações no formato texto. O maior benefício do Firebase Database Realtime é que ele já
possui um sistema de sincronização instantânea implementado, fazendo com que, caso ocorra
uma modificação no banco, todos os aplicativos que tenham a referência daquele item, o
actualizem automaticamente, ao invés de trabalhar com requisição e resposta normalmente
utilizado em outros bancos. A figura 7 mostra a arquitectura do Firebase.

Figura 7- Arquitectura Firebase. Fonte: (SERVELESS SLIDESHARE, 2016)

3.3. Google Maps API

A versão beta do Google Maps foi lançado em fevereiro de 2005, com sua interface inovadora,
utilizando recursos do navegador nunca explorados. Esse novo estilo de desenvolvimento web
foi dado o nome de Ajax (A New Approach to Web Applications).

Google Maps se tornou não apenas uma revolução nas aplicações de mapas, mas um modelo
para todas as aplicações web. Tim O’Reilly (fundador da O’Reilly Media) chamou este novo
modelo de “Web 2.0”, o que ajudou a definir a diferença entre como as aplicações costumavam
ser e o novo modelo “Google Maps” (adaptado de DAVIS, 2006). Em junho de 2005 a Google
17
lançou a primeira versão de suas APIs, permitindo que os usuários pudessem desenvolver
aplicações com mapas. Em abril de 2006 lançaram a versão 2 das APIs, com novos recursos
como vários níveis de zoom, controles adicionais aos mapas e a possibilidade de criar várias
camadas com imagens personalizadas aos mapas.

Atualmente a API do Google Maps está na versão 3 e foi desenvolvida a partir a do zero, como
um conjunto modular de bibliotecas JavaScript focadas em melhorar a velocidade de
carregamento, especialmente para renderizar mapas em navegadores de dispositivos móveis
(KATARIA, 2009). Esta API do Google Maps contribuiu para o desenvolvimento da aplicação
por oferecer funcionalidades referentes ao uso do mapa, como marcar pontos com nossos
ícones, desenhar polígonos, desenhar trajetos dentre outros.

3.3.1. Localização e Mapas no Android

Uma das funcionalidades do Android que chamam atenção é a integração com o Google Maps
e a possibilidade de desenvolver aplicações de localização com GPS com poucas linhas de
código. É possível incluir esses recursos na aplicação utilizando as classes do pacote
android.location e o Google Maps Android API.

O componente principal do framework de localização é o LocationManager system service,


que provê as APIs para determinar a localização e a direção do dispositivo. Para utilizá-lo, é
necessário solicitar uma instância para o sistema,chamando o getSystemService
(Context.LOCATION_SERVICE) que retorna um handle para uma nova instância do
LocationManager.

Com as APIs de Google Maps para Android, é possível adicionar mapas nas aplicações
baseados nos dados do Google Maps, como mostra a Figura 8. A principal classe da API é o
MapView, que automaticamente acessa os servidores do Google Maps, baixa os dados, mostra
os mapas e trata os eventos de toque no mapa. Também é possível utilizar a API para adicionar
marcadores, polígonos, camadas e alterar a visualização do usuário de uma área específica
(MAPS, 2013).

18
Figura 8- Aplicação utilizando o Google Maps API no android

3.4. Conclusão do Capítulo

Neste capítulo foram abordadas as tecnologias utilizadas no desenvolvimento do aplicativo


proposto, como o Android, Firebase e o Google Maps API, que contribuíram bastante com as
suas funcionalidades e características para melhor desempenho do aplicativo.

19
Capítulo 4
4. CaixaMóvel

Neste capítulo será apresentada uma breve descrição dos módulos do sistema, especificação e
levantamento de requisitos mostrando os seus respectivos diagramas e o desenho do sistema.

4.1. Descrição do Sistema

O CaixaMóvel é um aplicativo de suporte aos usuários de multicaixas, que fornece informações


acerca dos mesmos em qualquer área próxima a localização actual do usuário, na qual foi
estruturado em dois módulos.

4.2. Módulos do Sistema

Módulo é uma parte do sistema responsável por uma tarefa específica que pode ser acoplado a
um sistema. O sistema CaixaMóvel apresenta os seguintes módulos:

4.2.1. Módulo Administrativo

Responsável pela administração do sistema, tem como funções principais:

• Gestão de Pontos: responsável pela criação e eliminação dos pontos de localização dos
multicaixas.
• Gestão de Denúncias: responsável pelo controle de denúncias feitas pelos usuários.
• Gestão de Administradores: responsável pelo registo de administradores do sistema,
definição de senha, bem como funções de eliminação e actualização.
• Gestão de Publicidades: responsável pela alteração das imagens de publicidades que se
encontram na tela de informação dos multicaixas.

20
4.2.2. Módulo Usuário

Inclui todos os utilizadores de multicaixa, possui funções diferentes das do administrador,


podendo verificar e partilhar informações acerca destes. E tem como funções:

• A criação da sua própria conta, bem como alteração e eliminação da mesma.


• Fornecer informações sobre o estado dos multicaixas para outros usuários.
• A Marcação de pontos de multicaixas como favoritos.
• Adicionar outros usuários como seus amigos para limitação de informação.

4.3. Análise de Requisitos

Descrevemos nesta secção os requisitos levantados, de modo a apresentar as funcionalidades


do sistema, de acordo a estes foi possível ter uma base sólida para o desenvolvimento do
CaixaMóvel, de forma a satisfazer as necessidades de seus usuários.

4.3.1. Requisitos Funcionais

Os requisitos funcionais são características do sistema, ou seja, são responsáveis por descrever
as funcionalidades do sistema. Um requisito funcional descreve uma interação entre o sistema
e o seu ambiente. A tabela a seguir descreve os requisitos funcionais do sistema CaixaMóvel.

Identificador Descrição Módulo

RF01 O sistema deve permitir a gestão de administradores Administrador


(registo, alteração, exclusão e actualização de dados).

RF02 O sistema deve permitir a gestão dos pontos de multicaixa Administrador


(inclusão e exclusão).
RF03 O sistema deve permitir a inclusão e alteração de imagens Administrador
de publicidade.

RF04 O sistema deve permitir ao usuário criar, alterar e eliminar Usuário


a sua conta.

21
RF05 O sistema deve permitir ao usuário inserir e obter Usuário
informações detalhadas ao clicar sobre o ícone do ponto
de multicaixa.
RF06 O sistema deve disponibilizar a visualização e o uso da Usuário
localização actual do usuário.

RF06 O sistema deve permitir ao usuário marcar pontos de Usuário


multicaixas como favoritos

RF07 O sistema deve permitir ao usuário adicionar novos Usuário


usuários como seus amigos e poder trocar mensagens com
os mesmos.
RF08 O sistema deve apresentar ao usuário o mapa e com todos Usuário
os pontos de multicaixa, bem como pesquisar os mesmos
através de um endereço específico.
RF09 O sistema deve permitir ao usuário selecionar um ponto Usuário
de multicaixa para traçar uma rota.

RF10 O sistema deve disponibilizar vários modos de exibição Usuário


do mapa

Tabela 2- Requisitos Funcionais do sistema

4.3.2. Requisitos não funcionais

Descrevem os requisitos de desempenho e outros requisitos (desempenho, segurança,


confiabilidade, suporte e usabilidade) necessários para que o software atinja a qualidade
desejada. A tabela a seguir descreve os requisitos não funcionais do Sistema.

Identificador Atributo Descrição Módulo

RNF01 Segurança O acesso dos utilizadores ao sistema Administrador


será restrito por senhas. Usuário

RFN02 Desempenho O sistema deve dar as respostas para Administrador


pesquisas na base de dados em tempo Usuário
real.

22
RFN03 Compatibilidade A aplicação deverá ser compatível e Administrador
acessível através de um smartphone Usuário
com o sistema operativo móvel
Android. A versão mínima
suportada para o sistema operativo
Android será 4.1.
RFN04 Usabilidade O sistema deve cumprir com o Administrador
princípio de um bom desenho. Usuário

RFN05 Disponibilidade O sistema deverá ter conexão à Administrador


Internet. Usuário

Tabela 3-Requisitos não funcionais

4.3.3. Diagramas de Casos de uso

Nesta secção é apresentado um diagrama de casos de uso de modo a perceber melhor as


funcionalidades do produto, sendo que, o caso de uso representa a interação entre o usuário e o
sistema. Deve ser usado quando se deseja visualizar o comportamento de vários objectos no
sistema, pois fornece uma descrição consistente e clara sobre as responsabilidades que devem
ser cumpridas pelo sistema.

23
A figura 9, ilustra o diagrama de casos de uso geral do sistema.

Figura 9- Modelo de Casos de uso geral do sistema

4.3.3.1. Narração de Casos de Uso

Método extensivo do diagrama que serve para explicar o próprio, de modo que cite as
trajectórias percorridas e as possibilidades do sistema. Especifica as interações feitas entre os
actores.

A definição do âmbito do caso de uso registar administradores do diagrama de casos de uso


geral do sistema é representada na tabela 4, ilustrando de forma detalhada o seu objectivo,
actores, a sua prioridade de desenvolvimento, dados envolvidos, fluxos principais, alternativos
e validações.

24
Actores: Administrador

Objectivo: Este caso de uso permite ao Administrador fazer o registo de novos administradores
no sistema.
Pré-Condição: O Administrador deve ser autenticado

Pós-Condição: Os dados do administrador são armazenados na base de dados no sistema.

Fluxo de Eventos principais

Acção do Actor Resposta do Sistema

1. O caso de uso começa quando o administrador 5. Validar Autenticação.


informa seus dados para autenticar-se ao sistema.

3. O utilizador informa os seus dados.

4. O Administrador insere os dados do novo 6. O Sistema autoriza a inserção dos dados.


administrador no sistema.

Sequência Alternativa

6a Dados incorrectos:
1. O Administrador reinicia o processo de autenticação.

Tabela 4- Descrição da operação de registo de administradores no sistema.

25
A definição do âmbito do caso de uso registar pontos dos multicaixas do diagrama de casos de
uso geral do sistema é representada na tabela 5, ilustrando de forma detalhada o seu objectivo,
actores, a sua prioridade de desenvolvimento, dados envolvidos, fluxos principais, alternativos
e validações.

Actores: Administrador

Objectivo: Este caso de uso permite ao Administrador fazer o registo dos pontos de
multicaixa no sistema.
Pré-Condição: O Administrador deve ser autenticado

Pós-Condição:Os dados dos pontos são armazenados na base de dados no sistema.

Fluxo de Eventos principais

Acção do Actor Resposta do Sistema

1. O caso de uso começa quando o 2. Validar Autenticação.


administrador informa seus dados para
autenticar-se no sistema.

3. O Administrador insere os dados do ponto no


sistema.

4. O Sistema autoriza a inserção dos dados.

Sequência Alternativa

5a Dados incorrectos:
3. O Administrador reinicia o processo de inserção.

Tabela 5- Descrição da operação de registo dos pontos do multicaixa no sistema.

26
A definição do âmbito do caso de uso criar conta do diagrama de casos de uso geral do sistema
é representada na tabela 6, ilustrando de forma detalhada o seu objectivo, actores, a sua
prioridade de desenvolvimento, dados envolvidos, fluxos principais, alternativos e validações.

Actores: Usuário

Objectivo: Este caso de uso permite ao Usuário registar-se no sistema.

Pré-Condição: Não tem.

Pós-Condição:Os dados do usuário são armazenados na base de dados no sistema.

Fluxo de Eventos principais

Acção do Actor Resposta do Sistema

1. O caso de uso começa quando o usuário 2. O Sistema autoriza a inserção dos dados.
informa seus dados para registrar-se no
sistema.

Sequência Alternativa

3a Dados incorrectos:
1. O Usuário reinicia o processo de inserção.

Tabela 6- Descrição da operação de registo do usuário no sistema.

27
A definição do âmbito do caso de uso inserir informação do diagrama de casos de uso geral do
sistema é representada na tabela 7, ilustrando de forma detalhada o seu objectivo, actores, a sua
prioridade de desenvolvimento, dados envolvidos, fluxos principais, alternativos e validações.

Actores: Usuário

Objectivo: Este caso de uso permite ao Usuário inserir informação do estado dos pontos de
multicaixas no sistema.
Pré-Condição: O usuário deve ser autenticado.

Pós-Condição: Os dados do usuário são armazenados na base de dados no sistema.

Fluxo de Eventos principais

Acção do Actor Resposta do Sistema

1. O caso de uso começa quando o usuário 2. Validar a autenticação.


informa seus dados para autenticar-se no
sistema.

3. O usuário acede a tela do mapa e escolhe o 4. O sistema traça a rota e exibi tela de
ponto desejado. informação.

5. O usuário escolhe a categoria e insere a 7. O sistema autoriza a inserção dos dados.


informação.

Sequência Alternativa

7a Dados incorrectos:
4. O Usuário reinicia o processo de inserção.

Tabela 7- Descrição da operação de inserir informação no sistema.

28
4.3.4. Diagrama de Actividade

Com o intuito de documentar de forma clara o fluxo de atividades do sistema foi criado os
diagramas de atividades de todos os casos de uso do sistema, o qual mostra o disparo para a
execução de cada atividade, seus desvios, a concorrência existente entre elas e a finalização de
cada uma.

A figura 10 referencia o diagrama de actividade do caso de uso registrar administrador. A


actividade começa quando o Administrador se autentica ao sistema, se os dados estiverem
correctos o sistema exibe a tela de menu, em seguida o Administrador acede a tela de Registo
e insere os dados do novo administrador e clica na opção para salvar os dados, caso este
administrador não exista no sistema, o sistema salva os dados na base de dados.

Figura 10- Diagrama de actividade do caso de uso registar administrador

29
A figura 11 ilustra as actividades referentes ao registo dos pontos de multicaixa no sistema. A
actividade começa quando o administrador se autentica ao sistema, casos os dados estejam
correctos o sistema exibe a tela de menu, em seguida o Administrador acede a tela de registo
de pontos e insere os dados do ponto e clica na opção salvar os dados. O sistema salva os dados
do ponto na base de dados.

Figura 11- Diagrama de actividade do caso de uso registar ponto de localização

30
A figura 12 ilustra o diagrama de actividade do caso de uso criar conta de usuário no sistema.
A actividade começa quando o usuário acede a tela de registro, insere os seus dados no sistema
e clica na opção salvar, caso estejam correctos, o sistema salva os dados do usuário na base de
dados.

Figura 12- Diagrama de actividade do caso de uso criar conta de usuário

31
A figura 13 ilustra o diagrama de caso de uso criar conta de usuário desempenhada pelo usuário
do sistema. Actividade começa quando o usuário se autentica no sistema, caso os dados estejam
correctos, o sistema exibe a tela do mapa, em seguida o usuário escolhe o ponto desejado e o
sistema exibe a tela de informação, o usuário escolhe a categoria, insere a informação e o
sistema valida os dados, caso estejam correctos, o sistema salva na base de dados e exibe a
informação.

Figura 13- Diagrama de Actividade do caso de uso inserir informação dos pontos

32
4.3.5. Diagrama de Sequência

O diagrama de sequência procurar determinar a sequência dos eventos de entradas e saídas


relacionadas com o sistema, este trabalha com mensagens que são disparadas entre os elementos
envolvidos. Esse diagrama descreve a interação entre os objetos do sistema.

O registo de administradores do CaixaMóvel é uma acção realizada apenas pelo administrador


do sistema, processo este que é realizado no módulo administrador. Antes de dar início a este
processo o administrador deve informar os seus dados para autenticar-se ao sistema, caso o
sistema confirme a existência dos dados de entrada do administrador na base de dados o
processo de registo é inicializado.

A figura 14 referencia o diagrama de sequência do caso de uso registar administrador.

Figura 14- Diagrama de Sequência do caso de uso registar administrador

33
O registo de pontos do multicaixa do CaixaMóvel é uma acção realizada apenas pelo
administrador do sistema, processo este que é realizado no módulo administrador. Antes de se
dar inicio a este processo, o administrador deve informar os seus dados para se autenticar ao
sistema, caso o sistema confirme a existência dos dados de entrada do administrador na base de
dados o processo de registo é inicializado.

A figura 15 referencia o diagrama de sequência do caso de uso registar ponto de multicaixa

Figura 15- Diagrama de Sequência do caso de uso registar ponto

34
O registo de usuário no CaixaMóvel é uma acção realizada apenas pelo usuário do sistema,
processo este que é realizado no módulo usuário. O usuário deve informar os seus dados, caso
o sistema verifique a existência dos dados de entrada do usuário na base de dados p processo
de registo é inicializado.

A Figura 16 referencia a sequência de acções realizadas no processo de registo de usuário.

Figura 16- Diagrama de sequência do caos de uso registar usuário

35
O processo de inserir informação dos pontos é apenas realizado pelo usuário do sistema,
processo este que é realizado no módulo Usuário. Antes de se dar início a este processo, o
usuário deve informar os seus dados para autenticar-se ao sistema, caso o sistema valide os
dados do usuário, o usuário terá acesso a tela do mapa, onde o usuário terá de escolher o ponto
no qual deseja inserir a informação, podendo assim o sistema salvar a informação na base de
dados.

A sequência de acções realizadas no processo de inserir informação nos pontos é ilustrada na


figura 17

Figura 17- Diagrama de Sequência do caso de uso inserir informação no ponto

36
4.3.6. Diagrama de colaboração

Mostra como um grupo de objectos num caso de uso interage com os demais. Cada mensagem
é numerada para documentar a ordem na qual ela ocorre. O diagrama de colaboração também
é um diagrama de interação.

Figura 18- Diagrama de colaboração do caso de uso registar administrador.

Figura 19- Diagrama de colaboração do caso de uso registar ponto

37
Figura 20- Diagrama de colaboração do caso de uso registar usuário

Figura 21- Diagrama de colaboração do caso de uso inserir informação

38
4.4. Protótipo do sistema

Para melhor entendimento do sistema, esta secção apresenta o protótipo do sistema, ilustrando
a constituição da base de dados do sistema a partir do desenho de dados, que é responsável por
definir e especificar as estruturas de dados necessárias, espelhando as entidades do sistema,
seus atributos e relacionamentos, serão também apresentados o diagramas de classes definindo
todas as classes do CaixaMóvel, bem como o desenho do software, desenho do hardware e a
estrutura hierárquica de funções (DHF).

4.4.1. Desenho de dados

Nesta secção apresentamos a modelagem conceitual da base de dados para a aplicação proposta.
Na figura 22 é apresentado o diagrama ER que descreve os requisitos de dados da aplicação do
CaixaMóvel. Por se tratar de um aplicativo que utiliza um banco NoSQL, foi necessário adaptar
o que ele pudesse refletir como realmente ocorre esse relacionamento.

Figura 22- Modelo Conceitual da base de dados


39
A partir da modelagem conceitual modelo (DER), construímos o modelo lógico do banco de
dados relacional conforme apresentado na Figura 23, na qual as entidades são transformadas
em tabelas e os atributos passam a ser campos das mesmas, bem como os respectivos
relacionamentos entre as tabelas.

Figura 23- Modelo lógico de base de dados

A partir deste modelo lógico podemos criar uma base de dados relacional. Porém, no paradigma
NoSQL não utilizamos nenhum destes artefactos produzidos, pois, conforme vimos
anteriormente, o modelo NoSQL é livre de esquema, não exigindo uma estrutura prévia para
que possa ser utilizada pela aplicação. Neste caso, apenas é necessário conectar-se ao banco de
dados, inserir, recuperar ou alterar os dados.

40
A figura 24 ilustra o diagrama de classe do sistema, uma estrutura lógica estática em uma
superfície de duas dimensões, mostrando uma coleção de elementos declarativos de modelos,
como classes, tipos e seus respectivos conteúdos e relações. é composto por classes (atributos
e métodos) e associações.

Figura 24- Diagrama de classes

41
4.4.2. Mapeamento de Modelo Relacional para NoSQL

Como citado anteriormente, não definiremos um esquema prévio para a base de dados NoSQL.
Porém, para uma melhor compreensão da estrutura, utilizamos a entidade usuário para mostrar
como a base de dados Firebase armazena as informações, conforme a Figura 25.

Figura 25- Entidade usuário representada na base de dados Firebase

É importante notar que o conceito de tabelas e de relacionamentos através de chaves


estrangeiras não são utilizados. No Firebase, apenas inserimos uma coleção de dados no objeto
usuário sem nos preocuparmos com a definição de tabelas e de seus relacionamentos. Devido à
falta de estrutura definida, não temos os conceitos de cardinalidade e participação. Podemos a
qualquer instante modificar um documento sem precisar respeitar uma estrutura previamente
definida, transferindo qualquer carga de validação de tipo de dado ou estrutura para a aplicação.

Podemos observar que a estrutura exibida fica bem mais próxima da realidade, ou seja, um
usuário possui uma coleção de dados em sua estrutura, não sendo necessário realizar uma

42
junção para buscar os dados de um usuário. Isto nos permite um ganho de desempenho quando
tratamos de aplicações mais complexas e com grandes volumes de dados e usuários.

4.4.3. Desenho de Software

Esta secção apresenta o desenho do software do sistema ilustrados através da arquitetura de


software. Para o Desenvolvimento do sistema foi adoptada a arquitectura em 2 camadas como
mostra a figura 26, onde utilizamos respectivamente a camada cliente e a camada de acesso a
dados onde a:

• Camada Cliente é responsável pela função de apresentação, código que gera a interface
visível do programa, que é utilizada pelo usuário para acessar a aplicação, e pelas regras
de negócio que são as regras que definem a maneira como os dados serão acessados e
processados, desde funções simples de validação da entrada de dados, até as funções mais
complexas.

• Camada de acesso a Dados: conhecida como camada de dados responsável pela


comunicação directa da aplicação com o back-end (código do lado do servidor) realizando
transações, como inclusão e consulta a dados.

Figura 26 – Arquitectura de Software do CaixaMóvel


43
4.4.4. Desenho de Hardware

Nesta Secção é apresentada a infra-estrutura tecnológica de suporte ao software bem como os


a ilustração dos seus equipamentos físicos.

Figura 27- Desenho de Hardware. CaixaMóvel

44
4.4.5. Modelo Arquitectural

Nesta secção apresentamos o DHF que define a arquitectura global de um programa ou sistema,
mostrando os módulos e como estes se relacionam. Num DHF cada módulo pode representar
um subsistema, programa ou módulo de programa.

Figura 28-Diagrama Hierárquico de Funções

4.5. Conclusão do Capítulo

Este capítulo serviu para elaborar os requisitos para a aplicação móvel. Para isso recorreu-se a
elaboração dos requisitos funcionais apoiados por casos de uso, assim como a requisitos não
funcionais. Foram também criados diagramas referentes aos casos de usos para perceber mais
rapidamente o que a aplicação é capaz de fazer e finalmente o desenho da aplicação e o DHF
mostrando a arquitetura global do sistema.
45
Capítulo 5
5. Conclusão

O presente trabalho teve como objectivo principal o desenvolvimento de uma aplicação móvel
que permite ao usuário obter informações de diferentes multicaixas perto da sua localização.
Para a concretização deste objectivo, foram realizados estudos e pesquisas de como desenvolver
um protótipo para geolocalização usando a API do Google Maps, foram feitos estudos nas áreas
de desenvolvimento e modelagem de software para obtermos os resultados esperados e
propostos no início das pesquisas. Da mesma forma, foram feitas algumas consultas à manuais
de apoio, pesquisas em jornais locais e entrevistas em usuários de multicaixas através de
questionários.

O sistema desenvolvido neste trabalho mostra que é possível a utilização de um aplicativo para
auxiliar os usuários de multicaixas poderem localizar os mesmos próximos da sua localização
actual, permitindo buscar rapidamente os pontos de multicaixas, visualizar rotas, obter o tempo
de duração até a chegada ao ponto solicitado e obter informações sobre o mesmo sem a
necessidade de percorrerem grandes distâncias para chegarem até a estes pontos.

O projecto foi dividido em dois módulos: Administrador e Usuário. A divisão desses módulos
permitiu trabalhar de forma autónoma, mas criando ligações entre os módulos ao nível do
sistema. O desenvolvimento do aplicativo permitiu rever alguns conceitos aprendidos durante
o curso de especialização como programação Java, comunicação cliente-servidor, e obter
conhecimentos sobre as tecnologias que contribuíram para o desenvolvimento deste aplicativo
como a utilização dos mapas da Google, a plataforma Android e o Firebase Realtime Database
para o acesso aos dados. Este sistema contribuirá de várias maneiras no dia-a-dia do usuário de
multicaixa, permitindo que as dificuldades que surgem no momento de localizar o mesmo,
possam ser superadas, obtendo deste modo mais tranquilidade quando tiverem que se deslocar
até ao multicaixa.

46
5.1. Trabalhos Futuro

Para trabalhos futuros, pretende-se aprofundar a pesquisa em relação ao tema e posterior dar
continuidade no desenvolvimento do projecto de maneiras a dar suporte e contribuir para a
melhoria do mesmo, assim como a melhoria do layout da aplicação de forma a tornar-se mais
apelativa, apesar de a actual se revelar uma boa alternativa, penso que há certos aspectos visuais
(cores, ícones) que poderiam ser melhorados, integrar a aplicação com o Facebook, de forma a
dar mais visibilidade à mesma, além disso adicionar novas funcionalidades como obter direções
e traçar as rotas não só de carro como é apresentado na aplicação, mas também traçar as rotas
de bicicleta ou a pé.

5.2. Recomendações

É recomendado, que para ter acesso às funcionalidades do aplicativo móvel, o smartphone


possua acesso à Internet, também se recomenda que o aplicativo seja instalado em versões de
android superior à 4.0 (API 16), para melhor uso do aplicativo.

47
Referências Bibliográficas

LECHETA, Ricardo. Google Android: “Aprenda a criar aplicações para dispositivos móveis
com o Android SDK”. São Paulo: Novatec Editora, 2010.

MACK, R. S. Sistema de recomendação baseado na localização e perfil utilizando a plataforma


android. 2010. 56 f. In: Dissertação para Obtenção do Grau de Licenciado - Universidade
Federal do Rio Grande do Sul, Porto Alegre, 2010.

FRANCO, J; PEROZZO, R. F. Sistema para localização e gerenciamento de táxis utilizando a


plataforma android.106f. In: Dissertação para Obtenção do Grau de Licenciado. Centro
Universitário Franciscano, Santa Maria. 2015.

FURLAN, J. D. Modelagem de objectos através da UML, 1998.

GUGAPRIYA, A.; VAITHEKI, J.; KAVIYARASI, S. Mobile Banking with Location Tracking
Of Nearest ATM Center Using GPS, International Journal of Innovative Technology and
Research Volume No. 1, 2013.

SALGADO, N. Serviços Bancários “Utilizadores queixam-se de número elevado de


multicaixas fora de serviço” Expansão. Outubro de 2016.

GOOGLE. PLACES API <http://code.google.com/apis/maps/documentation/places/> acesso


em abril de 2017.

GOOGLE DEVELOPERS. API do Google Maps. 2013. Disponível em:


<http://developer.android.com/index.html>. Acesso em novembro de 2016.

ANDROID DEVELOPER. Location Manager APIs


<http://developer.android.com/reference/android/location/LocationManager.html/> Acesso em
novembro de 2016.

LENG, L. Y. ATM Locator Mobile Application. In: Bachelor of Computer Sciences. University
Malaysia Pahang 2012.

48
ANDROIDAPP. Android Architecture - The Key Concepts of Android OS. 2013. Disponível
em: <http://bit.ly/1S0Ylng>. Acesso em: novembro de 2016.

KARASINSKI. E.O que é GeoLocalização. 2010. Disponível em: <http://bit.ly/1JFfBxB>.


Acesso em: maio 2013.

FIREBASE. Realtime Database. Disponível em:


<https://firebase.google.com/docs/database/?hl=pt-br/>. Acesso em março de 2017.

FIREBASE. About Firebase. 2009. <https://firebase.google.com/>. Acesso em: Fevereiro de


2016.

FIREBASE. Authentication Firebase. <https://firebase.google.com/docs/auth/android/start/>.


Acesso em: Fevereiro de 2016.

WILT, A. H. Geolocalização baseada em localizar pessoas através de dispositivos móveis.


2012. 61 f. Monografia (Graduação) - Curso de Sistema de Informação, Universidade
Paranaense - Unipar, Paranavaí, 2012.

CORREIA, A. G. S. Aplicações e serviços baseados em localização. 2004. Disponível em:


<http://www-di.inf.pucrio.br/~endler/courses/Mobile/Monografias/04/AdolfoCorreia-
Mono.pdf>Acesso em maio de 2017.

BRITO, R. C; OGLIARI, R. Geolocalização Android: GPS, mapas e sintetização de voz no


Android. 2014. Disponível em: <http://www.devmedia.com.br/geolocalizacaoandroid-gps-
mapas-e-sintetizacao-de-voz-no-android/30495>.Acesso em maio de 2017.

FILIPE, L. H; DIAS W. J. Aplicações baseadas em Geolocalização. 2014. Trabalho de


Investigação Cientifica -Universidade Paranaense (Unipar) Paranavaí, Brasil. Disponível em
<http://web.unipar.br/~seinpar/2014/artigos/graduacao/Heitor_Felipe.pdf>. Acesso em maio
de 2017.

SILVA, C. M. Desenvolvimento de um aplicativo de auxílio para localização no Centro


Universitário de Patos de Minas – UNIPAM. 2015.112f. Monografia (Graduação) - Curso de
Sistema de Informação, Centro Universitário de Patos de Minas.

49
Ribeiro, R. Construindo aplicações baseadas em localização no Android. Disponível em:
<http://www.devmedia.com.br/construindo-aplicacoes-baseadas-em-localizacao-no-
andoid/10325>. Acesso em maio de 2017.

ANDROIDHIVE. <http://www.androidhive.info/2016/01/android-working-with-
recyclerview/> Acesso em outubro de 2016.

GITHUB DEVACADEMY. <https://github.com/devacademy/android-fundamentalone/>


Acesso em outubro de 2016.

TUTORIALSPOINT. <https://www.tutorialspoint.com/android/androidacitivities.htm
>Acesso em outubro de 2016.

KUMAR, A.; NISHANT K.; SHARMA A.; SRIVASTAV, A. LocATM ATM Locator.
international Journal of Modern Trends in Engineering and Research (IJMTER), Volume 03,
Abril– 2016.

MACEDO, T. Arquitetura de Aplicações em 2, 3, 4 ou N camadas. Disponível em:


<http://www.diegomacedo.com.br/arquitetura-de-aplicacoes-em-2-3-4-ou-n-camadas/> .
Acesso em maio de 2017.

LIMA, C.; MELLO, R. S. Um Estudo sobre Modelagem Lógica para Bancos de Dados NoSQL.
Universidade Federal de Santa Catarina.2015.

KAUR, K.; RANI, R. Modeling and Querying Data in NoSQL Databases. IEEE. In:
International Conference on Big Data, 2013.

FAGUNDES, E. R. Aplicação Android utilizando sistema de localização geográfica para


determinação de pontos turísticos na cidade de Curitiba.2012.55f. Monografia de
Especialização - Universidade Tecnológica Federal do Paraná.

ROCHA M. N. Computação Móvel: Serviços Baseados na Localização de Unidades Móveis


(LBS). Disponível em: <http://www.dpi.ufv.br/~nacif/cmovel/06_LBS.pdf/>. Acesso em:
Novembro de 2016.

50
VICARI R. L. A importância de ter um serviço e um planejamento de geolocalização para
equipe técnicas em campo. 2016. Disponível em: http://blog.sovis.com.br/a-importancia-de-
ter-um-servico-e-um-planejamento-de-geolocalizacao-para-equipe-tecnicas-em-campo/.
Acesso em: Maio de 2017.

FEIJÓ S. Caixa Electrônico, Multicaixa ou terminal Bancário. 2014 - Bancos de Angola.


Disponível em: http://www.bancosdeangola.co.ao/caixa-electronico-multicaixa-ou-terminal-
bancario/ Acesso em: Maio de 2017.

SPADA A. Acções baseadas em geolocalização. 2012- Marketing Digital. Disponível em:


http://blog.sforweb.com.br/acoes-baseadas-em-geolocalizacao/ Acesso em: Maio de 2017.

BRUNET, K.; FREIRE, J. Cultura digital e geolocalização: a arte ante o contexto técnico-
político. 2010. In: VI Encontro de Estudos Multidisciplinares em Cultura, 2010, Salvador.
Disponível em: http://karlabru.net/site/publicacoes/cultura-digital-e-geolocalizacao/. Acesso
em: Maio de 2017.

RIBEIRO R. Geolocalização: conceitos e aplicações. Disponível em:


<http://www.totalcross.com/blog/geolocalizacao-conceitos-e-aplicacoes/>. Acesso em: Maio
de 2017.

FERNANDES R. P. Firebase Database para desenvolvedores SQL. Disponível em:


<https://medium.com/android-dev-moz/firebasesql-4ee3d26a3d15>. Acesso Abril d 2017.

51
Apêndices
Anexo A- Interface do sistema

Requisitos de Interface

São apresentados nesta secção, os modelos de interface do CaixaMóvel, construídos com


auxílio da ferramenta Android Studio.

52
Figura 29- Tela de autenticação

Relacionamento com outras interfaces

Figura 30- Diagrama de relacionamento com outras interfaces-Tela Autenticação

Campos

Nº Nome Descrição Requisitos de Requisistos de Requisitos


conteúdo edição Diversos
1 Email do Email do usuário Texto de até Alterável/ Informado pelo
usuário 40 caracteres Obrigatório usuário
alfanuméricos
e pontuações
2 Senha Senha do usuário Texto superior Alterável/ Informado pelo
a 6 caracteres, Obrigatório usuário/
entre conteúdo oculto
alfanuméricos, por asteriscos
pontuações e
espaços

Tabela 8- Descrição dos campos da tela de autenticação

53
Comandos

Nº Nome Descrição Requisitos de validade Requisitos Diversos

1 Entrar Acede a tela Sempre válida


principal do mapa
se for o usuário,
acede a tela de
menu principal se
for administrador
2 Registar Acede a tela de Válida para o usuário
Registo do sistema
3 Esqueceu Acede a Tela de Válida para o usuário
Senha Recuperação de do sistema
senha

Tabela 9- Descrição de comandos da tela de Autenticação.

Interface de Registo do usuário

54
Figura 31- Tela de Registo de usuário

Relacionamento com outras interfaces

Figura 32- Diagrama de relacionamento com outras interfaces- Tela de Registo de usuário

Campos

Nº Nome Descrição Requisitos de Requisistos de Requisitos


conteúdo edição Diversos
1 Nome do Nome do usuário Texto de até Alterável/ Informado pelo
usuário 40 caracteres Obrigatório usuário
alfanuméricos
e pontuações
2 Senha Senha do usuário Texto superior Alterável/ Informado pelo
a 6 caracteres, Obrigatório usuário/
entre conteúdo
alfanuméricos, oculto por
pontuações e asteriscos
espaços
3 Confirmar Confirmar Senha Texto superior Alterável/ Informado pelo
Senha do usuário a 6 caracteres, Obrigatório usuário/
entre conteúdo
alfanuméricos, oculto por
pontuações e asteriscos
espaços
4 Data de Data de Texto de até 8 Alterável Informado pelo
nascimento nascimento do caracteres usuário
usuário númericos

55
5 Género Género do Seleccionável Alterável Informado pelo
usuário usuário
6 Email do Email do usuário Texto de até Alterável/ Informado pelo
usuário 40 caracteres Obrigatório usuário
alfanuméricos
e pontuações
7 Endereço Endereço do Texto de até Alterável Informado pelo
do usuário usuário 40 caracteres usuário
alfanuméricos
e pontuações

Tabela 10- Descrição dos campos da tela de registo

Comandos

Nº Nome Descrição Requisitos de validade Requisitos Diversos

1 Concluir Acede a tela de Válida para o usuário Atributos obrigatório


autenticação depois do sistema devem todos ser
de salvar os dados válidos
do usuário
2 Voltar Cancela a operação Válida para o usuário
e fecha a interface do sistema
3 Adicionar Adiciona uma Válida para o usuário
Imagem imagem para o do sistema
perfil do usuário

Tabela 11- Descrição dos comandos da tela de registo

56
Interface do Menu Principal

Figura 33- Tela do Menu Principal

57
Relacionamento com outras interfaces

Figura 34- Diagrama de relacionamento com outras interfaces- Tela de Menu

Comandos

Nº Nome Descrição Requisitos de validade

1 Mapa Acede a tela de Válida para o usuário do sistema


Mapa
2 Perfil Acede a tela de Válida para o usuário do sistema
Perfil
3 Kambas Acede a Tela de Válida para o usuário do sistema
amigos adicionados
4 Favoritos Acede a Tela de Válida para o usuário do sistema
multicaixas
favoritos
5 Conta Acede a tela de Válida para o usuário do sistema
Definições da conta
do usuário
6 sair Termina a sessão Válida para o usuário do sistema
no sistema

58
Tabela 12- Descrição de comandos da tela de Menu.
Interface de Informação de multicaixa

Figura 35- Tela de Informação

Relacionamento com outras interfaces

Figura 36- Diagrama de relacionamento com outras interfaces- Tela de Informação

59
Comandos

Nº Nome Descrição Requisitos de Requisitos


validade Diversos
1 Adicionar Acede a tela para inserir Válida para o Atributos devem
uma nova informação usuário do sistema ser válidos
2 Editar Altera os dados da Válida para o Atributos devem
informação no sistema administrador do ser válidos
sistema
3 Eliminar Elimina os dados do Válida para o
sistema administrador do
sistema
4 Voltar Cancela a operação e fecha Válida para o
a interface administrador do
sistema

Tabela 13- Descrição de comandos da tela de Informação.

Interface de Registo de administrador

60
Figura 37- Tela de Registo de Administrador

Relacionamento com outras interfaces

Figura 38- Diagrama de relacionamento com outras interfaces- Tela de Registo Administrador

Campos

Nº Nome Descrição Requisitos de Requisistos de Requisitos


conteúdo edição Diversos
1 Nome do Nome do Texto de até Alterável/ Informado pelo
administrador administrador 40 caracteres Obrigatório administrador
alfanuméricos
e pontuações
2 Email do Email do Texto de até Alterável/ Informado pelo
administrador administrador 40 caracteres Obrigatório administrador
alfanuméricos
e pontuações
3 Senha Senha do Texto superior Alterável/ Informado pelo
administrador a 6 caracteres, Obrigatório administrador /
entre conteúdo
alfanuméricos, oculto por
pontuações e asteriscos
espaços
4 Confirmar Confirmar Texto superior Alterável/ Informado pelo
Senha Senha do a 6 caracteres, Obrigatório administrador /
administrador entre conteúdo
alfanuméricos, oculto por
pontuações e asteriscos
espaços

Tabela 14- Descrição dos campos da tela de registo

61
Comandos

Nº Nome Descrição Requisitos de Requisitos Diversos


validade
1 Adicionar Salva os dados do Válida para o Atributos devem ser
administrador administrador do válidos
sistema
2 Voltar Cancela a operação e Válida para o
fecha a interface administrador do
sistema

Tabela 15- Descrição de comandos da tela de Registo.

Interface de Registo de Pontos Multicaixa

Figura 3- Tela de Registo de Ponto

62
Relacionamento com outras interfaces

Figura 38- Diagrama de relacionamento com outras interfaces- Tela de Registo Multicaixas

Campos

Nº Nome Descrição Requisitos de Requisistos de Requisitos


conteúdo edição Diversos
1 Latitude Latitude do Texto de até Alterável/ Informado pelo
ponto 15 caracteres Obrigatório administrador
numéricos
decimal
2 Longitude Longitude do Texto de até Alterável/ Informado pelo
ponto 15 caracteres Obrigatório administrador
numéricos
decimal
3 Endereço Endereço do Texto até 40 Alterável/ Informado pelo
ponto caracteres, Obrigatório administrador
entre
alfanuméricos,
pontuações e
espaços
4 Referência Referência do Texto até 40 Alterável/ Informado pelo
ponto caracteres, Obrigatório administrador
Entre
alfanuméricos,
pontuações e
espaços

Tabela 16- Descrição dos campos da tela de registo

63
Comandos

Nº Nome Descrição Requisitos de validade Requisitos


Diversos
1 Adicionar Salva os dados do ponto Válida para o Atributos devem
de multicaixa no administrador do sistema ser válidos
sistema
4 Voltar Cancela a operação e Válida para o
fecha a interface administrador do sistema

Tabela 17- Descrição de comandos da tela de Registo de pontos.

64
Anexo B- Trechos de Código da Aplicação

B.1- Trecho do código da aplicação em Java- Adicionar pontos ao mapa

private void initMarker() {


markersArray = new ArrayList<>();

mDatabase.child("markers").addValueEventListener(new ValueEventListener() {
@Override
public void onDataChange(DataSnapshot dataSnapshot) {

for (DataSnapshot markerDataSnapshot : dataSnapshot.getChildren()) {


MarkerData marker = markerDataSnapshot.getValue(MarkerData.class);

if (marker == null) {
Log.e(TAG, "User data is null!");
return;
}
markersArray.add(marker);
Log.d(TAG, "Marker longitude: " + marker.getLongitude() + ", latitude "
+ marker.getLatitude() + ", id : "+ marker.getIdentificador());
}
for(int i=0; i < markersArray.size(); i++){
createMarker(markersArray.get(i).getLatitude(),
markersArray.get(i).getLongitude(), markersArray.get(i).getReferencia(),
markersArray.get(i).getEndereco()
,markersArray.get(i).getIdentificador());
}
}

@Override
public void onCancelled(DatabaseError databaseError) {
}
});

65
protected Marker createMarker(final double latitude,final double longitude,final String
referencia,final String endereco,final String identificador) {

Log.d(TAG, "id"+identificador);
databasePost.child(identificador).addListenerForSingleValueEvent(new
ValueEventListener() {
@Override
public void onDataChange(DataSnapshot dataSnapshot) {

long count = dataSnapshot.getChildrenCount();


if (count >= 1) {
myMarker = mMap.addMarker(new MarkerOptions()
.position(new LatLng(latitude, longitude))
.title(referencia)
.snippet(endereco)

.icon(BitmapDescriptorFactory.fromResource(R.drawable.marker_pingre)));
myMarker.setTag(identificador);

Log.d(TAG, "Marker criado green");


} else {
myMarker = mMap.addMarker(new MarkerOptions()
.position(new LatLng(latitude, longitude))
.title(referencia)
.snippet(endereco)
.icon(BitmapDescriptorFactory.fromResource(R.drawable.marker_pin3)));

Log.d(TAG, "Marker criado orange");


myMarker.setTag(identificador);
}
}

@Override
public void onCancelled(DatabaseError databaseError) {

}
});

return myMarker;

66
B.2- Trecho do Código da aplicação em Java- Adicionar nova informação do multicaixa

private void startPosting() {

mProgress.setMessage("Criando a publicação...");
final long timeStamp =(-1 * new Date().getTime());
final String desc = mPostDesc.getText().toString().trim();
final String status = estado.getText().toString().trim();
Calendar cc = Calendar.getInstance();
Date date = cc.getTime();
// SimpleDateFormat format1 = new SimpleDateFormat("dd MMM");
SimpleDateFormat format2 = new SimpleDateFormat("dd-MM-yyyy HH:mm:ss ",
Locale.getDefault());
final String time = format2.format(date);
if( mImageUri != null){

mProgress.show();

StorageReference filepath =
mStorage.child("Post_Images").child(mImageUri.getLastPathSegment());
filepath.putFile(mImageUri).addOnSuccessListener(new
OnSuccessListener<UploadTask.TaskSnapshot>() {
@Override
public void onSuccess(UploadTask.TaskSnapshot taskSnapshot) {

final Uri downloadUri = taskSnapshot.getDownloadUrl();


final DatabaseReference newPost =
mDatabaseReference.child("Post").child(idmarker).push();
final DatabaseReference imagebd =
mDatabaseReference.child("Imagens").child(uid).push();
newPost.child("descricao").setValue(desc);
newPost.child("estado").setValue(status);
newPost.child("categoria").setValue(categoria);
newPost.child("imagem").setValue(downloadUri.toString());
newPost.child("uid").setValue(uid);
newPost.child("idmarker").setValue(idmarker);
newPost.child("data").setValue(time);
newPost.child("timestamp").setValue(timeStamp);
imagebd.child("image").setValue(downloadUri.toString());
imagebd.child("data").setValue(time);
mProgress.dismiss();
initActivity();
}
});

}else if(!TextUtils.isEmpty(desc)){
67
final DatabaseReference newPost =
mDatabaseReference.child("Post").child(idmarker).push();
newPost.child("descricao").setValue(desc);
newPost.child("estado").setValue(status);
newPost.child("categoria").setValue(categoria);
newPost.child("imagem").setValue("default");
newPost.child("uid").setValue(uid);
newPost.child("idmarker").setValue(idmarker);
newPost.child("data").setValue(time);
newPost.child("timestamp").setValue(timeStamp);

mProgress.dismiss();
initActivity();
}
}

68
Anexo C- Questionário de Pesquisa
Ao todo, vinte e seis (36) pessoas responderam o questionário produzido no Google Forms e
divulgado por via Facebook no perfil do autor deste trabalho. Apartir deste foi possível fazer
uma avaliação quanto a utilização dos multicaixas e medir nível de satisfação das pessoas, o
que foi de grande auxílio no desenvolvimento desta aplicação.

69
C.1- Questionário Multicaixas no dia-a-dia

70
71
72
73

Você também pode gostar