Você está na página 1de 79

UNIVERSIDADE METODISTA DE ANGOLA

FACULDADE DE ENGENHARIA
Engenharia Informática

“Sistema Kudissanga Multicaixa”


Desenvolvimento de uma aplicação web para a Localização de Multicaixas na
cidade de Luanda

Euridice Staline Pedro Pinto Ferreira

Orientador:
Professor Engº Hugo Dias Dos Santos

Luanda, Maio de 2017


Euridice Staline Pedro Pinto Ferreira

“Sistema Kudissanga Multicaixa”


Desenvolvimento de uma aplicação web 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.

Luanda, Maio de 2017.


Euridice Staline Pedro Pinto Ferreira

“Sistema Kudissanga Multicaixa”


Desenvolvimento de uma aplicação web 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

Agradeço primeiramente a Deus, por ter me dado saúde e inteligência durante estes 5 anos de
formação, foram anos difíceis e trabalhosos, mas com Deus no controle hoje posso dizer que
valeu apena cada esforço e dedicação.

Aos meus pais Salustiano Ferreira e Josefa Comandante, o meu muito obrigado por não
medirem esforços na realização deste sonho. As minhas irmãs, tios e amigos obrigado por todo
apoio que deram-me, ao longo desta caminhada.

Ao meu noivo pela paciência, companheirismo e apoio em todas as fases desta difícil jornada,
obrigado de coração porque nos momentos das minhas ausências dedicados aos estudos, sempre
entendeste que о futuro é feito а partir da constante dedicação no presente.

Os meus sinceros agradecimentos a todos os professores da universidade metodista que directa


ou indirectamente tornaram possível realização deste projecto. Em especial, o meu orientador
Professor Engº Hugo Dias Dos Santos, pela dedicação e paciência.

Agradeço a Instituição que me acolheu para o estagio “Pro It, consulting”, pois foi a base para
a realização deste projecto. O meu muito obrigado a todos por cada contributo. Em especial ao
Sr.Rui Andrade por me receber de braços abertos, pelo incentivo e pela disponibilidade.

Aos meus colegas e companheiros de batalha, obrigado por estarem comigo nos bons e maus
momentos desta caminhada, não foi fácil, mas graças a Deus conseguimos.

A todos que directa ou indirectamente fizeram parte da minha formação, о meu muito obrigado.

i
Epígrafe

“A única maneira de fazer um


bom trabalho é amando o que
você faz. Se você ainda não
encontrou, continue procurando.
Não se desespere. Assim como
no amor, você saberá quando
tiver encontrado.”
Steve Jobs.

ii
Abstract

It is undisputed that online mapping services, such as Google Maps, have revolutionized our
understanding of space. The web mapping technology, which is the process of using maps
provided by GIS, has progressed a lot with the possibility of using the Maps API.

Today, with the great use of geolocation-based applications that allow us to walk in cities,
countries, without ever having walked, meet specific unknown points like stores, pharmacies,
ATMs, showing the route chosen by the user in minutes.

In the present work we will discuss the difficulties we usually encounter when we want to locate
the nearest multicaixas in an unknown zone, or when we want to make use of it and we did not
know its current state.

In order to solve this problem, the interest appeared in creating the Web application
"Kudissanga Multicaixa", which has as main functionalities to show the existing multi-zones
in different zones thus providing the current state of each one of them, as well as showing the
route between a source and a Destination at the user's choice.

To develop this application we used the Visual Studio Code tool, the google maps API,
framework Angular 2, the StarUML modeling tool, and the TypeScript programming language
for programming.

Key words: Geolocation; Multicaixas; API Google Maps.

iii
Resumo

É indiscutível que os serviços de mapeamento online, como o Google Maps, revolucionaram a


compreensão que temos do espaço. A tecnologia web mapping é o processo de utilização de
mapas fornecidos por GIS (Sistema de informação geográfica), progrediu muito com a
possibilidade de usar a API do Google Maps.

Atualmente, com a grande utilização de aplicativos baseados em geolocalização que nós


permite andar em cidades, países, sem nunca ter andado, conhecer pontos específicos
desconhecidos como lojas, farmácias, ATMs, mostrando a rota escolhida pelo usuário em
questões de minutos.

No presente trabalho serão abordadas as dificuldades que normalmente encontramos quando


queremos localizar os multicaixas mais próximos numa zona desconhecida, ou quando
queremos fazer uso do mesmo e não soubemos o seu estado actual.

Para solucionar este problema, surgiu o interesse em criar o aplicativo Web “Kudissanga
Multicaixa”, que tem como principais funcionalidades mostrar os multicaixas existentes em
diferentes zonas disponibilizando assim o estado actual de cada um deles, como também
mostrar a rota entre uma origem e um destino a escolha do usuário.

Para desenvolver este aplicativo utilizou-se a ferramenta Visual Studio Code, a API do Google
Maps, framework Angular 2, a ferramenta de modelagem StarUML, e a linguagem de
programação TypeScript para a programação.

Palavras-Chave: Geolocalização; Multicaixas; API Google Maps.

iv
Lista de Figuras

Figura 2.1 – Tela de pesquisa do aplicativo Web foursquare……………………...…………..7

Figura 2.2 – Tela de demostração do resultado da pesquisa…………………………………....8

Figura 2.3 – Tela inicial do mapa da aplicação com o numero de jardim para cada estado…....9

Figura 2.4 – Tela de resultado de pesquisa…………………………………………………….10

Figura 2.5 – Janela de informação do jardim clicado………………………………………….10

Figura 2.6 – Tela inicial do sistema (navegador desktop Mozilla Firefox 6.x)………………..11

Figura 2.7 – Tela de pesquisa (navegador desktop Mozilla Firefox 6.x)………………………11

Figura 2.8 – Tela de resultado (navegador desktop Mozilla Firefox 6.x)………………….….12

Figura 4.1 – Diagrama de caso de uso do sistema……………………………………………..24

Figura 4.2 – Diagrama de actividade do caso de uso criar conta………………………………28

Figura 4.3 – Diagrama de actividade do caso de uso Alterar estado………………………...…29

Figura 4.4 – Diagrama de actividade do caso de uso Solicitar rota………………….………...30

Figura 4.5 – Diagrama de actividade do caso de uso Alterar estado……….…………………..31

Figura 4.6 – Diagrama de actividade do caso de uso Criar conta…………………..………….32

Figura 4.7 – Diagrama de actividade do caso de uso Solicitar rota……………….…………..32

Figura 4.8 – Diagrama de colaboração do caso de uso Criar conta……………….……..……33

Figura 4.9 – Diagrama de colaboração do caso de uso Solicitar rota………………………….34

Figura 4.10 – Diagrama de colaboração do caso de uso Alterar estado………………….…….34

Figura 4.11 – Diagrama de classes do sistema Kudissanga Multicaixa………………………..36

Figura 4.12 – Entidade usuário representada na base de dados Firebase – mapit……………...37

Figura 4.13 – Entidade markers (marcadores de multicaixa) representada na base de dados


Firebase – mapit…………………………...……………………………….….38

v
Figura 4.14 – Arquitetura de software do sistema Kudissanga Multicaixa…………………….38

Figura 4.15 – Arquitetura de hardware do sistema Kudissanga Multicaixa…………………...39

Figura 4.16 – Diagrama Hierárquico de Funções do sistema Kudissanga Multicaixa…………40

Figura A.1 – Tela de inicio do sistema Kudissanga Multicaixa………………………………..47

FiguraA.2 –Diagrama de relacionamento da tela de inicio com outras telas (sem


autenticação)……………………………………………………………..….47

Figura A.3 – Tela inicial do usuário do sistema Kudissanga Multicaixa……………………..48

Figura A.4 – Diagrama de relacionamento da tela inicial do usuário com outras telas……..….49

Figura A.5 – Tela inicial do administrador do sistema Kudissanga Multicaixa…………….…50

Figura A.6 – Diagrama de relacionamento da tela inicial do administrador com outras telas….50

Figura A.7 – Tela de registro de marcador de multicaixa do sistema Kudissanga Multicaixa…52

Figura A.8 – Diagrama de relacionamento da tela Criar ATM com outras telas……………...52

Figura A.9 – Tela do Administrador de Informação e gerência de marcador de multicaixa do


sistema………………………………………………………………………….54

Figura A.10 – Diagrama de relacionamento da tela ATM Info com outras telas………………54

Figura B.1 – Trecho de código Inserir Marcador de multicaixa no Mapa………………….….56

Figura B.2 – Trecho de código Criar marcador de multicaixa na base de dados……………….58

Figura B.3 – Trecho de código Mostrar rota entre dois pontos…………………………….…59

Figura B.4 – Trecho de código Eliminar marcador na base de dados……………………….…60

Figura C.1 – Tabela da base de dados - Markers……………………………………………....61

Figura C.2 – Tabela da base de dados - Mensagens………………………………………..….61

Figura C.3 – Tabela da base de dados – User……………………………………………..…..62

Figura C.4 – Tabela da base de dados – Funcionarios…………………………………………62

Figura E.1 – Modelo Lógico do sistema Kudissanga Multicaixa…………………………….63

vi
Lista de Tabelas

Tabela 2.1 – Tabela comparactiva do estado da arte…………………………………………..13

Tabela 3.1 Diferença entre visual studio code e visual studio……………………………..….20

Tabela 4.1 – Requisitos Funcionais do sistema………………………………………………..22

Tabela 4.2 – Requisitos não Funcionais do sistema……………………………………...……23

Tabela 4.3 – Descrição do caso de uso Criar conta…………………………………………….25

Tabela 4.4 – Descrição do caso de uso Alterar estado do multicaixa……………………….….26

Tabela 4.5 – Descrição do caso de uso solicitar rota…………………………………………..27

Tabela A.1 – Descrição dos comandos da tela inicial do usuário sem autenticação……….…48

Tabela A.2 – Descrição dos comandos da tela inicial do usuário……………………………..49

