ESCOLA SUPERIOR DE TECNOLOGIA E GESTÃO
INSTITUTO POLITÉCNICO DA GUARDA
G O W I - F LY T I C S
P L ATA F O R M A E S TAT Í S T I C A PA R A
S O L U Ç Ã O W I - F I
PROJETO EM CONTEXTO DE ESTÁGIO
Curso Engenharia Informática Unidade Curricular Projeto de Informática
Ano Letivo 2015/2016 Docente Orientador Pedro Pinto Coordenador da área disciplinar Noel Lopes Data 04-10-2016
II Instituto Politécnico da Guarda
Escola Superior de Tecnologia e Gestão Licenciatura em Engenharia Informática
Relatório de Estágio
Relatório relativo ao estágio efetuado na empresa GoWi-Fi no Aveiro Business
Centre, no âmbito da licenciatura em Engenharia Informática durante o período de 1 de
junho de 2016 a 25 de julho de 2016.
ESCOLA SUPERIOR DE TECNOLOGIA E GESTÃO
INSTITUTO POLITÉCNICO DA GUARDA
Av. Dr. Francisco Sá Carneiro 506300-559 Guarda Telf. 271220100 Fax: 271220150
III
Elementos Identificativos
Aluno:
Pedro Alexandre Romano Lopes Nº 1011423
Licenciatura: Engenharia Informática
Estabelecimento de Ensino:
Escola Superior de Tecnologia e Gestão Instituto Politécnico da Guarda
Instituição Acolhedora de Estágio: Nome: GoWi-Fi
Morada: Rua de Igreja 79, 3810-744 Aveiro Telefone: 234290297
Duração do Estágio: Inicio: 01 de junho de 2016 Fim: 25 de julho de 2016
Orientador de Estágio: Nome: Eng.º Pedro Pinto
IV
Agradecimentos
Agradeço ao meu orientador Pedro Pinto o contacto efetuado com a empresa
Wavecom que possibilitou a realização deste projeto em contexto de estágio assim como
todo o seu apoio ao longo do desenvolvimento do projeto.
Agradeço ao meu orientador na empresa Pedro Pereira pela fantástica oportunidade de estagiar na GoWi-Fi assim como todo o seu apoio durante o período de estágio.
Quero ainda agradecer a toda a equipa da GoWi-Fi pela ótima integração, pela imensa disponibilidade em esclarecer qualquer tipo de dúvida e ainda pela motivação que foi essencial para o desenvolvimento do projeto.
Um agradecimento final a todos aqueles que me apoiaram no decorrer desta última etapa, nomeadamente familiares e amigos mais próximos que sempre acreditaram nas minha capacidades e me apoiaram incondicionalmente.
V
Resumo
O presente documento descreve o trabalho relativo ao projeto realizado em contexto de estágio no âmbito da unidade curricular Projeto de Informática, englobada na Licenciatura em Engenharia Informática da Escola Superior de Tecnologia e Gestão do Instituto Politécnico da Guarda.
O projeto consistiu no desenvolvimento de uma aplicação para dispositivos móveis, para o sistema operativo móvel Android, onde é possível consultar, em tempo real, estatísticas de presenças por meio de elementos gráficos. Foi ainda desenvolvido todo o back-end que processa os dados desde que são recebidos até que a aplicação
Android os requisita à base de dados em tempo real.
O trabalho desenvolvido foi proposto pelo coordenador da empresa Pedro Pereira com o intuito de oferecer aos seus clientes uma aplicação para smartphone que disponibilizasse em tempo real estatísticas sobre os clientes ativos no seu estabelecimento assim como um histórico numa determinada janela temporal.
Palavras Chave (Tema): Aplicação Android, Gráficos, Servidor na Cloud, Atualização Tempo real
VI
Abstract
The present document describes the project done during the internship related to the Computer Science Project course, which is the final stage in the Computer Science degree held in School of Technology and Management of the Polytechnic Institute of Guarda.
The project consisted in developing an application for mobile devices, to the mobile operating system Android, which allows the user to access real time attendance statistics as well as its history through charts. It was further developed all the back-end that handles the data since its received until the Android application requests the data in real time.
This work idea was Pedro Pereira’s, coordinator in the company Go Wi-Fi, and its propose was to offer its customers an application that they could have on their smartphone and would display real time statistics about the customers present in his establishment alongside with a small history given a time window.
Key words (Theme): Android application, Charts, Cloud server, Real time update Key words (Technologies): Android Studio, Google Cloud, Firebase, Python
1
Índice Geral
Elementos Identificativos ... III
Agradecimentos ... IV
Resumo ... V
Abstract ... VI
Índice de figuras ... 3
Índice de tabelas ... 4
1.
Introdução ... 5
1.1. Enquadramento ... 5 1.2. Objetivos do estágio ... 5 1.3. Estrutura do relatório ... 62.
Apresentação do projeto ... 7
2.1. A Empresa ... 7 2.2. Definição do problema ... 9 2.3. Objetivos do projeto ... 103.
Estado da Arte ... 11
3.1. Fundamentação do Projeto ... 113.2. Estado da arte da Empresa ... 11
3.3. Plataformas existentes ... 12
3.4. Enquadramento do projeto ... 14
3.5. Metodologia ... 14
4.
Tecnologias e ferramentas utilizados ... 16
4.1. GitHub ... 16
4.2. Postman ... 20
4.3. Python ... 20
4.4. Pycharm ... 21
4.5. Google App Engine ... 22
4.6. Firebase ... 23
4.7. General Image Manipulation Program ... 23
2
4.9. Android ... 25
4.10. Android Studio... 26
5.
Relatório de Atividades ... 28
5.1. Estudo das tecnologias utilizadas pela empresa... 28
5.2. Pesquisa de bibliotecas de gráficos para Android ... 29
5.3. Criação da aplicação Android ... 31
5.4. Configuração inicial do servidor ... 31
5.5. Resolução de problemas no servidor ... 33
5.6. Otimização do servidor ... 36
5.7. Conclusão da aplicação Android ... 39
6.
Conclusão ... 41
Glossário ... 42
7.
Bibliografia ... 47
Fontes ... 498.
Anexos ... 50
8.1. Imagens ... 503
Índice de figuras
Figura 1 - Esquema funcionamento básico do projeto GoWi-Fi ... 9
Figura 2 - Exemplo de gráficos na aplicação Android ... 14
Figura 3 – Esquema de funcionamento do Scrum ... 15
Figura 4 - Repositório no GitHub ... 17
Figura 5 – Lista de issues no GitHub ... 17
Figura 6 - Issue no GitHub ... 18
Figura 7 - Controlo de versões no GitHub ... 19
Figura 8 - Exemplo de post usando o Postman ... 20
Figura 9 - Código de Python ... 21
Figura 10 - Projeto no PyCharm ... 21
Figura 11 - Dashboard do back-end do projeto na GAE ... 22
Figura 12 - Dashboard do Firebase ... 23
Figura 13 - Edição de imagem no GIMP ... 24
Figura 14 - Código de Java ... 24
Figura 15 - Ecrã inicial do Android 7.0 Nougat ... 26
Figura 16 - Aplicação Android do Projeto no Android Studio ... 27
Figura 17 - Exemplos de gráficos da biblioteca MPAndroidChart ... 29
Figura 18 - Exemplos de gráficos da biblioteca HelloCharts ... 30
Figura 19 - Ícone da aplicação Android ... 31
Figura 20 - Criação do projeto na GAE e posterior associação ao Firebase ... 32
Figura 21 - Exemplo Post Meraki (ficheiro JSON) ... 32
Figura 22 - Esquema do tratamento de dois pedidos concorrentes ... 34
Figura 23 - Esquema de funcionamento do servidor com a implementação da memcache e do cron ... 35
Figura 24 - Esquema da contabilização do mesmo cliente várias vezes na mesma hora 36 Figura 25 - Esquema de criação das chaves na memcache baseadas na data e hora e adição das mesmas à chave 'datasAtualizadas' ... 37
Figura 26 - Esquema de adição de um novo cliente ao HLL ... 38
Figura 27 - Esquema do funcionamento do servidor ... 39
Figura 28 - Gráficos aplicação Android antes e após a seleção do dia ... 40
Figura 29 - Captive Portal ... 50
Figura 30 - Criação de plano (Geo SMS ou Hot SMS) para envio de mensagens de campanhas publicitárias ... 50
4
Índice de tabelas
5
1. Introdução
Nesta secção segue-se uma breve introdução sobre a âmbito da realização do estágio, o seu enquadramento e ainda os objetivos propostos.
Este relatório surge na sequência do estágio realizado no âmbito da unidade curricular Projeto de Informática, da licenciatura em Engenharia Informática. O estágio realizou-se no Aveiro Business Centre, mais precisamente na empresa GoWi-Fi e teve uma duração de 2 meses, tendo início a 1 de junho de 2016 e término a 25 de julho de 2016.
Durante o estágio foram estudadas e implementadas várias tecnologias que contribuíram para o desenvolvimento de conhecimento e tornaram possível alcançar os objetivos propostos.
1.1. Enquadramento
O estágio curricular realizado diz respeito à última etapa da licenciatura em Engenharia Informática. Neste projeto final foi possível pôr em prática alguns dos conhecimentos adquiridos ao longo dos últimos três anos e desenvolver competências sobre novas tecnologias que foram fulcrais durante a elaboração de todo o trabalho.
Consequentemente durante os dois meses de estágio foi possível aprofundar conhecimento relativamente a estruturas de dados e programação, em especial para dispositivos móveis.
1.2. Objetivos do estágio
Os objetivos do estágio permitiram a aquisição de conhecimentos relativos às tecnologias utilizadas pela empresa GoWi-Fi e a posterior implementação destas no projeto. De seguida apresentam-se os objetivos definidos inicialmente:
Experiência de integração numa equipa de desenvolvimento de software; Contacto com a operação diária de um produto com utilizadores em todo o
território nacional;
6 Interação com sistemas de alto desempenho;
Contacto com ferramentas de controlo de versões de código (Git);
Conhecer as novas tecnologias usadas pela empresa: Git, Slack, Cisco Meraki,
Google App Engine, Column-Oriented DBMS e Google Data Store;
Adquirir conhecimentos sobre Google Cloud;
1.3. Estrutura do relatório
Neste relatório são abordadas as tecnologias utilizadas para o desenvolvimento do projeto, desde uma breve explicação sobre as mesmas até à sua implementação.
O relatório está estruturado da seguinte forma: introdução, onde se fala do enquadramento do projeto, dos objetivos e estrutura do relatório, uma breve apresentação da empresa onde o estágio foi realizado assim como a definição do problema, uma explicação de cada uma das tecnologias utilizadas, o relatório de todas as atividades desempenhadas durante o estágio e por fim encontra-se a conclusão.
7
2. Apresentação do projeto
Nesta segunda secção é dada a conhecer a empresa assim como o seu funcionamento base e tecnologias usadas. Por outro lado, é ainda contextualizado o projeto e definidos os objetivos do mesmo.
2.1. A Empresa
O Projeto de Informática no âmbito da conclusão da licenciatura em Engenharia Informática, foi realizado em contexto de estágio e teve local no Aveiro Business Centre, mais precisamente na empresa GoWi-Fi.
A empresa GoWi-Fi tem foco num projeto com o mesmo nome sendo o seu principal objetivo oferecer um serviço de Internet sem fios seguro a todos aqueles que estejam nas imediações de um dos seus Access Points, requerendo apenas o número de telemóvel do utilizador para o qual é enviado um código de confirmação.
A escolha da rede Wireless Fidelity (Wi-Fi) é fundamentada pela maior praticidade da propagação do sinal da Internet através de ondas de rádio, o que evita o uso de cabos de rede e ainda pelo número de dispositivos utilizados no dia a dia que são compatíveis, desde o telemóvel, tablet, portátil, entre outros. A norma Institute of
Electrical and Electronics Engineers (IEEE 802.11), ou simplesmente Wi-Fi, possuí
vários protocolos com diferentes frequências, larguras de banda e velocidades de transferência [26]. Entre os protocolos existentes, os principais e também compatíveis com os dispositivos alvo são:
Tabela 1 - Tabelas dos protocolos Wi-Fi mais comuns
Protocolo Velocidade Frequência
802.11a 54 Mbps 5 GHz 802.11b 11 Mbps 2.4 GHz 802.11g 54 Mbps 2.4 GHz 802.11n 300 Mbps 2.4 ou 5 GHz 802.11ac Wave 1 1.3 Gbps 5 GHz 802.11ac Wave 2 3.6 Gbps 5 GHz 802.11ad 6.75 Gbps 60 GHz
8 O Wi-Fi pode ser visto como uma rede que funciona em modo aberto, podendo ser difundida de forma aberta ou de forma segura, requerendo uma password de acesso. Caso esta seja difundida sem segurança esta poderá ser acedida por qualquer dispositivo referido acima, contudo não é por isso que se torna menos segura. A ligação a uma rede que não requisite uma password de acesso não é necessariamente insegura pois caso as páginas consultadas possuam o protocolo Hyper Text Trasnfer Protocol Secure (HTTPS) a informação transmitida entre o cliente e o servidor encontra-se encriptada. Para além deste tipo de proteção é possível ainda esconder a rede para esta não ser detetada por qualquer dispositivo, isto é, de modo a apenas os dispositivos que conheçam o seu SSID se consigam ligar à rede, no entanto, este tipo de proteção não garante a segurança da rede. Para além deste método existem ainda outros mecanismos de segurança desde o
Wired Equivalent Piravcy (WEP), Wi-Fi Protected Access (WPA) até ao Wi-Fi Protected Access 2 WPA2(AES), sendo este último o mais seguro visto que contempla um
mecanismo de encapsulamento de dados encriptados baseados no Advanced Encryption
Standard (AES) permitindo chaves de 128, 192 e 256 bits [19].
Relativamente à parte do serviço, o Wi-Fi disponibilizado pela GoWi-Fi é usado para a recolha de informação, cuja finalidade é marketing, isto é, para informar os utilizadores registados de eventuais campanhas promocionais. As campanhas promocionais são apresentadas de duas diferentes maneiras:
Captive Portal – página web com a campanha promocional apresentada
após o login;
Envio de SMS:
o Geo SMS – envia um SMS com uma campanha promocional numa determinada data e hora a todos os utilizadores com um perfil específico; o Hot SMS – envia um SMS a todos os utilizadores (que ainda não tenham recebido a campanha promocional) detetados nas imediações de um determinado local;
Os serviços descritos acima podem ser requisitados por empresas que efetuem um contrato com a GoWi-Fi podendo assim divulgar campanhas promocionais de uma maneira mais original.
Os Access Points (APs), da Cisco, da GoWi-Fi distribuídos pelo país enviam os dados que recebem para a plataforma de cloud da Meraki, mais propriamente os
9 endereços MAC Media Access Control Address das placas de rede dos equipamentos do cliente (este tipo de endereços é constituído por um conjunto de 6 bytes separados por dois pontos ou hífen, sendo cada byte representado por dois algarismos na forma hexadecimal, em que a primeira metade diz respeito à norma IEEE e a segunda metade ao fabricante, perfazendo um total de 48 bits). Estes dados são de seguida encaminhados para a Google App Engine que os transmite inicialmente para o Google Data Store que os armazena em tempo real devido à capacidade de receber grandes quantidades de dados. Estes dados são depois, periodicamente, copiados para a base de dados não relacional orientada a colunas onde têm como principal fim a análise de dados (Data Analytics (Figura 31 - Dashboard do projeto em geral em Anexo)). Segue-se um esquema para uma melhor compreensão do funcionamento da empresa:
Figura 1 - Esquema funcionamento básico do projeto GoWi-Fi
2.2. Definição do problema
O projeto de informática consiste na criação de uma aplicação em Android direcionada aos clientes da GoWi-Fi cuja finalidade é obter dados estatísticos sobre a eficácia da campanha promocional promovida, isto é, o cliente GoWi-Fi do estabelecimento poderá usar a aplicação para ver o número de clientes ativos nos últimos
10 x dias através de elementos gráficos. O cliente GoWi-Fi, poderá também ver qual a assiduidade dos clientes nos últimos períodos de tempo quer para fazer uma oferta especial quer para simples estatística. Assim, o cliente GoWi-Fi poderá tirar conclusões da sua campanha publicitária diretamente a partir do seu smartphone, o que é de extrema importância pois até à data a única maneira de saber o sucesso da campanha, ou da sua divulgação, restringia-se às alterações na faturação dos produtos ou serviços prestados associados a essa mesma campanha.
2.3. Objetivos do projeto
Desenvolvimento de um servidor com a linguagem de programação Python tendo como base o Google App Engine;
Desenvolvimento de uma aplicação Android que permita comunicar com o servidor previamente criado e tenha as seguintes funções:
o Disponibilização da lista de clientes no local; o Apresentação do histórico dos clientes.
11
3. Estado da Arte
Nesta secção encontra-se a fundamentação do projeto, um pequeno resumo sobre o estado da arte da empresa. É ainda feita uma comparação dos serviços prestados pela empresa e do projeto com as plataformas existentes.
3.1. Fundamentação do Projeto
O tema escolhido para o projeto, entre as várias propostas de empresa, recaiu sobre a criação de uma aplicação para Android com as características já referidas pois as tecnologias a usar iriam muito além dos conhecimentos adquiridos na licenciatura. Assim, surgiu uma grande oportunidade de aprender sobre novas tecnologias como a Cloud da
Google, Python, Meraki (Cisco) e ainda Firebase que até então eram desconhecidas.
3.2. Estado da arte da Empresa
A empresa tem como principal objetivo receber dados em massa sobre os hábitos das pessoas quer durante o período que se encontram ativos na rede quer durante o período que se encontram ausentes.
A solução mais imediata passa pela criação de uma aplicação para o smartphone, contudo esta apresenta várias desvantagens como ser caro desenvolver uma aplicação para um espectro tão largo da população ou calibrar o volume e periodicidade de envio da informação de modo a minimizar o seu impacto na bateria. Assim sendo convencionou-se que a informação poderia ser recolhida através de APs considerando que o protocolo rádio na base dos sistemas Wi-Fi se mantém e é ainda improvável uma diminuição significativa no preço dos dados móveis. Assim os APs teriam a função de fornecer um serviço de Wi-Fi às pessoas nas suas imediações, mas também recolher informações sobre estas. Dado isto, devido ao elevado número de dados que seriam recebidos revela-se necessário um sistema de alto desempenho que possa suportar picos de pedidos. Após alguns estudos das soluções possíveis conclui-se que a utilização de uma Platform as a Service (PaaS), neste caso a Google Cloud, seria mais viável visto que possui um sistema de tolerância a falhas com mecanismos de replicação de dados, é elástica, isto é, adequa automaticamente os processadores, memória e espaço em disco
12 alocados ao projeto consoante a quantidade de informação a ser processada, permite o acesso em qualquer lugar dado tratar-se de uma plataforma online e o custo deste serviço é proporcional ao seu uso.
Este projeto empresarial apresenta ainda assim alguns ricos tecnológicos, legais e ainda operacionais. Os riscos tecnológicos passam pela a triagem e eliminação do ruído nos dados, isto é, os aparelhos em exposição em lojas de um centro comercial devem ser triados pois serão detetados pelos APs, não constituindo informação útil sobre os hábitos de um cliente. Relativamente aos riscos legais, as políticas de segurança e de proteção de dados poderá colocar alguns entraves na utilização da informação recolhida. Por fim, os riscos operacionais que estão dependentes do número de nós da rede que se espera mitigar ao longo do projeto com recolha de mais informação.
Versão completa do estado da arte em anexo.
3.3. Plataformas existentes
3.3.1. NOS | Fon
Esta plataforma é fruto de uma parceria entre a Fon e a NOS e tem como fim fornecer um serviço de Wi-Fi em vários locais, possuindo APs distribuídos por todo o mundo, contudo este é um serviço pago, a primeira mensalidade é gratuita e as seguintes têm um custo de 5€ por mês. Porém, dada a parceria entre a NOS e a Fon é possível ter acesso a este serviço de Wi-Fi caso o utilizador possua um contrato em vigor com a NOS. Para tal o cliente NOS deverá ligar um router com a funcionalidade ‘NOS Wi-Fi powered by Fon’ que partilha o seu sinal Wi-Fi com outros membros Fon separando a parte partilhada da banda larga da rede privada. Assim o cliente terá acesso ao serviço Fon em todo o mundo [8].
3.3.2. MEO Wi-Fi
A plataforma da MEO Wi-Fi disponibiliza um serviço similar ao referido acima, podendo aderir aos planos de Internet disponibilizados pela MEO ou, caso já seja cliente, através da difusão do sinal a partir do router, igualmente numa rede separada da rede doméstica. Deste modo o cliente terá também acesso aos hotspots desta empresa distribuídos por todo o mundo.
13 A GoWi-Fi disponibiliza o mesmo tipo de serviço embora, de momento, apenas em Portugal. O serviço de Wi-Fi disponibilizado é completamente gratuito. Para efetuar a ligação Wi-Fi basta o utilizador ligar-se à rede e preencher um pequeno formulário onde apenas o seu número de telefone é obrigatório pois receberá um código que deve introduzir no Captive Portal para ter acesso à Internet.
As duas empresas fornecem o mesmo tipo de serviço de Wi-Fi embora com diferentes fins. As plataformas acima referidas têm com único objetivo oferecer uma ligação à Internet sem fios ao utilizador final (Business-to-Client ou B2C) é o comércio efetuado diretamente entre a empresa prestadora do serviço e o consumidor final.). A GoWi-Fi tem um serviço Business-to-business (B2B), ou seja, o serviço é direcionado a uma empresa embora o utilizador final sejam os clientes dessa empresa. Dado isto, são colocados APs no estabelecimento do cliente GoWi-Fi e são os clientes desse estabelecimento que usufruem da ligação à Internet sem fios. A empresa tem ainda um outro objetivo que é permitir ao seu cliente direto criar campanhas publicitárias usando a base de dados da GoWi-Fi.
O projeto desenvolvido é enquadrado neste último tópico e é inovador na medida que o cliente da GoWi-Fi tem acesso a elementos gráficos com estatísticas em tempo real sobre os utilizadores que estão e estiveram no seu estabelecimento numa janela temporal a partir do seu smartphone. Assim, o projeto distancia-se de qualquer serviço que a NOS ou a Fon oferecem dado tratar-se de uma outra vertente da empresa GoWi-Fi. Este é mais um serviço que poderá ser disponibilizado aos seus clientes para que estes possam aferir sobre a melhor altura para uma eventual campanha.
Na figura seguinte podemos visualizar as estatísticas apresentadas no smartphone por meio de elementos gráficos:
14 Figura 2 - Exemplo de gráficos na aplicação Android
3.4. Enquadramento do projeto
O projeto desenvolvido é inovador e único na medida em que a aplicação em
Android disponibilizará estatísticas à cerca dos clientes ativos na rede em tempo real, mas
também um histórico de assiduidade dos mesmos dentro de uma janela temporal. Sendo que os dados são recolhidos pelos APs distribuídos pelo país e posteriormente enviados para a cloud da Meraki onde são redirecionados para a Google App Engine para serem tratados e posteriormente apresentados pelo meio de um gráfico ao utilizador final. Este tipo de estatísticas revela-se de extrema importância pois poderá transmitir ao utilizador qual o melhor período para criar uma campanha publicitária com base na estatística presente no seu smartphone Android em tempo real.
3.5. Metodologia
A metodologia usada para o desenvolvimento do projeto foi o Scrum que é uma ferramenta de desenvolvimento de software iterativo e incremental utilizado na gestão de projetos e desenvolvimento de software ágil. Esta metodologia é evidente ao longo do projeto visto ter sofrido alterações à medida que foi desenvolvido. Sendo os requisitos voláteis e, portanto, a definição do projeto nunca completamente nítida foi fundamental uma rápida adaptação ao novo problema e consequente produção de um novo produto com as devidas alterações.
15 Dado a natureza incremental desta ferramenta está preparada para alterações constantes no produto final adotando assim uma abordagem empírica – aceita que o problema nunca está inteiramente compreendido focando-se em produzir um produto final adaptado aos novos requisitos [27].
A iteratividade do Scrum traduz-se em sprints semanais ou mensais em que é desenvolvido um produto funcional devidamente testado. Por norma, os sprints são seguidos de uma reunião de revisão onde novas tarefas são identificadas e um novo compromisso do próximo sprint definido.
O projeto desenvolvido adequa-se nesta última característica na medida em que são definidos issues semanais no Gitub (sprints) com as tarefas a realizar e no fim de cada dia é feito um ponto de situação onde são revistos os progressos feitos e são definidos novos requisitos ou tarefas. No fim de cada sprint existe também uma revisão com as características a cima mencionadas.
Por fim, a natureza incremental da metodologia que, apesar da volatilidade dos requisitos, se pode constatar pelas alterações ao projeto serem implementadas sobre uma estrutura base, isto é, as alterações são implementadas sobre o projeto desenvolvido anteriormente.
Na figura abaixo podemos conferir o funcionamento desta ferramenta onde o trabalho de um determinado intervalo de tempo é repartido por menores períodos de tempo e são desenvolvidos em sprints semanais até à data limite inicial concluindo o trabalho final e posteriormente num sprint final é adicionado ao software existente.
Figura 3 – Esquema de funcionamento do Scrum (Scrum, s.d.)
16
4. Tecnologias e ferramentas utilizados
O projeto contemplou várias tecnologias e aplicações, desde a plataforma móvel para a qual foi desenvolvida uma aplicação (Android) até ao endpoint em python onde os dados são recebidos e tratados. Assim, segue-se uma breve explicação sobre cada uma das tecnologias ferramentas utilizadas no desenvolvimento do projeto.
4.1. GitHub
O GitHub é um serviço de alojamento de repositórios Git (sistema de controlo de versões e de gestão de código fonte) baseado na web que oferece todas as funcionalidades do Git assim como uma interface gráfica que facilita a sua utilização [24].
A plataforma do GitHub foi criada por Tom Preston-Werner, Chris Wanstrath e PJ Hyett e teve como base a linguagem de programação Ruby. O GitHub oferece dois tipos de planos, repositórios privados e contas gratuitas. Este último plano é normalmente usado para alojar projetos de software open-source.
O GitHub é um dos repositórios mais usados a nível mundial, principalmente a nível de código, e mediante funcionalidades como a criação de issues com secção de comentários e o controlo de versões bastante simples foi o escolhido para o projeto. Este repositório foi usado para criar issues semanais com os objetivos propostos e para controlo de versões do trabalho realizado efetuando upload do mesmo pela linha de comandos do Git.
Na Figura 4 está presente o repositório do GitHub onde o projeto desenvolvido foi guardado.
17 Figura 4 - Repositório no GitHub
A Figura 5 apresenta alguns dos issues criados no GitHub onde podemos verificar o título, o número, o autor, a quem está atribuído, a data de entrega, o número de comentários e ainda verificar se já foi fechado ou ainda continua ativo. Há ainda a opção de criar novos issues.
18 A Figura 6 representa um issue com todos os detalhes. Para além da informação presente na Figura 5 encontramos os objetivos semanais que constituem o issue assim como os comentários.
19 A Figura 7 apresenta as alterações efetuadas no ficheiro especificado assinalando a vermelho o que foi removido e a verde o que foi acrescentado. Assim, podemos facilmente verificar quais as alterações.
As versões anteriores podem ser encontradas numa simples pesquisa pelo número do issue associado ou através do título.
20
4.2. Postman
O Postman foi criado por Abhinav, Ankit e Abhijit e trata-se de uma Application
Programming Interface (API) que permite criar e enviar pedidos Hyper Text Transfer Protocol (HTTP), partilhar workflows através da sua própria cloud e ainda criar casos de
teste [16].
Esta API foi usada para enviar pedidos Respresentional State Trasnfer (REST) como gets que consultam informação ou posts que enviam informação, ambos sobre HTTP.
Figura 8 - Exemplo de post usando o Postman
4.3. Python
O Python foi desenvolvido por Guido van Rossum tendo como base a linguagem de programação ABC. Trata-se de uma linguagem de programação de alto nível, multi paradigma, de script, orientada a objetos, imperativa, funcional e de tipagem dinâmica. A filosofia de design passa por um código mais legível, o que permite aos programadores escrever o seu código em menos linhas [17].
O Python foi escolhido para a programação do endpoint principalmente pela compatibilidade com a Google App Engine (GAE) embora o desconhecimento desta linguagem de programação também tenha sido um fator importante despertando interesse em adquirir novas competências.
21 Figura 9 - Código de Python
4.4. Pycharm
O Pycharm foi desenvolvido pela JetBrains e trata-se de um IDE de desenvolvimento para Python que contempla funcionalidades como análise de código,
debugger gráfico, testes unitários, controlo de versões e desenvolvimento web com Django [15].
O PyCharm foi escolhido por ser uma ferramenta bastante completa facilitando a deteção de erros de escrita e de compilação. A integração com a GAE permitiu fazer
upload direto do código evitando o uso da aplicação da GAE.
A figura 10 apresenta o projeto desenvolvido em edição no PyCharm.
22
4.5. Google App Engine
A Google App Engine (GAE) foi desenvolvida pela Google e é um dos componentes da Google Cloud. Trata-se de uma plataforma de computação em nuvem (PaaS) para o desenvolvimento e alojamento de aplicações web. Esta plataforma virtualiza aplicações em múltiplos servidores, provendo hardware, conectividade, sistema operativo e serviços de software. Estas aplicações são implementadas numa
sandbox (mecanismo seguro que separa programas em execução, isto é, executa
programas não testados sem afetar a máquina ou qualquer outro programa em execução). A GAE suporta as linguagens de programação Python, Java, Go e PHP [10][25].
A cloud cada vez mais se afirma como uma alternativa aos servidores convencionais devido aos custos iniciais (Capital Expenditure ou CAPEX) assim como os custos energéticos e de manutenção (Operational Expenditure ou OPEX). A facilidade de acesso, a escalabilidade e os custos serem proporcionais à utilização dos serviços são outros motivos que favorecem a ideia de que o uso da Cloud é o mais vantajoso.
A GAE foi a escolhida pelas vantagens acima referidas, mas também por ser uma das tecnologias usadas pela empresa e um dos requisitos do projeto. Na GAE está alojado todo o back-end do projeto [11].
23
4.6. Firebase
O Firebase foi criado por Andew Lee e James Tamplin, teve como base o Envolve (API que permitia a integração de um chat online em websites), e trata-se de um provedor de serviços em nuvem e Back-end as a Service (BaaS). A principal funcionalidade do
Firebase é a base de dados em nuvem em tempo real, o que permite aos programadores
armazenar e sincronizar dados entre vários clientes [22].
O Firebase foi usado como uma base de dados que sincroniza dados em tempo real e faz broadcast para a aplicação desenvolvida para Android.
Figura 12 - Dashboard do Firebase
4.7. General Image Manipulation Program
O General Image Manipulation Program (GIMP) foi criado por Spencer Kimball e Peter Mattis e é um software open-source principalmente usado para criação e edição de imagens raster e em menor escala para desenho vetorial [9].
Este software foi usado para criar o ícone da aplicação móvel que está presente na figura que se segue:
24 Figura 13 - Edição de imagem no GIMP
4.8. Java
O Java foi criado por James Gosling e sua equipa e baseia-se em C e C++, contudo tem menos atributos de baixo nível do que qualquer uma delas. Esta é uma linguagem de programação de alto nível, multi paradigma, baseada em classes, orientada a objetos e especificamente projetada para ter o menos número de dependências de execução possível. Destina-se a permitir que o código Java compilado possa ser executado em todas as plataformas que suportem Java se a necessidade de recompilação.
O Java é a linguagem de programação do Android sendo usada para o desenvolvimento da aplicação móvel.
A figura 14 constitui um exemplo de código Java.
Figura 14 - Código de Java (Java, s.d.)
25
4.9. Android
O Android foi desenvolvido pela Google e trata-se de um sistema operativo (baseado no núcleo de Linux e na linguagem de programação Java) projetado principalmente para dispositivos móveis sensíveis ao toque (smartphones, tablets e
smartwatches), podendo também ser usado para outros dispositivos, interfaces
específicas de TV (Android TV) ou carros (Android Auto) [20].
Este sistema operativo (SO) foi disponibilizado sob licença de código o aberto, o que o torna muito popular entre empresas de tecnologias que procuram um software pronto, de baixo custo e personalizável para os seus dispositivos. Por consequente uma imensa variedade de dispositivos assim como de aplicações foi criada. Para além destas vantagens o Android recebe ainda maior integração de serviços da Google, a sua produtora.
O Android não é perfeito e como tal apresenta algumas desvantagens. A disponibilização do seu código abertamente resulta numa enorme variedade de designs por parte de cada empresa de tecnologia, o que por vezes poderá dificultar a adaptação dos utilizadores a diferentes empresas que adotem este SO. Outro ponto negativo do
Android é a otimização visto que a variedade de componentes utilizados nos smartphones
das mais variadas empresas não o permitem. Por fim, a desvalorização dos dispositivos
Android, quer pela grande oferta que há no mercado, mas também porque muitos modelos
veem o SO ser descontinuado.
Apesar das desvantagens referidas o Android continua a ser o sistema operativo móvel mais usado no mundo e uma das grandes razões é a sua grande comunidade, existem imensas produtoras de aplicações para Android que tornam a Play Store bastante rica em conteúdo das mais variadas áreas. Como tal a integração com outras plataformas e a atualização das aplicações é frequentemente, sendo oferecido suporte para novas versões do Android [5].
O Android foi escolhido para o desenvolvimento da aplicação móvel principalmente por ser o SO móvel mais utilizado em todo o mundo, mas foi igualmente importante a compatibilidade com as mais variadas plataformas. A aplicação desenvolvida constrói um gráfico a partir de dados provenientes de um web service.
26 Figura 15 - Ecrã inicial do Android 7.0 Nougat
4.10.
Android Studio
O Android Studio foi desenvolvido pela Google e é um Integrated Development
Environment (IDE) de desenvolvimento para Android com as seguintes características:
Suporte para compilações baseadas em Gradle; Análise de código;
Ferramentas Lint - controlo de performance, usabilidade, compatibilidade e outros problemas;
Integração com Proguard (otimiza código java detetando e removendo instruções não usadas) e assinatura de app.
Assistentes de criação de templates;
Editor de layout que permite o drag-and-drop de componentes e a visualização do layout em múltiplos ecrãs e resoluções;
Suporte para a criação de aplicações Android para todo o tipo de plataforma
Android;
Suporte para Google Cloud Platform, integração com Google Cloud Messaging,
Firebase e App Engine.
27 Este IDE foi escolhido para desenvolver a aplicação Android devido às características acima referidas [6].
Na figura 16 retrata a edição da aplicação Android desenvolvida no Android Studio e o emulador que o IDE integra em funcionamento.
28
5. Relatório de Atividades
Neste capítulo são abordadas todas as atividades desenvolvidas no projeto em contexto de estágio.
O estágio incidiu, inicialmente, sobre o estudo das tecnologias utilizadas pela empresa e pesquisa de outras tecnologias ou APIs que pudessem ser uma mais valia para o desenvolvimento do projeto. Por fim, a implementação do projeto usando as tecnologias mais indicadas no âmbito dos objetivos propostos.
5.1. Estudo das tecnologias utilizadas pela empresa
A primeira etapa do estágio passou por pesquisar e ler informação relativa às tecnologias utilizadas pela empresa no âmbito de compreender o funcionamento da mesma.
A equipa GoWi-Fi deu uma pequena palestra sobre o funcionamento da empresa e de cada uma das tecnologias em utilização. Disponibilizou ainda muito do material de estudo através de issues no GitHub, o que acelerou a integração no projeto.
Como primeira abordagem, foram estudadas todas a tecnologias utilizadas pela empresa para ter uma visão global do projeto e saber qual o workflow. Desde a plataforma de cloud da Meraki que recebe e trata os dados enviados pelos APs distribuídos por todo o país até aos dados armazenados na cloud em base de dados orientadas a colunas que tem como fim Data Analytics [12].
De seguida precedeu-se a um estudo mais pormenorizado das tecnologias que estariam diretamente envolvidas no projeto. Concluído o estudo passou-se a uma vertente prática, foram realizados cursos online de Python e Git, tutoriais sobre Google App
29
5.2. Pesquisa de bibliotecas de gráficos para Android
Nesta segunda etapa procedeu-se a uma pesquisa em busca de uma biblioteca de gráficos com suporte para Android que fosse de encontro com os requisitos propostos nos objetivos.
A grande variedade de bibliotecas encontradas não foi uma surpresa estando perante o sistema operativo móvel mais usado no mundo. Assim, foram escolhidas as 2 bibliotecas que mais se adequavam com o pretendido.
A primeira, denominada MPAndroidChart, foi criada for Phillipp Jahoda e dispunha de 8 tipos de gráficos diferentes incluindo gráficos de linhas, barras, circulares, entre outros. Esta biblioteca possuía várias características bem conhecidas do Android como o zoom com dois dedos para aumentar ou diminuir a escala dos gráficos ou o scroll horizontal e vertical e ainda animações na criação dos gráficos para além das outras propriedades comuns dos gráficos [4].
A Figura 17 apresenta alguns dos gráficos disponibilizados pela biblioteca referida no parágrafo anterior.
Figura 17 - Exemplos de gráficos da biblioteca MPAndroidChart (MAPAndroidChart, s.d.)
A segunda biblioteca de nome HelloCharts foi desenvolvida por Leszek Wach e para além de todas as propriedades da biblioteca anterior possuía uma outra variante bastante interessante. Esta biblioteca permitia construir um gráfico com base noutro, isto é, a partir de um gráfico de barras é possível criar um gráfico de linhas com base na informação proveniente da coluna selecionada [2].
30 A Figura 18 apresenta alguns dos gráficos disponibilizados pela biblioteca referia no parágrafo anterior.
Figura 18 - Exemplos de gráficos da biblioteca HelloCharts (HelloCharts, s.d.)
Dado o estudo e a seleção das melhores opções seguiu-se a implementação destas duas bibliotecas para escolher qual a mais indicada para o pretendido. Para tal foi criado um projeto no Android Studio para cada uma das bibliotecas e, usando dados fictícios para preencher os gráficos, efetuou-se uma análise cuidada das potencialidades de cada uma.
Por fim, concluiu-se que para além do design da biblioteca HelloCharts ser mais agradável e da melhor organização do código a característica referida acima que a destaca é ideal para o pretendido. Assim, o gráfico de barras na metade inferior do ecrã seria usado para dispor o número de clientes por dia onde o eixo dos x corresponderia aos dias e o eixo dos y ao número de clientes. A metade superior do ecrã apresentaria um gráfico de linhas que, consoante o dia selecionado no gráfico de barras, seria preenchido com o número de clientes por hora desse mesmo dia, em que o eixo dos x corresponderia às horas e o eixo dos y ao número de clientes.
31
5.3. Criação da aplicação Android
Esta foi a fase em que se deu início ao desenvolvimento da aplicação móvel, começando por criar um projeto padrão no Android Studio, isto é, com a estrutura de uma aplicação Android porém com uma particularidade, a atividade principal não teria qualquer conteúdo. De seguida procedeu-se à implementação da biblioteca no projeto e, consequentemente, do gráfico pretendido na atividade principal. Dado isto foram atribuídos dados fictícios ao gráfico e foram feitos testes em dispositivos com diferentes versões do Android assim como várias resoluções.
A aplicação requer uma versão do Android igual ou superior ao Jelly Bean (4.1.x). Esta escolha é fundamentada pela percentagem de dispositivos ativos com versão igual ou superior à referida na ordem dos 96,6%. A versão em causa trata-se do Software
Development Kit (SDK) 16 que oferece um maior leque de funcionalidades do Android e
permite a integração de muitas outras tecnologias, nomeadamente o Firebase.
Nesta fase foi ainda desenhado o ícone para a aplicação com base no logotipo da empresa como podemos verificar na figura que se segue:
Figura 19 - Ícone da aplicação Android
5.4. Configuração inicial do servidor
Esta etapa do projeto contempla as configurações iniciais do servidor, desde a programação do endpoint até à sua alocação na Google App Engine.
O primeiro passo foi a criação de um novo projeto na GAE e a atribuição de um nome seguido de um identificador único que seria utilizado mais tarde como parte do endereço do endpoint.
O segundo passo foi associar o projeto criado anteriormente ao Firebase. A opção de associar ou importar o projeto da GAE existe, pois, a empresa foi recentemente adquirida pela Google, o que evita a criação de um novo projeto.
32 Na Figura abaixo está representada a criação de um novo projeto na GAE do lado esquerdo da imagem e do lado direito a associação do projeto criado ao Firebase.
Figura 20 - Criação do projeto na GAE e posterior associação ao Firebase Após as configurações iniciais do projeto seguiu-se a programação do endpoint. A sua função seria receber posts da Meraki e trata-los de modo a reter apenas a informação mais relevante e de seguida guardar esses dados na base de dados em tempo real do
Firebase.
Os posts da Meraki são enviados em JavaScript Object Notation (JSON) e têm a estrutura de dados que podemos conferir na figura abaixo:
Figura 21 - Exemplo Post Meraki (ficheiro JSON)
Analisando a figura acima deparamo-nos com dicionários de dados onde cada chave corresponde a um valor, sendo que o valor poderá ser um outro dicionário. Os
33 dicionários, tal como os arrays, possuem um método de pesquisa, contudo essa pesquisa em vez de ser feita através da posição são usadas as chaves como referência [18].
A informação que se pretende retirar destes posts é o número de clientes que estão presentes na rede num determinado minuto. Assim, por cada post recebido é criado um dicionário local com a seguinte estrutura dict[data][hora]:
Data: yyyy/mm/dd o Hora: hh
Dado isto é feita uma pequena conversão da data com granularidade até à hora de
timestamp para inteiro, guardando os vários componentes em variáveis separadas
(data(yyyy-mm-dd) e hora(hh)).
Obtidos todos os dados necessários é executado um pequeno algoritmo para cada cliente:
if data in dict:
dict[data][hora] += 1 else:
dict[data] = {hora: 1}
Por fim, é feita a integração da API do Firebase no projeto em Python e, como a estrutura de dados utilizada por este serviço é baseada num ficheiro do tipo JSON, basta atualizar a base de dados em tempo real com o dicionário local [3].
5.5. Resolução de problemas no servidor
O código contruído anteriormente revelou falhas quando se verificou uma maior frequência de pedidos ao endpoint originando perdas de dados. Esse problema teve origem no facto do Firebase não ser transacional, isto é, se dois pedidos forem executados concorrentemente apenas o último a ser finalizado é contabilizado visto que ambos requisitam o valor da base de dados no mesmo instante, o que faz com que a informação do outro pedido seja descartada.
34 A figura 22 traduz o problema com pedidos concorrentes encontrados onde apenas um dos pedidos era processado.
Figura 22 - Esquema do tratamento de dois pedidos concorrentes
De modo a solucionar este problema decidiu-se utilizar a memcache da GAE para guardar os pedidos recebidos e de minuto a minuto executar um cron que enviaria os dados para o Firebase.
A memcache é um serviço da GAE usado para aumentar a velocidade de queries da datastore guardando o resultado das queries mais comuns e, consequentemente, caso outros pedidos sejam executados só será executada a query à datastore dos dados que não estão presentes na memcache. Contudo também pode ser usada para guardar ficheiros embora seja temporário dado tratar-se de uma cache e não de um sistema de armazenamento persistente. A memcache utiliza uma estrutura de dados em que a cada chave corresponde um valor [14].
É sobre esta última característica da memcache que incide a solução do problema. Com a utilização da memcache como intermediário o Firebase só receberá dados a cada minuto, resolvendo assim o problema de não ser transacional. A memcache possui uma função denominada cas (compare-and-set update) que trata este tipo de problemas pois apenas permite a atualização da chave da memcache caso esta não esteja já a ser acedida por outro processo. Se o acesso à chave falhar por esta já estar a ser acedida o pedido é efetuado assim que a chave esteja disponível.
A implementação da ideia teve de ser dividida em duas componentes, o endpoint que recebe os posts, trata a informação dos mesmos e guarda os dados na memcache e o
35 Começando pelo endpoint, o primeiro passo foi criar uma chave na memcache denominada ‘dadosAtualizados’ onde seria guardado um dicionário com dados provenientes dos posts recebidos. De seguida procedeu-se à atualização do valor dessa chave consoante os dados presentes nos posts recebidos através do algoritmo já utilizado na versão anterior do servidor que atualizava o número de clientes presentes numa determinada data e hora.
Por fim, o dicionário era atualizado na memcache utilizando a função cas de modo a evitar escritas concorrentes.
O cron, executado minuto a minuto, tinha como função atualizar a base dados em tempo real do Firebase e limpar a chave da memcache.
A primeira etapa do cron era importar os dados do Firebase, caso existissem, correspondentes às datas do dicionário guardado na memcache. Dado isto, o dicionário proveniente do Firebase e o dicionário da memcache eram fundidos, isto é, o dicionário do Firebase era atualizado com os dados do dicionário da memcache. Por fim, o dicionário resultante era enviado para o Firebase com os dados atualizados e a chave da
memcache era limpa para que estes dados não fossem novamente enviados no cron
seguinte.
A figura 23 traduz um esquema da solução implementada descrita nos últimos cinco parágrafos.
Figura 23 - Esquema de funcionamento do servidor com a implementação da memcache e do cron
36
5.6. Otimização do servidor
A etapa anterior do projeto continuou sem resolver todos os problemas do servidor e, desta feita, verificou-se que o uso da mesma chave para todos os posts não era escalável, isto é, caso o número de posts recebido aumentasse abruptamente o servidor bloquearia. Outra falha ainda importante fazia-se notar nos algoritmos desenhados anteriormente, caso um cliente permanecesse durante uma hora no mesmo local este apenas deveria ser contabilizado uma vez, porém a sua presença era registada 60 vezes visto que os posts são recebidos ao minuto.
A figura 24 demonstra o problema de contabilização do mesmo cliente mais que uma vez na mesma hora.
Figura 24 - Esquema da contabilização do mesmo cliente várias vezes na mesma hora De modo a solucionar o problema presente na imagem acima procedeu-se à otimização do servidor quer através do uso de uma chave para cada data com granularidade até à hora (yyyy-mm-dd-hh) quer pela implementação de um algoritmo denominado HyperLogLog que apenas considera elementos distintos, estimando o número de elementos diferentes com um determinado erro.
Inicialmente procedeu-se à alteração do sistema de chaves utilizado anteriormente. A chave ‘dadosAtualizados’ foi apagada e uma nova chave denominada ‘datasAtualizadas’ criada. O valor desta chave é gerado de maneira diferente dado tratar-se um conjunto de elementos, neste caso datas, e não de um dicionário de dados. A atribuição de valores a esta chave passa por quando se recebe um post, para cada cliente, guardar as datas (com granularidade até à hora) num conjunto de elementos únicos. As datas inseridas nessa chave correspondem a outras chaves criadas na memcache. Segue-se uma figura que ilustra a implementação da solução explicada neste parágrafo:
37 Figura 25 - Esquema de criação das chaves na memcache baseadas na data e hora e
adição das mesmas à chave 'datasAtualizadas'
As chaves cujo nome é a data referidas no parágrafo anterior têm um pequeno algoritmo de criação. À medida que os posts são recebidos, para cada cliente, é verificado se já existe uma chave com nome igual à data (com granularidade atá à hora). Caso exista a chave os seus dados são atualizados, caso contrário é criada uma chave com os dados recebidos. O valor de cada uma destas chaves é baseado no algoritmo HyperLogLog.
O algoritmo HyperLogLog (HLL), desenvolvido por Phillippe Flajolet, contabiliza elementos distintos e estima a cardinalidade de conjuntos de dados muito grandes utilizando poucos recursos não só computacionais, mas também temporais. O seu funcionamento passa por aplicar uma função hash criptográfica a cada elemento do conjunto de dados de modo a obter um conjunto de números aleatórios uniformemente distribuídos e guarda-los num array de tamanho fixo [2].
Neste caso específico, a função hash usada foi a Secure Hash Algorithm 1 (SHA-1) e esta produz um valor de dispersão de 160 bits, o que permite um número máximo de elementos de 2160.
O HyperLogLog, tal como referido acima, é constituído por um array que é calculado com base no erro escolhido. Quanto menor o erro maior o tamanho do array, o que diminui a probabilidade de dois elementos serem alocados na mesma posição.
O valor das chaves criadas para cada data diz respeito ao array HLL correspondente, onde são adicionados novos dados sempre que num post um cliente vem referenciado com essa data. A informação enviada para a função diz respeito à concatenação entre dois identificadores únicos como o local da rede onde o cliente foi detetado e o MAC address da placa de rede do dispositivo detetado. (exemplo: localid:mac -> d8aa472b6d331779e667f901314f0721d0f95769)
38 Dado isto, o array do HLL é atualizado com base no hash gerado que indica a posição do array onde será colocado o bit menos significante da hash caso seja maior do que o número já existente nessa posição. Através desta informação é possível calcular a cardinalidade estimada com base no erro definido anteriormente. Segue-se um esquema ilustrativo para uma melhor compreensão:
Figura 26 - Esquema de adição de um novo cliente ao HLL
O algoritmo tem alguns problemas como o ‘Birthday Paradox’ que diz que num conjunto de n pessoas escolhidas aleatoriamente existe uma probabilidade de algumas delas terem o mesmo dia de aniversário. Assumindo que todos os dias do ano têm a mesma probabilidade (excluindo 29 de fevereiro, ou seja, não considerando anos bissextos) conferimos que a probabilidade de duas pessoas terem nascido no mesmo dia alcança 50% com apenas 23 pessoas e 99,9% com 70 pessoas. Este acontecimento relaciona-se com o HLL na medida em que embora o número de hashes possíveis seja vasto, o número de possível entradas é ainda maior, existindo a possibilidade de duas entradas diferentes originarem duas saídas iguais [21].
Outro problema do algoritmo é a maneira como gera o número a partir da hash assim como a posição do array onde este é alocado que poderá originar erros na estimativa da cardinalidade dado estar relacionada com os elementos do array por meio de fórmulas matemáticas complexas.
As alterações efetuadas no endpoint também implicaram algumas alterações no
39 a chave ‘datasAtualizadas’ e, consequentemente, todas as chaves das datas aí referenciadas. O próximo passo diz respeito à importação dos dados referentes a essas mesmas datas do Firebase diretamente para um dicionário. Dado isto o dicionário era atualizado e enviado novamente para a base dados em tempo real. Por fim, a chave com as datas atualizadas era limpa para as chaves dessas datas não voltarem a ser consultadas novamente sem terem sofrido qualquer alteração. Segue-se um esquema ilustrativo da solução final:
Figura 27 - Esquema do funcionamento do servidor
5.7. Conclusão da aplicação Android
Esta foi a última fase de desenvolvimento da aplicação móvel onde se procedeu à implementação da API do Firebase no projeto Android e ainda à atualização dos gráficos em tempo real com os dados provenientes do Firebase.
A primeira etapa passou pelo estudo da API do Firebase para Android seguida da sua implementação [7]. Verificou-se que a integração com este sistema operativo móvel se encontra num nível bastante elevado, o que se poderá justificar pela Firebase ter sido adquirida pela Google em outubro de 2014.
A segunda e última etapa do projeto passou por substituir os dados fictícios anteriormente usados para a elaboração do gráfico pelos dados provenientes da base de dados em tempo real. Os dados do Firebase são recebidos através de datasnapshots que nos permitem
40 iterar pelo dicionário de dados e obter a chave, usada para legendar o eixo dos x no gráfico de barras, e o valor, usado para contabilizar o número de pessoas ativas em determinado momento. Estes dados provenientes do Firebase são atualizados sempre que alguma alteração é verificada na base de dados e, por conseguinte, os gráficos são também atualizados em tempo real.
A figura 28 apresenta a aplicação desenvolvida para Android em funcionamento nas suas duas fases, antes de um dia ser selecionado e após um dia ser selecionado, mostrando a oscilação do número de clientes ao longo desse dia.
41
6. Conclusão
O estágio realizado na GoWi-Fi no Aveiro Business Centre consistiu no desenvolvimento de uma aplicação para Android com o objetivo de mostrar estatísticas de presenças em tempo real assim como um histórico numa janela temporal.
Primeiramente foram apresentados objetivos para o desenvolvimento do projeto, objetivos esses que foram implementados embora viessem a ser moldados ao longo do tempo de modo a produzir uma melhor solução. A alteração dos objetivos teve origem nas reuniões com a equipa onde o trabalho era analisado e, consequentemente, novas ideias sugeridas.
A fase de desenvolvimento do projeto enfrentou, naturalmente, alguns problemas a nível de implementação de código e a nível de solução final pois a má interpretação dos objetivos originaria uma solução que não era a ideal. Por conseguinte foi necessária uma rápida adaptação justificada também pela volatilidade dos requisitos.
Dado o projeto ter sido desenvolvido em contexto de estágio tive a oportunidade de trabalhar juntamente com profissionais do ramo e integrar uma equipa no mundo do trabalho, o que foi sem dúvida uma mais valia pelos métodos de trabalho criados, mas sobretudo pelos conhecimentos que me foram transmitidos.
A minha opinião pessoal sobre este estágio é muito positiva destacando, para além da experiência de trabalho referida anteriormente, a oportunidade de trabalhar com tecnologias que desconhecia totalmente. Consequentemente foram encontradas dificuldades relativas às novas tecnologias que implicaram pesquisas extensas e muito estudo das mesmas. Embora as tecnologias fossem desconhecidas, a motivação em buscar do conhecimento adquirida na instituição foi essencial para ultrapassar todos os obstáculos.
Em título de conclusão refiro que os objetivos propostos para o projeto em contexto de estágio foram realizados com sucesso, estando a aplicação Android assim como todo o
back-end totalmente funcionais. A aplicação está pronta para ser disponibilizada aos
clientes GoWi-Fi que queiram consultar as estatísticas sobre o seu estabelecimento, apenas sendo necessário uma pequena adaptação dado a aplicação ter sido desenvolvida num contexto geral para toda a rede GoWi-Fi.
42
Glossário
Termo
Descrição
Access Point (AP) é um hardware de rede que tem a função de emitir um sinal sem fios, permitindo aos dispositivos também sem fios aceder à rede.
Android TV televisão inteligente desenvolvida pela Google com software Android.
App diminutivo para aplicação.
Application
Programming Interface (API)
conjunto de subrotinas, protocolos e ferramentas para desenvolver software e aplicações.
Array estrutura de dados composta por vários elementos separados por vírgulas.
Backend as a Service (BaaS)
computação em nuvem cujo objetivo é facilitar a instalação, uso e operacionalidade de servidores cloud para os smartphones e aplicações web.
Back-end aplicação ou programa que serve ou suporta indiretamente os serviços de front-end.
Broadcast distribuição de conteúdo por vários dispositivos.
Business-to-business (B2B)
comércio estabelecido entre empresas.
Business-to-client (B2C) comércio efetuado diretamente entre a empresa produtora e o consumidor final.
Cache dispositivo de acesso rápido que serve de intermediário entre um operador de um processo e de armazenamento.
Capital Expenditure (CAPEX)
despesas de investimento.
Captive Portal página apresentada por hardware da camada 2 ou 3 OSI antes do utilizador ter acesso à rede.
43
Cloud é um modelo que permite o acesso ubíquo, conveniente a pedido, através da rede, a um conjunto de recursos de computação partilhados, que podem ser aprovisionados ou libertados, com um mínimo esforço e sem interação com o fornecedor.
Cluster elemento de uma rede de computadores que efetua processamento juntamente com outros nós para o mesmo fim, podendo ser vistos como um único computador.
Compare-and-set update comparação inicial do valor atual com o novo e posterior atualização do mesmo.
Cron gestor de tarefas que executa tarefas em determinados intervalos de tempo.
Dashboard interface que mostra ao utilizador estatísticas em tempo real através de gráficos.
Datasnapshots contém dados de uma localização específica do Firebase.
Data Store repositório de armazenamento de dados.
Data Analytics processo de inspecionar, limpar, transformar e modelar dados com o objetivo de encontrar informação útil.
Debugger programa que testa e executa outros programas.
Django open-source web framework que visa facilitar a criação de
sites com base de dados.
Drag-and-drop ato de arrastar e largar
Endpoint ponto de comunicação utilizado pelas aplicações.
Framework plataforma com características genéricas que facilita o desenvolvimento de software com base na plataforma utilizada.
Front-end aplicação com a qual o utilizador final interage.
Google Cloud Messaging serviço móvel que permite o envio de notificações para
dispositivos Android.
Gradle sistema que otimiza a execução de código
Hardware elementos físicos que constituem um sistema computacional.
44
HyperLogLog algoritmo que contabiliza elementos distintos e estima a cardinalidade de conjuntos de dados muito grandes utilizando poucos recursos computacionais e temporais.
Hypertext Transfer Protocol (HTTP)
protocolo de comunicação utilizado para sistemas de informação.
Hyper Text Transfer Protocol Sercure (HTTPS)
protocolo HTTP sobre uma camada de segurança que utiliza o protocolo SSL/TLS.
ID Identificador.
Imagens raster estrutura de pontos organizados por meio de uma matriz de dados.
Issue questão ou neste caso objetivo.
Java Script Object Notation (JSON)
tipo de ficheiro usado para transferir dicionários de dados.
Jelly Bean versão do Android 4.3.x.
Lint ferramenta que controla o performance, usabilidade, compatibilidade entre outros problemas.
Login ato de aceder a um sistema por meio de um nome de utilizador e respetiva senha.
MAC Address endereço constituído por um conjunto de 6 bytes separados por dois pontos ou hífen, sendo cada byte representado por dois algarismos na forma hexadecimal, em que a primeira metade diz respeito à norma IEEE e a segunda metade ao fabricante, perfazendo um total de 48 bits.
MapReducers modelo de programação que visa processar e gerar grande quantidade de dados paralelamente (algoritmo de distribuição por clusters).
Memcache sistema usado para aumentar o performance de queries a base de dados.
Open-source software no qual a código fonte está disponível sobre uma licença que permite o estudo, alteração e distribuição do mesmo.
45
Operational expenditure (OPEX)
despesas de manutenção e gastos de consumíveis.
Password senha.
Plataform as a Service (PaaS)
serviço de fornecimento de uma plataforma de trabalho.
Player jogador ou concorrente.
Play Store loja da Google presenta no Android.
Providers prestadores ou fornecedores.
Post pedido HTTP usado pela WWW cuja função é transmitir os dados incluídos no seu corpo de modo a serem guardados pelo servidor web destino.
Powered no contexto utilizado o seu significado é proveniente ou disponibilizada por.
Proguard ferramenta de otimização de código Java.
Query pesquisa de informação numa base de dados.
Representational state transfer (REST)
estilo de desenvolvimento web que visa aumentar o performance, confiabilidade e o escalonamento.
Router dispositivo que transmite pacotes de dados entre redes diferentes.
Sandbox executa programas não testados sem afetar a máquina ou qualquer outro programa em execução.
Scroll ato de percorrer a informação presente no ecrã.
Secure Hash Algorithm 1 (SHA-1)
função hash criptográfica a cada elemento do conjunto de dados de modo a obter um conjunto de números aleatórios uniformemente distribuídos e guarda-los num array de tamanho fixo.
Service set identification (SSID)
conjunto único de caracteres que identifica uma rede sem fios
Short Message Service (SMS)
serviço de envio de mensagens ao nível das redes telefónicas.
Smartphone telemóvel com um sistema operativo avançado que combina as funções de um computador pessoal com as características habituais de um telemóvel vulgar.