Tabela A.3 – Descrição dos campos da tela inicial do usuário………………………………..49

Tabela A.4 – Descrição dos comandos da tela inicial do administrador…………………….…51

Tabela A.5 – Descrição dos campos da tela de registro de marcador de multicaixa………...…53

Tabela A.6 – Descrição dos comandos da tela de registro de marcador de multicaixa……..…53

Tabela A.7 – Descrição dos comandos da tela do Administrador de Informação e gerência de


marcador de multicaixa…………………………………………………………55

vii
Lista de Abreviações e Siglas

GIS Geographic Information Systems

API Application Programming Interfaces

JSON JavaScript Object Notation

SPA Single Page Application

ATM Asynchronous Transfer Mode

Web World Wide Web (WWW)

CSS Cascading Style Sheets

DHF Diagrama Hierárquico de Funções

HTML HyperText Markup Language

SQL Structured Query Language

NoSQL Not Only Structured Query Language

XML Xtensible Markup Language

EMIS Empresa Interbancária de Serviços

NPM Node Package Manager

RF Requisitos Funcionais

RNF Requisitos Não Funcionais

FRAMEWORK Conjunto de classes

OPEN-SOURCE Código aberto para alterações

viii
Índice

Agradecimentos ...................................................................................................................................... i
Epígrafe .................................................................................................................................................. ii
Abstract ................................................................................................................................................. iii
Resumo .................................................................................................................................................. iv
Lista de Figuras ..................................................................................................................................... v
Lista de Tabelas ................................................................................................................................... vii
Lista de Abreviações e Siglas............................................................................................................. viii
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.6. Metodologia ................................................................................................................................ 4
1.7. Resultados Esperados .................................................................................................................. 5
1.8. Organização do projecto.............................................................................................................. 5
Capítulo 2 ............................................................................................................................................... 7
Estado da arte .......................................................................................................................................... 7
2.1. Considerações Iniciais ................................................................................................................. 7
2.2. Conclusão do capítulo ............................................................................................................... 13
Capítulo 3 ............................................................................................................................................. 14
Estudo das Tecnológias ......................................................................................................................... 14
3.1. Considerações Iniciais ............................................................................................................... 14
3.2. Conclusão do capítulo ............................................................................................................... 20
Capítulo 4 ............................................................................................................................................. 21
Sistema Kudissanga Multicaixa ............................................................................................................ 21
4.1. Considerações Iniciais ............................................................................................................... 21
4.2. Descrição do Sistema ................................................................................................................ 21
4.3. Módulos do Sistema .................................................................................................................. 21
4.4. Análise de requisitos ................................................................................................................. 22
4.5. Protótipo do sistema .................................................................................................................. 35
4.6. Conclusão do Capítulo .............................................................................................................. 41
Capítulo 5 ............................................................................................................................................. 42
Considerações Finais ............................................................................................................................. 42
5.1. Conclusões ................................................................................................................................ 42
5.2. Dificuldades .............................................................................................................................. 42
5.3. Trabalhos Futuros...................................................................................................................... 43
5.4. Recomendações ......................................................................................................................... 43
Referências Bibliográficas .................................................................................................................. 44
Anexos .................................................................................................................................................. 47
Capítulo 1

1. Considerações Iniciais

No presente capítulo abordaremos sobre o projecto em questão, sua problemática, objectivos


gerais e específicos, a metodologia usada bem como a organização do projecto.

1.1. Introdução

A sociedade vive numa era tecnológica onde as ferramentas digitais estão cada vez mais sendo
inseridas no nosso cotidiano. A internet tornou-se em pouco tempo o meio de comunicação
mais utilizado e eficaz para obtermos informações em termo real. Para Santos (2007) a
utilização de novas tecnologias e o uso de computadores conectados à internet estão presentes
em todos os segmentos importantes das sociedades do mundo actual.

O computador pode ser considerado o recurso didático do século XXI, dado à variedade de
atividades que ele permite efectuar, principalmente através da internet. (COSTA;
MAGALHÃES; ASSIS; 2008).

Para que haja um aumento de produtividade considerável em ambientes de


desenvolvimento web, é preciso que os desenvolvedores web, busquem inúmeras
ferramentas e softwares visando rapidez, confiabilidade e êxito. Para que isso ocorra
surgem as API’s, que estão cada vez mais acessíveis para os programadores,
permitindo a utilização do mesmo em softwares, como o uso da API do Google Maps
para desenvolvimento web.

O aumento de aplicações webs que utilização a API do Google maps tem-se tornado viável
devido à grande demanda do mercado, a cada dia os usuários tornam-se mais exigentes e
procuram maior êxito em suas pesquisas, sendo assim utilizando a API Google Maps estas
buscas se tornam mais acessível satisfazendo assim as necessidades diárias dos usuários.

1
Multicaixa é o nome da rede angolana de pagamentos por cartão que tem, por base, o
compartilhamento interbancário de caixas automáticas e de terminais de pagamento automático
em pontos de venda. Entre as suas várias funções e utilidades, o multicaixa “permite uma grande
variedade de transacções sem que o cliente tenha que se deslocar fisicamente a um banco”, além
de que as operações realizadas por via deste canal não têm custos associados (EMIS, 2002).

A utilização de ferramentas como a API do Google Maps têm facilitado os programadores de


aplicações web a satisfazerem as necessidades dos seus usuários, na busca de locais e rotas
desconhecidas, além disso permitem solucionar problemas do dia-a-dia do utilizador como
encontrar os multicaixas mais próximos, saber a rota para chegar a um multicaixa desconhecido
e principalmente saber o estado actual do mesmo sem houver a necessidade de andar longas
distâncias, nem andar de multicaixa em multicaixa para encontrar um com os serviços
disponíveis.

Visto que com a ajuda das novas tecnologias é possível solucionar diversos problemas de uma
sociedade, que muitas vezes parecem sem solução, isto motivou-nos a desenvolver uma
aplicação Web que se apoderou dessas tecnologias de forma positiva para poder responder de
maneira gratificante as necessidades dos usuários dos ATMs.

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 transacções nos caixas
automáticos de mais de 1 milhão de operações diárias. No entanto as pessoas recorrem a estes
serviços tais como levantamentos, transferências bancárias, recargas e pagamentos com a
finalidade de suprir as suas necessidades 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.

2
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 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 projecto visa dar resposta aos problemas definidos acima, dando melhorias ao dia-a-dia
dos usuários dos multicaixas. Por outro lado, existem algumas restrições, tais como:

 Embora é possível localizar multicaixas no país inteiro (Angola), a aplicação limita-se


apenas em mostrar os multicaixas da cidade de Luanda;
 Na aplicação não estão disponíveis todos os multicaixas existentes nos municípios 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,
3
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 planeamento.

Para usuário em geral, a geolocalização faz cada vez mais parte do coitidiano com obtenção de
informações e rotas optimizadas, localização de serviços e localidades próximas ao usuário.

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.

1.5. Objectivos

Objectivo geral

O projecto tem como objetivo geral desenvolver uma aplicação web que permitirá ao utilizador
localizar o multicaixas mais próximos da sua localização actual utilizando API do Google maps.

Objectivos específicos

Os objetivos específicos do projecto são:

 Localizar os multicaixas mais próximos da sua localização actual;


 Localizar os multicaixas existentes numa determinada zona;
 Disponibilizar informações do estado actual dos multicaixas;
 Disponibilizar as rotas para que o usuário consiga chegar ao seu destino;
 Permitir que o usuário do aplicativo possa alterar os estados dos multicaixas.

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.
4
O sistema foi desenvolvido baseando-se 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 questões feitas a vários usuários de multicaixas (ver anexo E), 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 Typescript e com ajuda do Firebase foi feita a recolha e leitura dos dados
da base de dados.

 Validação e Verificação: Nesta fase será 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 destacam-se a seguir:

 Evitar que as pessoas percorram longas distâncias para encontrar um multicaixa com as
suas operações disponíveis.
 Permitir que as pessoas que não conheçam uma determinada área possam localizar
multicaixas próximos a sua localização.
 Evitar que as pessoas experimentem vários terminais para se conseguir fazer qualquer
movimentação bancária.
 Permitir que as pessoas saibam o estado atual antes de se deslocarem até aos mesmos.

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.

5
 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, alguns anexos e apêndices, onde se
encontram as imagens de telas, documentos, código do programa e outros que contribuem
para esclarecer ou ilustrar determinados pontos do trabalho.

6
Capítulo 2

Estado da arte

2.1. Considerações Iniciais

Durante o desenvolvimento deste projecto, fomos pesquisando trabalhos e artigos com


objectivos semelhantes que foram utilizados para auxilio no processo de desenvolvimento do
mesmo, pois tratam de assuntos relacionados ao projecto.

2.1.1. Aplicativo Web Foursquare

[Harry Heymann, Nathan Folkman, Mike Singleton, Dennis Crowley e Naveen Selvadurai,
2009], desenvolveram o aplicativo Foursquare: que permite ao utilizador indicar onde se
encontra, e procurar por contatos que estejam próximo da sua localização actual. Permite ao
utilizador procurar restaurantes, lojas e outros locais de interesse na sua área envolvente.

Algumas ferramentas utilizadas para o desenvolvimento do aplicativo:

 Para autenticação dos usuários: OAuth 2.0;


 Para obtenção da localização dos usuários: GPS - sistema de posicionamento global;
 Para pesquisas e visualização de mapas e rotas: Google Maps;
 Ficheiros JSON para intercâmbio dos dados.

Figura 2.1 – Tela de pesquisa do aplicativo Web foursquare.

7
Algumas funcionalidades do aplicativo:

 O aplicativo permite o usuário fazer login e se registrar;


 O aplicativo conta com uma camada de rede social que permitiu um usuário compartilhar
sua localização com amigos;
 Foursquare permite ao utilizador procurar restaurantes, clubes noturnos, lojas e outros
locais de interesse na sua área envolvente.
 O aplicativo ajuda o usuário conhecer novos lugares através das recomendações de outros
usuários.

Figura 2.2 – Tela de demostração do resultado da pesquisa.

2.1.2. Aplicactivo Web People’s Garden

[Shunfu Hu e Ting Dai, 2013], este aplicativo foi desenvolvido com o objectivo de mostrar e
pesquisar mais de 600 jardins disponíveis ao redor da cidade. Isto foi uma iniciativa do
departamento de Agricultura dos Estados Unidos da América. Este aplicativo tem como
objectivo especifico facilitar as pessoas que por algum motivo procuram um jardim pela cidade,
como por exemplo, para marcar um encontro, para relaxar, para fazer um piquenique, etc.

8
Algumas ferramentas utilizadas para o desenvolvimento do aplicativo:

 API do Google Maps,


 Google Geocoderer,
 banco de dados Microsoft SQL,
 Microsoft aspx.NET,
 JavaScript libraries.

Principais navegadores que podem ter acesso a aplicação:

 Microsoft Internet Explorer (IE) 7.0+,


 Google Chrome,
 Mozilla Firefox,
 Apple Safari.

Figura 2.3 – Tela inicial do mapa da aplicação com o numero de jardim para cada estado.

9
Figura 2.4 – Tela de resultado de pesquisa.

Segundo os desenvolvedores o aplicativo tem as seguintes características:

 O aplicativo permite pesquisar os jardins existentes numa determinada zona;


 As pesquisas podem ser feitas por endereço ou por código postal;
 O aplicativo mostra e pesquisa os jardins por categorias diferentes;
 Ao clicar no marker de um jardim é possível observar as informações do mesmo, como
endereço, fotografia, entre outras.

Figura 2.5 – Janela de informação do jardim clicado.


10
2.1.3. Sistema mobile web para busca georreferenciada de imóveis (Cadê Meu Apê)

[Gláucia Mendes, 2011], desenvolveu uma ferramenta de busca de imóveis baseada em


localização geográfica, que é possível utilizar a partir de qualquer dispositivo com acesso à
internet, permitindo assim uma busca com resultados mais precisos e que atenda os mais
diversos perfis de clientes, evitando que o usuário não perca muito tempo no momento de
procurar imóveis que vão de acordo as suas necessidades.

Figura 2.6 - Tela inicial do sistema (navegador desktop Mozilla Firefox 6.x).

Principais ferramentas utilizadas para o desenvolvimento do sistema:

 jQuery Mobile;
 HTML5 e CSS;
 Google Maps API e JavaScript;

Figura 2.7 - Tela de pesquisa (navegador desktop Mozilla Firefox 6.x).


11
Principais Características do sistema:

 Este sistema apresenta uma interface que se ajusta tanto para a visualização em
computadores desktops como em dispositivos móveis.
 É compatível com todas as principais plataformas móveis: IOS, Android, Blackberry,
Palm WebOS, Nokia / Symbian, Windows Mobile e qualquer outro dispositivo com
navegador que interprete HTML.
 O usuário poderá filtrar a busca por pontos específicos no mapa, evitando a perda de
tempo com informações de imóveis que não se encaixam no seu perfil de interesses.

Figura 2.8 - Tela de resultado (navegador desktop Mozilla Firefox 6.x).

12
Aplicações Web Foursquare People’s Garden Cadê Meu Apê
Ferramentas
Google maps Sim Sim Sim
GPS Sim Não Não
Ficheiros JON Sim Não Não
Javascript libraries Sim Sim Sim
Banco de dados SQL Não Sim Não
JQUERY mobile Não Não Sim
HTML5 e CSS Sim Sim Sim
Serviços
Autenticação do usuário Sim Não Não
Localização actual Sim Não Não
Pesquisar locais específicos Sim Sim Sim
Compartilhar localização actual Sim Não Não
Navegadores
Microsoft Internet Explorer Sim Sim Sim
Google Chrome Sim Sim Sim
Mozilla Firefox Sim Sim Sim
Plataformas
WEB Sim Sim Sim
Android Não Não Sim

Tabela 2.1 – Tabela comparactiva do estado da arte.

2.2. Conclusão do capítulo


O estado da arte é extremamente importante para dar-nos luzes no desenvolvimento de um
trabalho científico, neste capitulo foi apresentado de forma resumida e explicita como alguns
projectos com o mesmo objecto foram criados. Apesar de feitos utilizando algumas ferramentas
diferentes apresentam um mesmo objectivo que é criar um aplicativo de geolocalização
utilizando a API do Google Map, servindo assim de apoio para o desenvolvimento do aplicativo
Kudissanga Multicaixa.

13
Capítulo 3

Estudo das Tecnológias

3.1. Considerações Iniciais

Actualmente existem varias ferramentas disponíveis para o desenvolvimento de aplicações web


e não só, que visam facilitar o desenvolvedor de aplicativos. Nesta secção será feita uma
abordagem sobre as ferramentas utilizadas para o desenvolvimento do aplicativo.

3.1.1. Google Maps

Google Maps é um serviço do Google que oferece uma poderosa tecnologia de mapas amigáveis
e informações de locais, incluindo a localização, informações de contatos e direções de
condução.

Segundo Erle e Gibson (2006), Google Maps foi desenvolvida inicialmente


por dois irmãos, Lars e Jens Rasmussen, co-fundadores de Where 2 Technologies
uma empresa dedicada a criação de soluções de mapeamento. A empresa foi
comprada pela Google em outubro de 2004, e logo depois os dois irmão criaram
Google Maps.

Antes de que tivesse uma API pública, alguns desenvolvedores descobriram


uma maneira de hackear Google Maps para incorporar os mapas ao seus próprios
sites, Isso levou a Google a conclusão que havia a necessidade de uma API pública,
e no início de 2005 nas principais localidades dos EUA e posteriormente se
expandiu e passou a servir de referência para a busca de endereços e pontos de
interesse nos demais centros urbanos de outras nações e continentes. Com o passar do tempo
adicionou novas funcionalidades aos usuários, gerando comodidade e facilidades nunca antes
oferecidas, que vão desde o cálculo de rotas, visualização 3D de ruas e edificações, até
informações sobre tráfego, sobre o transporte público, ATM´s, e lojas.

Para Purvis e Sambells (2006), o grande sucesso e aceitação dos usuários,


fez com que pouco depois do lançamento oficial do Maps, foi lançada a sua API (Application
14
Programming Interface), que permite aos usuários inserir mapas em suas páginas web, contando
com a possibilidade de personalização e customização dos mapas como bem entenderem.

Para Erle e Gibson (2006), a funcionalidade principal do Google Maps é a


exibição de um mapa no website, partindo de uma coordenada que é exibida
centralizada na tela. Só isso já basta para usuários que buscam ajuda para
localização de ruas e regiões aos redores do endereço fornecido. Como meio de facilitar o
entendimento por parte do usuário a visualização do mapa pode ser feita tanto do modo
cartográfico (onde aparecem as ilustrações das ruas e quadras), como do modo
satélite (exibe uma imagem aérea da área selecionada).

Google Maps é o aplicativo de serviço livre e tecnologia para mapeamento


web fornecido pela empresa Google. Antes do Google Maps, era difícil de pesquisar
ou planejar uma viajem por meio de a pé, carro ou ônibus. Mas o Google Maps torna
mais fácil, oferecendo os mapas de ruas para viajar a pé, de carro ou transporte
público, fornece três visualizações diferentes. Existe uma visualização do mapa
normal, uma vista de imagem por satélite e uma vista terra (Google Earth) para
visualizar imagens e terrenos em 3D para poder obter uma vista panorâmica dessas
imagens e incliná-las, dependendo da necessidade do utilizador. Ela não só fornece altamente
receptivo, interface de mapeamento intuitiva com dados detalhados de rua
incorporados, mas além disso, oferece aos usuários mapas controles embutidos nos
produtos, para ter total controle sobre a exibição de rua e mapa de navegação.

3.1.2. Firebase

O Firebase é uma plataforma 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 (Firebase Storage), banco de dados (Firebase
Realtime Database), hospedagem (Firebase Hosting) entre outros.

O Firebase Realtime Database que consistem em um banco de dados não-relacional localizado


na nuvem fornecido pela Firebase (FIREBASE DATABASE 2016). O termo NoSQL (banco
de dados não-relacional) foi primeiramente utilizado em 1998 como o nome de um banco de

15
dados relacional de código aberto que não possuía uma interface SQL. Seu autor, Carlo Strozzi,
alega que o movimento NoSQL "é completamente distinto do modelo relacional e, portanto,
deveria ser mais apropriadamente chamado "NoREL" ou algo que produzisse o mesmo efeito".

A principal vantagem dos bancos não relacionais é a escalabilidade, claro que o esquema rígido
dos bancos relacionais torna difícil, por exemplo, aumentar um nó em um cluster de banco de
dados, outra vantagem é a flexibilidade da estruturação que além de tornar a escalabilidade mais
fácil facilita a inserção e acesso aos dados. Outra característica que talvez possa ser vista como
vantagem é a manipulação de dados por APIs orientadas a objetos enquanto no modelo
relacional somente via SQL. Pode-se citar ainda, como desvantagem, a relativa imaturidade do
Nosql.

No começo de 2014 o Firebase anunciou o suporte ao AngularJS, oferecendo um módulo


(AngularFire) para o framework com alguns componentes e serviços que permitiriam integrar
aplicações web ao Back-End oferecido. Deste modo as funcionalidades de tempo-real
oferecidas pelo Firebase (sincrônia de dados por meio de websockets (MOZILLA, 2015c))
poderiam ser incorporadas aos ciclos de processamento de dados do AngularJS de modo
transparente ao desenvolvedor. No final de 2014 a equipe do Firebase foi integrada à Google.

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.

As principais funcionalidades da plataforma Firebase:

 Autenticação - suporte para autenticação de usuários via e-mail, Facebook, GitHub,


Google Sign-In e Twitter;

 Database - um banco de dados NoSQL utilizado para armazenar dados JSON;

 Hosting - uma CDN (Content Delivery Network) distribuída globalmente para servir
aplicações web;

 Messaging - o antigo Google Cloud Messaging (GCM) é o novo Firebase Cloud


Messaging (FCM);
16
 Offline - possibilita a armazenagem de dados na memória cache local, permitindo assim
o funcionamento da aplicação em estado offline;

 Real time - os dados são armazenados em tempo real no banco de dados;

 Storage - armazena as mídias do usuário, como áudio, imagens e vídeos;

 Synchronization - quando os dados são alterados em um dispositivo eles são enviados


para o Firebase e então para todos os dispositivos conectados. Caso existam dispositivos
offline neste momento os mesmos serão atualizados com a última versão dos dados logo
após a conexão com a internet;

3.1.3. Angular 2

Angular é uma plataforma para construir aplicações de cliente em HTML e JavaScript ou uma
linguagem como TypeScript que compila JavaScript, por esse motivo hoje é uma das
ferramentas mais largamente utilizada para desenvolvimento web.

O Angular depende de recursos e funcionalidades fornecidos por uma variedade de pacotes de


terceiros. Esses pacotes são mantidos e instalados com o Node Package Manager (NPM).
Node.js e NPM são conhecidos como gerenciadores de pacotes do angular e são essenciais para
o desenvolvimento Angular.

O Angular possui, entre seus desenvolvedores, dois modos principais de organização de


projetos: Organização por componente ou Organização por funcionalidade. O primeiro modo
descreve que os diretórios do projeto devem ser estruturados para guardar todos os componentes
semelhantes na mesma pasta, deixando por exemplo todos os controladores na pasta
Controladores e todas as diretivas na pasta Diretivas. O segundo modo descreve que
funcionalidades semelhantes devem ser armazenadas na mesma pasta, nomeadas pelo nome da
funcionalidade (KUKIC, 2014).

O Angular 2 é uma plataforma que permite desenvolver aplicações web e mobile, mantido pela
Google. Apesar de ser a segunda versão da plataforma, Angular 2 não é a continuação do
Angular 1 com melhores e novas funcionalidades, foi reescrito.

17
Os principais componentes da plataforma:

 Componentes,
 Modulo,
 Templates,
 Serviços,
 Validação de formulários,
 Roteamento (SPA - Single Page Application).

Algumas vantagens do Angular 2:

 Extremamente declarativo, sendo muito fácil entender o funcionamento das aplicações


lendo apenas o HTML.
 O Angular 2 foi criado para que o desenvolvedor possa escrever o mínimo de código
possível.
 Esta plataforma cria, actualiza e destrói componentes à medida que o usuário se move
através do aplicativo.
 Permite a e interação de forma dinâmica com vários componentes da aplicação.

3.1.4. HTML (Hyper Text Markup Language)

Para Fernandes (2008), através da World Wide Web é possível acessar informações
armazenadas em documentos escritos usando-se uma linguagem chamada Hyper Text Markup
Language (HTML). Esta linguagem, inventada por Tim Berners-Lee no Laboratório CERN na
Suíça, é composta por comandos através dos quais é possível definir a aparência e a estrutura
de documentos.

O HTML 5 (Hypertext Markup Language) é a quinta versão da linguagem HTML. Esta nova
versão traz consigo importantes mudanças quanto ao papel do HTML no mundo da web,
trazendo novas funcionalidades como semântica e acessibilidade, com novos recursos antes só
possíveis por meio de outras tecnologias, e trazendo uma importante disseminação dentre todos
os novos navegadores de internet, tornando-o dessa forma mais universal.

De acordo com Martins (2010), após dez anos sem atualizações, a forma como se escreve
páginas na Internet passa por uma significativa transformação. O HTML5 oferece uma

18
experiência web totalmente diferente para usuários tornando a navegação mais rápida, simples
e melhorando a performance de uma página web, embora exista um longo caminho para ser
finalizado, muitos navegadores importantes já implementaram grandes partes da linguagem.

É importante mencionar que o HTML5 ainda está em desenvolvimento e aos poucos passará
por mudanças. Devido a suas capacidades tão impressionantes e alto padrão, podemos dizer
com alguma segurança que qualquer coisa envolvendo HTML5 terá um grande impacto na
internet.

3.1.5. Typescript

O Typescript foi desenvolvido pela Microsoft e é uma versão de Javascript que suporta
funcionalidades como classes no estilo da Orientação a Objetos, bem parecido com o que temos
em Java e C#. É considerada uma linguagem de programação livre e open-source, ou seja,
qualquer pessoa é livre para usar, copiar, estudar e mudar o software de qualquer forma, e o
código-fonte é compartilhado abertamente para que as pessoas sejam encorajadas a
voluntariamente melhorar a concepção do software.

3.1.6. Visual Studio Code

O Visual Studio Code é um editor de código-fonte desenvolvido pela Microsoft para Windows,
Linux e macOS. Ele inclui suporte para depuração, controle Git incorporado, realce de sintaxe,
complementação inteligente de código, snippets e recfatoração de código. Ele também é
customizável, fazendo com que os usuários possam mudar o tema do editor, teclas de atalho e
preferências.

O Visual Studio Code foi anunciado, com uma versão de previsão lançada, em 29 de abril de
2015 pela Microsoft na conferência Build de 2015. Em 18 de novembro de 2015, o Visual
Studio Code foi lançado sob a Licença MIT e o seu código-fonte foi postado no GitHub. Suporte
para extensões também foi anunciada. Em 14 de abril de 2016, o Visual Studio Code concluiu
o estágio de previsão pública e foi lançado para a web. A tabela a seguir mostra de maneira
explicita a diferença entre o Visual Studio Code e o Visual Studio.

19
Tabela 3.1 Diferença entre visual studio code e visual studio.

O visual studio code tem como principais características Multi-Platforma, Git integrado,
Highlighting da sintaxe e autocomplete, Funcionalidades para debugging e Suporte para várias
linguagens de programação.

A principal vantagem do visual studio code é a grande capacidade de otimização de linhas,


fazendo com que os softwares sejam mais leves, eficientes e compatíveis com diferentes
plataformas.

3.1.7. Bootstrap

Bootstrap é um framework de desenvolvimento web Front-End criado no Twitter em 2010 que


oferece uma série de componentes e comportamentos desenvolvidos com JQuery
(BOOTSTRAP, 2015). O framework oferece diversas classes CSS para manipular o conteúdo
estático da página de modo que esta se adapte a qualquer dispositivo de navegação, seja o
celular, tablet ou desktop. Este framework contribuiu para o desenvolvimento da aplicação por
oferecer uma série de novas directivas HTML.

3.2. Conclusão do capítulo


Neste capítulo foram abordados os conceitos, vantagens e características das principais
ferramentas usadas no desenvolvimento do aplicativo Kudissanga Multicaixa. Foram
escolhidas ferramentas actualizadas e com um grande desenvolvimento tecnológico afim de
obter da melhor maneira possível os resultados esperados.

20
Capítulo 4

Sistema Kudissanga Multicaixa

4.1. Considerações Iniciais


Neste capítulo ilustraremos os módulos do sistema, requisitos funcionais e não funcionais,
diagrama de caso de uso, hierárquico de funções, diagrama de actividade, diagrama de
sequência, diagrama colaboração, tal como os modelos de interface do mesmo.

4.2. Descrição do Sistema

O Kudissanga Multicaixa é um aplicativo desenvolvido para auxiliar os utilizadores de


multicaixas da cidade de Luanda. Onde o foco principal é ajudar os mesmos utilizadores com
informações sobre o estado actual dos multicaixas, além disso mostrar as rotas disponíveis para
chegar ao multicaixa desejado através da localização actual da pessoa ou através de uma origem
a sua escolha.

4.3. Módulos do Sistema

O sistema em questão esta estruturado em dois módulos fundamentais módulo administrativo


e módulo utilizador.

4.3.1. Módulo Administrativo

Este modulo é responsável pela administração do sistema, tem como funções são:

 Gestão dos marcadores dos multicaixas no mapa: responsável por criar, eliminar e
alterar o estado actual dos marcadores.
 Gestão dos funcionários: responsável por criar e eliminar os funcionários.
 Gestão de perfil: alterar a sua senha.

21
4.3.2. Módulo Utilizador

Este módulo inclui todos os utilizadores do sistema, as suas funções são:

 Gestão dos marcadores dos multicaixas no mapa: alterar o estado actual dos
marcadores.
 Gestão de perfil: alterar a sua senha.

4.4. Análise de requisitos

Requisitos são as capacidades e condições que o sistema deve atender, dos quais podem
classificados em funcionais e não-funcionais. Sendo assim nesta sessão ser apresentada as
funcionalidades do sistema necessárias para alcançar os objectivos desejados.

4.4.1. Requisitos funcionais

Os requisitos funcionais são responsáveis por descrever as funcionalidades do software.

Na tabela 4.1, são apresentados os requisitos funcionais do sistema.

Identificador Descrição Módulo


RF01 O sistema deve permitir criar e eliminar os marcadores Administrador
de multicaixas.
RF02 O sistema deve permitir alterar o estado actual dos Administrador
multicaixas.
RF03 O sistema deve permitir alterar a sua senha. Administrador
e Utilizador
RF04 O sistema deve permitir visualizar o mapa com os Administrador
marcadores de multicaixas de todos os municípios ou de
e Utilizador
um município especifico.
RF05 O sistema deve permitir ao clicar no marcador do Administrador
multicaixa visualizar as informações do mesmo
e Utilizador
(endereço, estado actual).
RF06 O sistema deve permitir ao utilizador criar, eliminar a Utilizador
sua conta.
RF06 O sistema deve disponibilizar a visualização da Utilizador
localização actual do utilizador.

22
RF07 O sistema deve permitir ao utilizador visualizar e enviar Utilizador
mensagens com os outros utilizadores da aplicação.
RF08 O sistema deve permitir ao utilizador visualizar uma rota Utilizador
através da sua localização actual para o multicaixa
desejado.
RF09 O sistema deve permitir ao utilizador visualizar uma rota Utilizador
através de uma origem especifica para o multicaixa
desejado.

Tabela 4.1 - Requisitos Funcionais do sistema.

4.4.2. Requisitos não funcionais

Os requisitos não funcionais descrevem os requisitos de desempenho e outros requisitos


necessários para que o software atinja a qualidade desejada.

Na tabela 4.2, são apresentados alguns requisitos não funcionais do sistema.

Identificador Descrição Classificação


dos requisitos
RNF01 O acesso as principais funcionalidades do sistema Segurança
serão restritas por e-mail e senha.
RNF02 Compatibilidade com sistemas operacionais Compatibilidade
Windows.

RFN03 A aplicação deverá funcionar em qualquer Portabilidade


navegador web compatível com HTML 5 .

RFN04 O sistema deve possuir uma interface gráfica Usabilidade


simples e intuitiva.

Tabela 4.2 – Requisitos não Funcionais do sistema.

23
4.4.3. Diagrama Casos de Uso

Segundo Ivar Jacobson, podemos dizer que um caso de uso é um "documento narrativo que
descreve a sequência de eventos de um ator que usa um sistema para completar um processo",
sendo que, o caso de uso representa uma unidade discreta da interação entre um usuário
(humano ou máquina) e o sistema.

Ele tem como objectivo ilustrar em um nível alto de abstração quais elementos externos
interagem com que funcionalidades do sistema, ou seja, a finalidade de um diagrama de caso
de uso é apresentar um tipo de diagrama de contexto que apresenta os elementos externos de
um sistema e as maneiras segundo as quais eles as utilizam.

Figura 4.1 – Diagrama de caso de uso do sistema.

A figura 4.1 ilustra o diagrama de caso de uso geral do sistema Kudissanga Multicaixa, com
objectivo de mostrar de uma maneira clara e objectiva os principais actores do sistema e as suas
respectivas funções.

24
4.4.3.1. Narração de casos de uso

Método extensivo do diagrama de caso de uso que tem como finalidade explicar o mesmo, de
modo que cite as trajectórias percorridas e as possibilidades do sistema. Através da narração de
caso de uso é possível ilustrar de forma detalhada o objectivo do sistema, os actores, os dados
envolvidos, os fluxos principais e alternativos.

Descrição: Criar conta.

Actor: Usuário

Objectivo: Este caso de uso permite ao usuário criar sua conta no sistema.

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


Fluxo Principal

Acção do Actor Resposta do sistema


1: O caso de uso começa quando o Usuário
acessa o sistema.

2: O Usuário acede a tela de registro e


informa os seus dados.
3: O sistema verifica os dados.

4: O sistema cria nova conta.


Fluxo Alternativo

3A Dados incorrectos:
1. O usuário reinicia o processo de registro.

Tabela 4.3 – Descrição do caso de uso Criar conta.

A tabela 4.3 descreve o caso de uso criar conta com o intuito de mostra as funcionalidades do
sistema do ponto de vista do usuário.

25
Descrição: Processo de alteração do estado do multicaixa.

Actor: Administrador

Objectivo: Este caso de uso permite ao Administrador alterar o estado do multicaixa.

Pré-Condições: O Administrador deve estar autenticado.

Pós-Condições: O novo estado do marcador de multicaixa será armazenado na base de


dados do sistema.
Fluxo Principal

Acção do Actor Resposta do sistema


1: O caso de uso começa quando o
Administrador informa os seus dados para
autenticação.
2: Validar Autenticação.

3: O Administrador acede a tela do mapa e


escolhe o marcador desejado.

4: O Administrador acede a tela de ATM


informação e escolhe um novo estado.
5: O sistema actualiza o multicaixa com o
novo estado.
Fluxo Alternativo

2A Dados incorrectos:
1. O Administrador reinicia o processo de autenticação.

Tabela 4.4 – Descrição do caso de uso Alterar estado do multicaixa.

A tabela 4.5 descreve o caso de uso Alterar estado do multicaixa com o intuito de mostra as
funcionalidades do sistema do ponto de vista do usuário.

26
Descrição: Processo de solicitação de rota.

Actor: Usuário

Objectivo: Este caso de uso permite ao usuário solicitar uma rota no sistema.

Pré-Condição: O Usuário deve estar autenticado.


Fluxo Principal

Acção do Actor Resposta do sistema


1: O caso de uso começa quando o Usuário
informa os seus dados para autenticação.

2: Validar Autenticação.
3: O Usuário acede a tela do mapa.
4: O usuário escolhe a origem e o destino
desejado e solicita a rota. 5: O sistema verifica os dados.

6: O sistema envia a rota solicitada.

Fluxo Alternativo
2A Dados incorrectos:
1. O usuário reinicia o processo de autenticação.
3A Como origem a sua localização actual:
1. O usuário deve clicar no botão para ter como origem a sua localização actual.
5A Dados incorrectos:
1. O usuário reinicia o processo de solicitação de rota.

Tabela 4.5 – Descrição do caso de uso solicitar rota.

A tabela 4.6 descreve o caso de uso solicitar rota com o intuito de mostra as funcionalidades do
sistema do ponto de vista do usuário.

27
4.4.4. Diagrama de Actividade

Nesta sessão são apresentados os diagramas de actividades dos módulos do kudissanga


Multicaixa. Este diagrama é essencialmente um gráfico de fluxo, mostrando o fluxo de controle
de uma atividade para outra.

Figura 4.2 – Diagrama de actividade do caso de uso criar conta.

A figura 4.2 representa o diagrama de actividade do caso de uso criar conta desempenhada pelo
usuário. A actividade começa quando o usuário clica no menu Entrar, em seguida o sistema
abre a tela de Login, quando o usuário visualiza a tela ele clica no botão Novo Usuário,
posteriormente o sistema mostra a tela de registro. O usuário preenche o formulário de registro,
caso os dados estiverem correctos o sistema habilita o botão Salvar e usuário clica no mesmo,
caso o usuário não exista no sistema, o sistema salva automaticamente os dados do usuário na
base de dados.

28
Figura 4.3 – Diagrama de actividade do caso de uso Alterar estado.

A figura 4.3 representa o diagrama de actividade do caso de uso Alterar estado desempenhada
pelo Administrador. A actividade começa quando o administrador autentica-se ao sistema, caso
os dados estejam correctos o sistema exibe a tela do Mapa. O administrador no mapa clica no
marcador de multicaixa que deseja alterar o estado, em seguida o sistema mostra a janela de
informação do mesmo, posteriormente o administrador clica na opção alterar estado e o sistema
abre a tela de ATM informação. Nesta tela existe duas opções de estado para alterar, estado da
maquina e estado de lotação, o administrador escolhe um dos ícones e o sistema mostra uma

29
nova sessão que permitirá ao administrador escolher um novo estado para o multicaixa, o
administrador ao clicar no botão Confirmar o sistema envia a opção escolhida para a base de
dados, em seguida a base de dados actualiza o estado do multicaixa.

Figura 4.4 – Diagrama de actividade do caso de uso Solicitar rota.

A figura 4.4 representa o diagrama de actividade do caso de uso Solicitar rota desempenhada
pelo Usuário. A actividade começa quando o Usuário autentica-se ao sistema, caso os dados
estejam correctos o sistema exibe a tela do Mapa. Em seguida o usuário preenche o campo da
origem, caso queira que a origem seja a sua localização actual é necessário clicar do botão da
localização actual e em seguida o sistema irá preencher o campo da origem com a sua
localização actual, o usuário também tem que preencher o campo do destino. Ao clicar no botão
Mostrar rota o sistema desenha a rota no mapa e mostra o a duração de tempo para chegar no
destino e a explicação da rota.

30
4.4.5. Diagrama de Sequência

Mostram a sequência em que os eventos ocorrem em um determinado processo. É também um


diagrama de objetos que mostra o envio de mensagens entre eles. Um diagrama de sequência
preocupa-se com a ordem temporal em que as mensagens são trocadas e pode ser usado para
detalhar um Caso de Uso.

Figura 4.5 – Diagrama de actividade do caso de uso Alterar estado.

A figura 4.5 representa o diagrama de sequência do caso de uso Alterar estado esta acção
pode ser realizada tanto pelo usuário como para o administrador. Antes de dar inicio a este
processo o utilizador deve estar autenticado e posteriormente poderá alterar a informação
do estado actual do multicaixa, esse estado pode ser o estado actual da máquina ou o estado
actual da lotação. A figura acima, ilustra a sequência necessária para efectuar com sucesso
a alteração do estado do multicaixa.

31
Figura 4.6 – Diagrama de actividade do caso de uso Criar conta.

A figura 4.6 representa o diagrama de sequência do caso de uso Criar conta, esta acção é
realizada pelos usuários que não têm uma conta de acesso ao sistema e desejam tem acesso a
outras funcionalidades do sistema como, alterar estado do multicaixa e entrar na sala de bate-
papo. A figura acima, ilustra a sequência necessária para efectuar com sucesso um novo registro
no sistema.

Figura 4.7 – Diagrama de actividade do caso de uso Solicitar rota.


32
A figura 4.7 representa o diagrama de sequência do caso de uso Solicitar rota. Esta acção é
realizada apenas pelo usuário, e não pelo administrador. A mesma, tem como finalidade mostrar
ao usuário a rota necessário para sair de um determinado ponto para o outro, além disso o
sistema disponibiliza o tempo necessário para chegar ao destino e uma explicação breve das
direções.

4.4.6. Diagrama de Colaboração

O diagrama de colaboração mostra, de maneira semelhante ao diagrama de sequência, a


colaboração dinâmica entre os objetos. Exibe uma interação, consistindo de um conjunto
de objetos e seus relacionamentos, incluindo as mensagens que podem ser trocadas entre
eles. O diagrama de colaboração também é um diagrama de interação.

Figura 4.8 – Diagrama de colaboração do caso de uso Criar conta.

A figura acima ilustra através do diagrama de colaboração do caso de uso Criar conta, a
colaboração dinâmica que existe entre os objetos, desde a sua estrutura até as mensagens que
trocam entre si no processo de criação de conta.

33
Figura 4.9 – Diagrama de colaboração do caso de uso Solicitar rota.

A figura 4.11 ilustra através do diagrama de colaboração do caso de uso Solicitar rota, a
colaboração dinâmica que existe entre os objetos, desde a sua estrutura até as mensagens que
trocam entre si no no acto de solicitação de rota.

Figura 4.10 – Diagrama de colaboração do caso de uso Alterar estado.

A figura 4.13 ilustra através do diagrama de colaboração do caso de uso Alterar estado, a
colaboração dinâmica que existe entre os objetos, desde a sua estrutura até as mensagens que
trocam entre si no no processo de alterar o estado actual do multicaixa.

34
4.5. Protótipo do sistema

Nesta sessão apresenta-se o protótipo do sistema que visa ajudar o usuário a ter uma ideia de
como o sistema irá parecer, e facilita a tomada de decisões no projeto sem esperar que o sistema
seja construído. Será ilustrado a constituição da base de dados do sistema a partir do desenho
de dados, diagrama de classes, desenho de software, desenho de hardware e o DHF.

4.5.1. Modelo Conceitual

Consiste em demonstrar como serão construídas as estruturas de dados que darão suporte aos
processos de negócio, como esses dados estarão organizados e quais os relacionamentos que
pretendemos estabelecer entre eles, facilitando o seu entendimento e desenvolvimento.

Neste relatório não será apresentado um modelo de conceitual (modelo lógico) porque diferente
de uma base de dados SQL Normalizada o Firebase não utiliza chave primária, nem chave
estrangeira para representar as relações entre as entidades, embora existe interação entre as
entidades não devemos representa-lo com o modelo conceitual.

4.5.2. Diagrama de classes

É uma modelagem muito útil para o desenvolvimento de sistemas, pois define todas as classes
que o sistema necessita possuir. Este diagrama é composto por classes (atributos e métodos) e
associações.

Interpretação do diagrama de classes ilustrado abaixo:

 Um utilizador envia uma ou varias mensagens;


 Uma mensagem é envia apenas por um utilizador;
 Um utilizador pode alterar o estado de nenhum ou vários marcadores de multicaixa;
 Um marcador de multicaixa pode ser alterado por um ou vários utilizador;
 Um Funcionário gere um ou vários marcadores de multicaixa;

35
Figura 4.11 – Diagrama de classes do sistema Kudissanga Multicaixa.

A figura 4.11 ilustra o diagrama de classes do sistema, procurando estabelecer, de forma


sintética, as classes e seus relacionamentos.

36
4.5.3. Mapeamento de SQL (Modelo Relacional) para NoSQL

Diferente do banco de dados SQL, no NoSQL não há nenhum esquema para o banco de dados.
O constante crescimento da tecnologia em geral, tem feito os desenvolvedores reavaliarem
como eles armazenam e mantém esses dados. Os bancos de dados precisam
prover escalabilidade, flexibilidades, segurança e eficiência para o massivo fluxo de dados que
vivemos.

Desenvolvedores especialistas analisam a dificuldade, às vezes a impossibilidade,


de utilizar modelos relacionais para armazenar todos esses dados mantendo uma escalabilidade
dinâmica e a performance necessária com o aumento dos dados.

É 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 nos
objectos sem nos preocuparmos com a definição de tabelas e de seus relacionamentos. 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. Isto permite um
ganho de desempenho quando tratamos de aplicações mais complexas e com grandes volumes
de dados e usuários.

Figura 4.12 - Entidade usuário representada na base de dados Firebase – mapit.

37
Figura 4.13 - Entidade markers (marcadores de multicaixa) representada na base de dados Firebase – mapit.

4.5.4. Desenho de software

Nesta sessão apresenta-se o desenho do software do sistema ilustrado através da arquitetura de


software que mostra como esta configurado o hardware e o software dentro do sistema. É
importante saber desta configuração porque permite visualizar a estrutura ou o comportamento
de um sistema.

Figura 4.14 – Arquitetura de software do sistema Kudissanga Multicaixa.

38
Para o Desenvolvimento do sistema foi adoptada a arquitectura em 3 camadas como mostra a
figura 4.14, onde utilizamos respectivamente a camada de apresentação, a camada de negócio
e a camada de acesso a dados.

 A camada de apresentação (interface do usuário ou apresentação), é a camada


responsável pela exibição das informações, e é utilizada pelo usuário para acessar a
aplicação.
 A camada de negócio é a camada intermediária entre o utilizador e o back-end. 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.
 A camada de acesso a dados é conhecida como camada 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.

4.5.5. Desenho de Hardware

Nesta sessão será apresentada a infraestrutura tecnológica de suporte ao software bem como os
equipamentos de hardware que a compõem.

Figura 4.15 – Arquitetura de hardware do sistema Kudissanga Multicaixa.

39
A figura 4.15 apresenta a estrutura de hardware do sistema mediante a ilustração dos seus
equipamentos físicos. Temos o computador como o equipamento eletrônico que recebe as
informações e através da internet envia para o servidor de aplicação, esse por sua vez processa
as informações, e em seguida essas informações são enviadas para o servidor de base de dados
que por sua vez armazena e devolve os dados de saída para o servidor de aplicação que
posteriormente envia para o utilizador.

4.5.6. Modelo Arquitectural

Será apresentado nesta sessão o DHF que define a arquitetura global de um programa ou
sistema, mostrando os módulos e suas inter-relações. É importante lembrar que um DHF pode
ser usado como um guia para o projeto das interfaces com o usuário, apoiando a definição de
janelas, estrutura de menus etc.

A figura a seguir ilustra o diagrama hierárquico de funções do sistema Kudissanga Multicaixa


representando os seus módulos e as suas respectivas funções.

Figura 4.16 – Diagrama Hierárquico de Funções do sistema Kudissanga Multicaixa.

40
4.6. Conclusão do Capítulo
As principais diretrizes para o desenvolvimento de um sistema referem-se à forma de
representação da informação a fim de torná-la acessível e de fácil compreensão e análise para
as pessoas interessadas. Neste capítulo foram abordados os aspectos concernentes ao sistema,
os módulos e os diagramas que serviram de guia para o desenvolvimento do sistema Kudissanga
Multicaixa.

41
Capítulo 5

Considerações Finais

5.1. Conclusões
Este trabalho apresentou uma aplicação que teve como objectivo solucionar algumas
dificuldades que geralmente os utilizadores de multicaixas encontram quando pretendem
usufruir dos benefícios do mesmo. Para a concretização deste objectivo foram avaliados
sistemas com objectivos similares de modo a obter melhores conteúdos, que serviram de apoio
para o desenvolvimento da aplicação.

O sistema Kudissanga Multicaixa foi projectado de modo a melhorar alguns projectos de


localização já existentes, focando-se na localização de multicaixas. Visto que alguns sistemas
já implementados disponibilizam apenas os multicaixas existentes em diversas áreas, o sistema
Kudissanga Multicaixa além de mostrar os multicaixas disponíveis irá disponibilizar
informações sobre o estado actual do mesmo.

Esse trabalho permitiu verificar que pode ser desenvolvido um sistema que use serviços
disponíveis gratuitamente na Internet, deixando a aplicação com bom desempenho em tempo
real, a utilização API do Google Maps foi primordial para o desenvolvimento desta aplicação.

A realização deste trabalho permitiu a consolidação do conhecimento adquirido durante o curso


de Engenharia Informática, permitiu obter experiências na área de desenvolvimento de software
e mostrar que é possível a integração de múltiplas tecnologias em ambientes e plataformas
diferentes para o desenvolvimento de um mesmo sistema.

É de referir que, este sistema irá melhorar de forma considerável o dia-a-dia de muitos
utilizadores dos ATMs, evitando deslocações desnecessárias.

5.2. Dificuldades
Durante o desenvolvimento do sistema Kudissanga Multicaixa a maior dificuldade que eu
encontrei foi o pouco conhecimento das ferramentas e linguagens de programação escolhidas
para o desenvolvimento da aplicação, mais com empenho e dedicação consegui cumprir com
os objectivos esperados.
42
5.3. Trabalhos Futuros
Para o trabalho futuro pretende-se dar continuidade no desenvolvimento do projecto de
maneiras a contribuir para a melhoria do mesmo. Para tal, sugere-se as seguintes melhorias:

 Cria um design responsivo para que a pagina possa ser acessada independentemente do
tamanho da tela do usuário;
 Melhorar a interação entre os utilizadores da aplicação (o chat);
 Ter opção de salvar os multicaixas em uma seção de “Favoritos”, para que no futuro seja
consultado o seu estado com facilidade.

5.4. Recomendações
Para o usuário obter a melhor experiência possível com a aplicação é importante ter em conta
algumas recomendações:

 Para o melhor desempenho de sistema recomenda-se que o usuário tenha acesso a


internet;
 É indispensável garantir que o seu navegador de Internet tenha como linguagem
predefinida o Português, devido as informações do caminho da rota que o Google map
mostra;
 Para execução de algumas funcionalidades é importante disponibilizar a sua localização
actual.

43
Referências Bibliográficas

SCHMITT. Peterson. Aplicação web utilizando api google maps. In: Dissertação para a
obtenção do título de Tecnólogo no Curso Superior de Tecnologia em Análise e
Desenvolvimento de Sistemas, da Universidade Tecnológica Federal do Paraná, Campus
Medianeira. MEDIANEIRA. 2013.

LUPCHINSKI, R. Desenvolvimento de uma Aplicação de Página-Única e Banco de Dados


Não-Relacional para Organização e Controle de Eventos Esportivos. In: Monografia
apresentada como requisito parcial para a obtenção do grau de Bacharel em Ciência da
Computação. UNIVERSIDADE FEDERAL DO RIO GRANDE DO SUL. Porto Alegre, 2015.

Felipe, L. H.; Dias, W. J. Aplicações baseadas em geolocalização. In: investigação cientifica


sobre aplicações baseadas em geolocalização. Universidade Paranaense (Unipar) Paranavaí –
PR – Brasil.

HOLDENER, A. T. HTML5 Geolocation. United States of America: Simon St. Laurent, 2011.
103 p.

UDEMY- Aprenda Angular 2 e 4 com TypeScript. Disponível em:


< https://www.udemy.com/aprenda-angular-2-com-typescript/learn/v4/overview>
[Online: acessado 15 de Janeiro de 2017].

ANGULAR –Typescript. Disponível em: <https://angular.io/docs/ts/latest/ quickstart.html>.


[Online: acessado 10 de Janeiro de 2017].

GITHUB – The official library for Firebase and Angular 2. Disponível em:
<https://github.com/angular/angularfire2> . [Online: acessado 10 de Fevereiro de 2017].

GITHUB. loiane.training.Angular 2017. Disponível em


< https://github.com/loianetraining/ementas/blob/master/angularjs2.md>. [Online:
Acessado 20 de Março de 2017].

GOOGLE. Google Maps Api. Disponível em


<http://code.google.com/intl/ptBR/apis/maps/documentation/>. [Online: Acessado 19 de
Janeiro de 2017].

GOOGLE. Google Maps Api Places. Disponível em


<https://developers.google.com/maps/documentation/javascript/places#place_searches>
[Online: Acessado 19 de Janeiro de 2017].

44
FIREBASE. About Firebase. 2009.Disponível em
<https://www.firebase.com/about.html>. [Online:Acessado 28 de Janeiro de 2017].

CRIARWEB. Desenvolvimento com o API de Google Maps.


<http://www.criarweb.com/desenvolvimento-google-maps/> [Online: Acessado 28 de Janeiro
de 2017].

FIREBASE. Retrieving Data. 2009. Disponível em


<https://www.firebase.com/docs/web/guide/retrieving-data.html>. [Online: Acessado 15 de
Fevereiro de 2017].

FIREBASE. Features. 2009. Disponível em <https://www.firebase.com/features.html>.


[Online:Acessado 15 de Fevereiro de 2017].
HTML5 - Um guia de referência para os desenvolvedores web. Disponível em:
<http://tableless.com.br/html5/> [Online:Acessado 25 de Fevereiro de 2017].

GOOGLE - Preenchimento automático para endereços e termos de pesquisa.


Disponível em:
<https://developers.google.com/maps/documentation/javascript/placesautocomplete>
[Online:Acessado 10 de Abril de 2017].

BANCOSDEANGOLA. Multicaixas. Disponível em:


<file:///C:/Users/PC/Desktop/projecto_2017/Relatorio/Portal%20%E2%80%93%20Bancos%
20de%20Angola%20-%20%E2%80%93%20Multicaixa.html>
[Online:Acessado 19 de Abril de 2017].

EMIS. CartãoMulticaixa-Relatório da Merktest. Disponível em:


<http://www.emis.co.ao/publicacoes>. [Online:Acessado 30 de Abril de 2017].
NPM. NPM - Node Package Manager. 2009. <https://docs.npmjs.com/getting-started/
what-is-npm>. [Online: acessado 15 de Janeiro de 2017].

EDUONIX. Learn To Build A Google Map App Using Angular 2. Disponível em:
<https://www.eduonix.com/courses/Web-Development/learn-to-build-a-google-map-app-
using-angular-2> . [Online: acessado 27 de Janeiro de 2017].

PILGRIM, M. Dive into HTML5: API DE GEOLOCALIZAÇÃO. 2010. Disponível


em: <http://diveintohtml5.com.br/geolocation.html>. [Online: acessado 22 de Março de 2017].

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


<http://www-di.inf.pucrio.br/~endler/courses/Mobile/Monografias/04/AdolfoCorreia-
Mono.pdf>. [Online: acessado 12 de Fevereiro de 2017].

45
PLUNKER. Angular 2 QuickStart with google map. Disponível em:
<http://plnkr.co/edit/YX7W20?p=preview> . [Online: acessado 27 de Março de 2017].

ANGULAR2-GOOGLE-MAPS. Playing with angular2-google-maps. Disponível em:


<file:///C:/Users/PC/Documents/projecto_fim_curso/Getting%20started%20with%20angular2
-google-maps.html>. [Online: acessado 22 de Fevereiro de 2017].

SITEPOINF. Getting Started with Angular 2 using TypeScript. Disponível em:


<https://www.sitepoint.com/getting-started-with-angular-2-using-typescript/>.[Online:
acessado 22 de Janeiro de 2017].

ANGULAR.IO . A quick look at Angular basics. Disponível em:


<https://angular.io/docs/ts/latest/quickstart.html>. [Online: acessado 22 de Abril de 2017].

PROG BLOG. Angular 2 Firebase Tutorial Part 1: Create a Firebase 3 CRUD app with
Angular CLI. Disponível em: <https://progblog.io/Angular-2-Firebase-Tutorial-Part-1-
Create-a-Firebase-3-CRUD-app-with-Angular-CLI/>. [Online: acessado 30 de Abril de 2017].

CODINGTHESMARTWAY. Angular 2 + Firebase Introduction. Disponível em:


<http://codingthesmartway.com/angular-2-firebase-introduction/>. [Online: acessado 11 de
Fevereiro de 2017].

FREECODECAMP. Angular Authentication made easy with Firebase.Disponível em:


<https://medium.freecodecamp.com/angular-2-authentication-made-easy-with-firebase-
246c282d9ef8>. [Online: acessado 11 de Fevereiro de 2017].

LALIWALA, J. Getting Started with Angular 2. Disponível em:


<http://www.attuneww.com/wp-content/uploads/2016/09/GettingStartedWith
Angular2.pdf>. [Online: acessado 11 de Fevereiro de 2017].

BOOTSTRAP. About Bootstrap. Disponível em: <http://getbootstrap.com/about/>. [Online:


acessado 29 de Abril de 2017].

W3SCHOOLS. HTML5 Tutorial. Disponível em:


<https://www.w3schools.com/html/default.asp>. [Online: acessado 29 de Abril de 2017].

W3SCHOOLS. CSS Tutorial. Disponível em:


< https://www.w3schools.com/css/default.asp>. [Online: acessado 29 de Abril de 2017].

W3SCHOOLS. Bootstrap 3 Tutorial. Disponível em:


< https://www.w3schools.com/bootstrap/default.asp>. [Online: acessado 29 de Abril de 2017].

46
Anexos
Anexo A – Interfaces do sistema Kudissanga Multicaixa

Nesta sessão serão apresentados os modelos das interfaces do sistema, construído com auxílio
das ferramentas HTML, CSS e Bootstrap.

A.1 – Tela de inicio do sistema para usuário sem autenticação.

Figura A.1 – Tela de inicio do sistema Kudissanga Multicaixa.

Relacionamento com outras interfaces

Figura A.2 – Diagrama de relacionamento da tela de inicio com outras telas (sem autenticação).

47
Comandos

Nº Nome Descrição Requisitos de validade


1 Entrar Acede a tela de Login. Sempre válido.
2 Mapa Acede a tela do mapa Sempre válido.
3 Localizar por zonas Mostra uma caixa que permite
escolher uma determinada zona
para mostrar os multicaixas. Sempre válido.

4 Todas as zonas Mostra os multicaixas de todas as Sempre válido.


zonas.

Tabela A.1 – Descrição dos comandos da tela inicial do usuário sem autenticação.

A.2 – Tela inicial do usuário do sistema.

Figura A.3 – Tela inicial do usuário do sistema Kudissanga Multicaixa.

48
Relacionamento com outras interfaces

Figura A.4 – Diagrama de relacionamento da tela inicial do usuário com outras telas.

Comandos

Nº Nome Descrição Requisitos de validade


1 Mapa Acede a tela do mapa Sempre válido.
2 Localizar por zonas Mostra uma caixa que permite
escolher uma determinada zona Sempre válido.
para mostrar os multicaixas.
3 Todas as zonas Mostra os multicaixas de todas Sempre válido.
as zonas.
4 Bate-papo Acede a tela de bate-papo. Válido apenas para os
usuários do sistema
autenticados.
5 Perfil usuário Acede a tela de perfil do Válido para todos os
usuário. usuários autenticados.
6 ATM Info Acede a tela de informação do Válido para todos os
multicaixa. usuários autenticados.
7 Sair Termina a sessão no sistema. Válido para todos os
usuários autenticados.

Tabela A.2 – Descrição dos comandos da tela inicial do usuário.

Campos

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


1 Origem Origem da rota Obrigatório
2 Destino Destino da rota Obrigatório
Tabela A.3 – Descrição dos campos da tela inicial do usuário.

49
A.3 – Tela inicial do administrador do sistema.

Figura A.5 – Tela inicial do administrador do sistema Kudissanga Multicaixa.

Figura A.6 – Diagrama de relacionamento da tela inicial do administrador com outras telas.

50
Comandos

Nº Nome Descrição Requisitos de validade


1 Mapa Acede a tela do mapa Sempre válido.
2 Localizar por Mostra uma caixa que permite
zonas escolher uma determinada Sempre válido.
zona para mostrar os
multicaixas.
3 Todas as zonas Mostra os multicaixas de Sempre válido.
todas as zonas.
4 Criar ATM Acede a tela de criação de Válido apenas para o
marcador de multicaixa. administrador do sistema
autenticado.
5 Perfil usuário Acede a tela de perfil do Válido para todos os
usuário. usuários autenticados.
6 ATM Info Acede a tela de informação Válido para todos os
do multicaixa. usuários autenticados.
7 Sair Termina a sessão no sistema. Válido para todos os
usuários autenticados.

Tabela A.4 – Descrição dos comandos da tela inicial do administrador.

51
Figura A.7 – Tela de registro de marcador de multicaixa do sistema Kudissanga Multicaixa.

Figura A.8 – Diagrama de relacionamento da tela Criar ATM com outras telas.

52
Campos

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


1 Identificador do Identificador do Multicaixa Obrigatório
Multicaixa
2 Latitude Latitude do Multicaixa Obrigatório
3 Longitude Longitude do Multicaixa Obrigatório

4 Endereço do Endereço onde se encontra o Obrigatório


Multicaixa Multicaixa

5 Município Município onde se encontra o Obrigatório


Multicaixa
6 Banco pertencente O banco pertencente ao Obrigatório
Multicaixa
7 Estado actual da Estado actual da máquina Obrigatório
máquina

8 Estado actual da Estado actual da lotação do ATM Obrigatório


lotação do ATM

Tabela A.5 – Descrição dos campos da tela de registro de marcador de multicaixa.

Comandos

Nº Nome Descrição Requisitos de validade


1 Salvar Salvar os dados no Válido apenas quando os dados
sistema estiverem completos.
2 Cancelar Cancelar a criação do Sempre válido.
marcador
3 Mapa Acede a tela do mapa Sempre válido.

4 Perfil usuário Acede a tela de perfil Válido para todos os usuários


do usuário. autenticados.
5 ATM Info Acede a tela de Válido para todos os usuários
informação do autenticados.
multicaixa.

6 Sair Termina a sessão no Válido para todos os usuários


sistema. autenticados.

Tabela A.6 – Descrição dos comandos da tela de registro de marcador de multicaixa.

53
Figura A.9 – Tela do Administrador de Informação e gerência de marcador de multicaixa do sistema.

Figura A.10 – Diagrama de relacionamento da tela ATM Info com outras telas.

54
Comandos

Nº Nome Descrição Requisitos de validade


1 Alterar estado da Alterar estado da Válido para todos os usuários
máquina (botão máquina no sistema. autenticados..
Azul)
2 Alterar estado da Alterar estado da Válido para todos os usuários
Lotação (botão Lotação no sistema. autenticados.
laranja)
Eliminar marcador Eliminar marcador no Válido apenas para o administrador
(botão vermelho) sistema. do sistema autenticado.
3 Mapa Acede a tela do mapa Sempre válido.

4 Perfil usuário Acede a tela de perfil Válido para todos os usuários


do usuário. autenticados.
5 Criar ATM Acede a tela de criação Válido apenas para o administrador
de marcador de do sistema autenticado.
multicaixa.

6 Sair Termina a sessão no Válido para todos os usuários


sistema. autenticados.

Tabela A.7 – Descrição dos comandos da tela do Administrador de Informação e gerência de marcador de
multicaixa.

55
Anexo B – Trechos de códigos da Aplicação

Figura B.1 – Trecho de código Inserir Marcador de multicaixa no Mapa.

insertMarker(){
this.map=new google.maps.Map(document.getElementById("map_canvas"),this.myOptions);
(<HTMLInputElement>document.getElementById("directionsPanel")).innerHTML = "";
for (var i = 0; i < this.markers.length; i++) {
this.markers[i].setMap(null);
}
this.markers = [];

var map = this.map;


var lat;
var lng;
var infowindow = new google.maps.InfoWindow();

this.af.database.list('/markers/').subscribe(x => {

for (var i = 0; i < x.length; i++){


var image_status;
lat=x[i].latitude;
lng=x[i].longitude;
var municipio = x[i].municipio;
var endereco = x[i].endereco;
var key_marker=x[i].$key;
var banco=x[i].banco;
var estadoactual=x[i].estado;
var estadolot=x[i].estadolot;

if(x[i].estado=="Sem Dinheiro"){
image_status= 'assets/img/marker_amarelo.png';
}
if(x[i].estado=="Fora de Serviço"){
image_status= 'assets/img/marker_vermelho.png';
}
if(x[i].estado=="Sem Papel"){
image_status= 'assets/img/marker_cinza.png';
}
if(x[i].estado=="Sem Papel e Sem Dinheiro"){
image_status= 'assets/img/marker_laranja.png';
56
}
if(x[i].estado=="Em Serviço"){
image_status= 'assets/img/marker_verde.png';
}
this.marker = new google.maps.Marker({
position: new google.maps.LatLng(lat, lng),
icon: image_status,
animation: google.maps.Animation.DROP,
map: map

});
var info = "<a href='" + '#markerinfo' + "'>" + "alterar estado do Multicaixa" + "</a>";
google.maps.event.addListener(this.marker, 'click', (function(marker, i) {

var content = '<strong>Nome: </strong>'+key_marker+'<br>'+ '<strong>Latitude: </strong>'+lat


+'<br>' +'<strong>Longitude: </strong>'+lng +'<br>' +'<strong>Endereço:
</strong>'+endereco+'<br>'+ '<strong>Município: </strong>'+municipio +'<br>'+'<strong>Nome do
Banco: </strong>'+ banco+'<br>' + '<strong>Estado Atual do ATM:</strong> '+estadoactual+ '<br>' +
'<strong>Estado Atual da Lotação do ATM:</strong> '+estadolot+'<br>' +'<br>' + info +" do
"+key_marker;

return function () {
infowindow.setContent(content);
infowindow.open(map, marker);

}
})(this.marker, i)

);
this.markers.push(this.marker);
}
})
}

57
Figura B.2 – Trecho de código Criar marcador de multicaixa na base de dados.

onSubmit(formData) {
if(formData.valid) {

var ref = firebase.database().ref().child("markers");


var id_nome=(<HTMLInputElement>document.getElementById('id_nome')).value;

var data = {
latitude:(<HTMLInputElement>document.getElementById('latitude')).value,
longitude:(<HTMLInputElement>document.getElementById('longitude')).value,
endereco:(<HTMLInputElement>document.getElementById('endereco')).value,
municipio:(<HTMLInputElement>document.getElementById('municipio')).value,
banco:(<HTMLInputElement>document.getElementById('banco')).value,
estado:(<HTMLInputElement>document.getElementById('estado')).value,
estadolot:(<HTMLInputElement>document.getElementById('estadolot')).value,
usuario_alt:"euryferreira.eng@hotmail.com",

var alerta=this.toastr.success('Criado com Sucesso!','certo');


ref.child(id_nome).set(data).then(function(ref)
alerta;
}
, function(error) {
this.toastr.warning('Dados incorretos!', 'ERRO!');
});

}
}

58
Figura B.3 – Trecho de código Mostrar rota entre dois pontos.

initialize() {
this.insertMarker();
(<HTMLInputElement>document.getElementById("directionsPanel")).innerHTML
= "";
var rendererOptions = { draggable: false};
var directionsDisplay=new google.maps.DirectionsRenderer(rendererOptions);

directionsDisplay.setMap(this.map);
directionsDisplay.setPanel(document.getElementById("directionsPanel"));

var travelMode = google.maps.TravelMode.DRIVING;


var start =(<HTMLInputElement>document.getElementById('routeStart')).value;
var end =(<HTMLInputElement>document.getElementById('routeEnd')).value;
var request = {
origin: start,
destination: end,
travelMode: google.maps.DirectionsTravelMode[travelMode]
};

this.directionsService.route(request, function(response, status) {


if (status == google.maps.DirectionsStatus.OK) {
directionsDisplay.setDirections(response);
} else {
if (status == 'ZERO_RESULTS') {
alert('Não é possivel mostrar uma rota entre a origem e o destino! Verifique os
seus endereços');
} else if (status == 'UNKNOWN_ERROR') {
alert('solicitação de rotas não pôde ser processada devido a um erro no servidor.
A solicitação pode ser bem-sucedida se você tentar novamente.');
} else if (status == 'REQUEST_DENIED') {
alert('Esta página da Web não tem permissão para usar o serviço de rotas.');
}

59
else if (status == 'OVER_QUERY_LIMIT') {
alert('A página da web ultrapassou o limite de solicitações em um período de tempo
muito curto.');
} else if (status == 'NOT_FOUND') {
alert('At least one of the origin, destination, or waypoints could not be geocoded.');
} else if (status == 'INVALID_REQUEST') {
alert('Pelo menos uma origem, destino ou waypoints não pôde ser geocodificado.');
} else {
alert("Ocorreu um erro desconhecido no seu pedido."+status);
}
}
});

(<HTMLInputElement>document.getElementById('routeStart')).value = " ";


(<HTMLInputElement>document.getElementById('routeEnd')).value = " ";

Figura B.4 – Trecho de código Eliminar marcador na base de dados.

apagar(atm){
this.estadoatual=atm;
var atmkey=this.estadoatual;
var ref = firebase.database().ref().child("markers");
ref.once('value', function(snapshot) {
if (snapshot.hasChild(atmkey)) {
ref.child(atmkey).remove();
}
else {
console.log("erro")
}
});

60
Anexo C – Principais tabelas da Base de dados da Aplicação

Figura C.1 – Tabela da base de dados - Markers.

Figura C.2 – Tabela da base de dados - Mensagens.


61
Figura C.3 – Tabela da base de dados – User.

Figura C.4 – Tabela da base de dados – Funcionários.

62
Anexo D

Modelo Lógico

Compreende uma descrição das estruturas que serão armazenadas no banco de dados,
resultando de uma maneira lógica a representação gráfica dos dados, inclusive nomeando os
componentes e ações que exercem uns sobre os outros.

Figura E.1 – Modelo Lógico do sistema Kudissanga Multicaixa.

63
Anexo E – Questionário usado para analise de requisitos

64
65
66

Você também pode gostar