Universidade de Aveiro Departamento de Eletrónica,Telecomunicações e Informática 2019
Raquel Oliveira
Universidade de Aveiro Departamento de Eletrónica,Telecomunicações e Informática 2019
Raquel Oliveira
Ramos
da qualidade do ar
Sistema móvel para divulgação do estado e previsão
Dissertação apresentada à Universidade de Aveiro para cumprimento dos requisitos necessários à obtenção do grau de Mestre em Engenharia de Computadores e Telemática, realizada sob a orientação científica do Doutor Ilídio Castro Oliveira, Professor auxiliar do Departamento de Eletrónica, Telecomunicações e Informática da Universidade de Aveiro, e do Doutor Miguel Sala Coutinho, Investigador do Instituto do Ambiente e Desenvolvimento da Universidade de Aveiro.
o júri / the jury
presidente / president Professor Doutor José Luis Guimarães Oliveira
Professor Associado com Agregação do Departamento de Eletrónica, Telecomunicações e Infor-mática da Universidade de Aveiro
vogais / examiners committee Professor Doutor Ciro Alexandre Domingues Martins
Professor Adjunto da Escola Superior de Tecnologia e Gestão de Águeda
Professor Doutor Ilídio Fernando de Castro Oliveira
Professor Auxiliar do Departamento de Eletrónica, Telecomunicações e Informática da Universi-dade de Aveiro
agradecimentos /
acknowledgements Gostaria de agradecer ao professor Ilídio Oliveira, orientador desta dissertação, portoda a disponibilidade e apoio prestado ao longo do tempo em que a dissertação foi desenvolvida. Agradeço também ao Miguel Coutinho e João Ginja do IDAD por toda a disponibilidade e apoio nesta cooperação para o desenvolvimento da dissertação, que foi extremamente essencial para o desenvolvimento deste projeto. A eles, um grande obrigada. A todos os meus amigos que me acompanharam durante este último ano e que tiveram sempre paciência para me aturar, o meu muito obrigada. Um agradecimento especial ao Tiago Ramalho, Domingos Nunes, Ricardo Jesus e Diogo Ferreira. Por último e não menos importante, o meu enorme obrigada à minha mãe que, apesar de todos os percalços e incovenientes, sempre fez de tudo para me apoiar e para que nada me faltasse.
Palavras Chave Qualidade do ar, aplicação móvel, telemetria, alarmística, aquisição e agregação de dados
Resumo A qualidade do ar é cada vez mais uma preocupação nos dias de hoje, sendo considerada uma componente determinante para a saúde pública e o equilíbrio dos ecossistemas. A monitorização da qualidade do ar faz parte da missão de agências públicas e institutos de investigação, como é o caso do IDAD. Um dos trabalhos nesta área consiste em realizar campanhas de recolha de dados, obtidos por senso-res, para caraterizar a qualidade do ar em diferentes contextos (ex: aeroportos). Os dados são recolhidos com sistemas proprietários e independentes, sendo benéfico poder agregá-los numa plataforma única. Este trabalho apresenta um ambiente
web para acesso integrado aos dados de monitorização de diferentes campanhas,
recolhidos por diferentes equipamentos. Para além disso, foi desenvolvida uma aplicação para comunicar a informação da qualidade do ar. A aplicação pode ser usada por um investigador ou cliente do IDAD fornecendo acesso a informação meteorológica e de previsão de qualidade do ar, tendo também acesso aos parâ-metros da qualidade do ar das campanhas relevantes. Os ambientes encontram-se em utilização piloto pelas equipas do IDAD.
Keywords Air quality, mobile application, telemetry, configuration of alarms, data acquisition and aggregation
Abstract Nowadays, air quality is becoming a more relevant aspect and is considered to be a determining component for public health and ecosystem balance. Air quality monitoring is part of the mission of public agencies and research institutes such as IDAD. An ongoing job in this area is to conduct sensor-based data collection campaigns to characterize air quality in different contexts (e.g., airports). Data is collected with proprietary and independent systems, and aggregated into a single platform. This paper presents a web environment for integrated access to monitor data from different campaigns collected by different devices. Also, a mobile appli-cation has been developed to communicate air quality information. The appliappli-cation can be used by a researcher or IDAD client by providing weather and air quality forecast information, allowing access to the air quality parameters of the relevant campaigns. IDAD teams have been using both platforms.
Conteúdo
Conteúdo i
Lista de Figuras v
Lista de Tabelas vii
Glossário ix 1 Introdução 1 1.1 Motivação . . . 1 1.2 Objetivos . . . 2 1.3 Estrutura da Dissertação . . . 3 2 Estado da Arte 5 2.1 Qualidade do Ar . . . 5 2.1.1 Definição . . . 5
2.1.2 Cálculo do Índice QualAr . . . 6
2.1.3 Classes do Índice . . . 7 2.1.4 Aplicações Existentes . . . 8 2.2 Desenvolvimento Web . . . 11 2.2.1 Backend . . . 11 2.2.2 Frontend . . . 12 2.2.3 Containers . . . 13
2.3 Desenvolvimento de Aplicações Móveis . . . 15
2.3.1 Plataforma Android . . . 16
2.3.2 Plataforma iOS . . . 18
2.3.3 Soluções Cross-Platform . . . 19
2.3.4 Padrões de Arquitetura em Aplicações Móveis . . . 20
3 Solução Anterior 25 3.1 Solução Existente . . . 25
3.2 Fontes de Informação . . . 26
3.3 Limitações e Oportunidades . . . 27
4 Requisitos do Sistema 29 4.1 Processos associados à monitorização da qualidade do ar . . . 29
4.2 Casos de Utilização . . . 31
4.2.1 Atores . . . 31
4.2.2 Casos de utilização da plataforma web . . . 31
4.2.3 Casos de utilização da aplicação móvel . . . 34
4.3 Requisitos não funcionais . . . 36
5 Arquitetura do Sistema 37 5.1 Arquitetura dos Componentes . . . 37
5.1.1 Watchdog no LabQAr . . . 38 5.1.2 RabbitMQ . . . 38 5.1.3 Servidor . . . 39 5.1.4 Plataforma Web . . . 39 5.1.5 Air Pointer . . . 39 5.1.6 Aplicação Móvel . . . 40
5.2 Interação entre Componentes . . . 40
5.3 Interação com Sistemas Externos . . . 41
5.4 Modelo de Dados . . . 42 5.4.1 LabQAr . . . 42 5.4.2 Air Pointer . . . 44 5.4.3 IPMA . . . 44 5.4.4 GEMAC . . . 45 6 Implementação 47 6.1 Módulo do Backend . . . 47 6.1.1 Conector do LabQAr . . . 49
6.1.2 Conector do Air Pointer . . . 50
6.1.3 Conector para a previsão da qualidade do ar . . . 51
6.1.4 Base de Dados . . . 52 6.1.5 Containers . . . 52 6.2 API de Integração . . . 55 6.3 Plataforma Web . . . 58 6.3.1 Overview . . . 58 6.3.2 Interface do Administrador . . . 59
6.4 Aplicação Móvel . . . 62
6.4.1 Overview . . . 62
6.4.2 Implementação das Funcionalidades . . . 71
6.5 Garantia de Qualidade . . . 74 6.5.1 Plataforma Web . . . 75 6.5.2 Aplicação Móvel . . . 76 7 Resultados 81 7.1 Solução desenvolvida . . . 81 7.1.1 Plataforma Web . . . 81 7.1.2 Aplicação Móvel . . . 85 7.2 Utilização Exploratória . . . 92 8 Conclusão 93 8.1 Trabalho Desenvolvido . . . 93 8.2 Trabalho Futuro . . . 94 Referências 95 Apêndice A 99 Plataforma Web . . . 99 Aplicação Móvel . . . 100
Lista de Figuras
2.1 Estações de Monitorização da Qualidade do Ar em Portugal. . . 7
2.2 Classes do Índice QualAr. . . 8
2.3 Esquema de um container. . . . 14
2.4 Gráfico dos sistemas operativos e seu uso pelos utilizadores de smartphones (Julho 2018 -Julho 2019). . . 16
2.5 Arquitetura Model-View-Controller. . . 21
2.6 Arquitetura Model-View-Presenter. . . 22
2.7 Arquitetura Model-View-ViewModel. . . 23
3.1 Arquitetura da solução anterior. . . 26
3.2 Sensores instalados no LabQAr. . . 27
4.1 Monitorização da qualidade do ar. . . 30
4.2 Casos de utilização da plataforma web. . . 33
4.3 Casos de utilização da aplicação móvel. . . 35
5.1 Proposta de arquitetura para a solução desenvolvida. . . 38
5.2 Diagrama de interação dos componentes. . . 41
5.3 Esquema de interação dos sistemas externos com a plataforma web e a aplicação móvel. . 42
5.4 Tabelas da base de dados local do LabQAr. . . 43
5.5 Dados provenientes do Air Pointer. . . 44
5.6 Tabelas dos dados pedidos à API do IPMA. . . 45
5.7 Tabelas dos dados usados do projecto do GEMAC. . . 45
6.1 Poluente Dióxido de Enxofre (SO2) presente na tabela Parametro_Local da base de dados. 48 6.2 Interface do administrador gerada pelo Django. . . 59
6.3 Interface do administrador onde é possível a visualização dos diferentes utilizadores bem como a criação dos mesmos. . . 60
6.4 Interface do administrador onde é possível gerir as várias permissões dos utilizadores. . . 60
6.6 Interface com as medições dos poluentes. . . 75
6.7 Interface com as medições dos poluentes. . . 76
6.8 Dispositivos Android onde a aplicação foi testada. . . 78
6.9 Dispositivos iOS onde a aplicação foi testada. . . 79
7.1 Visualização da qualidade do ar consoante os últimos dados recolhidos. . . 82
7.2 Visualização da qualidade do ar nas últimas 24 horas. . . 82
7.3 Medições dos vários parâmetros. . . 83
7.4 Visualização da variação dos parâmetros nas últimas 24 horas. . . 83
7.5 Visualização da variação dos parâmetros ao longo da campanha escolhida. . . 84
7.6 Visualização dos alertas detetados para os alarmes definidos pelo utilizador. . . 84
7.7 Visualização da previsão da qualidade do ar. . . 85
7.8 Interface com as medições dos poluentes (GEMAC). . . 86
7.9 Interface com as informações fornecidas pelo projeto. . . 87
7.10 Interface com os dados do Instituto Português do Mar e Atmosfera (IPMA). . . 88
7.11 Representação da qualidade do ar. . . 88
7.12 Interface com as medições dos poluentes. . . 89
7.13 Visualização dos alertas detetados para os alarmes definidos pelo utilizador. . . 90
7.14 Visualização dos dados adquiridos pelo Air Pointer. . . 91
7.15 Informação sobre a nomenclatura e cores usadas para a classificação da qualidade do ar. . 91
1 Login do utilizador na plataforma web. . . 99
2 Selecção da campanha ou datas. . . 100
3 Alteração dos dados do utilizador. . . 100
4 Interface para a autenticação do utilizador. . . 101
5 Visualização dos dados e contactos dos responsáveis pelo projeto. . . 101
6 Navigation drawer para a navegação do utilizador na aplicação. . . 102
Lista de Tabelas
2.1 Funcionalidades das aplicações existentes para a monitorização da qualidade do ar. . . . 11
4.1 Tabela descritiva dos casos de uso da plataforma web. . . . 32
4.2 Tabela descritiva dos casos de uso da aplicação móvel. . . 34
4.3 Especificação dos requisitos não funcionais. . . 36
6.1 REST API: Pedidos, respostas e descrições dos vários pedidos. . . 58
Glossário
IDAD Instituto do Ambiente e Desenvolvimento
CCDR Comissões de Coordenação e Desenvolvimento Regional
VL Valores Limite
PM10 Partículas com diâmetro inferior a 10 micrómetros (µm)
PM2.5 Partículas com diâmetro inferior a 2.5 micrómetros (µm)
NO2 Dióxido de Azoto
O3 Ozono
SO2 Dióxido de Enxofre
CO2 Dióxido de Carbono
OMS Organização Mundial de Saúde
DRA Direções Regionais do Ambiente
IPMA Instituto Português do Mar e Atmosfera
CAMS Serviço de Monitorização Atmosférico Copernicus
JDK Java Development Kit
LLVM Low Level Virtual Machine
HTML HyperText Markup Language
CSS Cascading Style Sheets
JS JavaScript
PWA Progressive Web Applications
MVC Model-View-Controller MVP Model-View-Presenter MVVM Model-View-ViewModel UI User Interface PaaS Platform-as-a-Service VM Virtual Machine VMs Virtual Machines LXC Linux Containers
UFS Unix File System
PID Process Identification Number
IPC Inter-Process Communication
ppm partes por milhão
CO Monóxido de Carbono
NO Monóxido de Azoto
NOx Óxidos de Azoto
STIC Serviços de Tecnologias de Informação e Comunicação
GCM Google Cloud Messaging
AMQP Advanced Messaging Queue Protocol
GEMAC Grupo de Emissões, Modelação e Alterações Climáticas
UA Universidade de Aveiro
URL Uniform Resource Locator
SGBD Sistemas de Gestão de Bases de Dados
ODBC Open Database Connectivity
IP Internet Protocol
HTTP Hypertext Transfer Protocol
API Application Programming Interface
REST Representational State Transfer
MTV Model-Template-View
GSON Google Json
JSON JavaScript Object Notation
BLoC Business Logic Component
APA Agência Portuguesa do Ambiente
GPS Global Positioning System
MMS Multimedia Messaging Service
XML Extensible Markup Language
IP Internet Protocol
SQL Structured Query Language
NoSQL Not Only Structured Query Language
NoSQL Not Only Structured Query Language
CAPÍTULO
1
Introdução
A qualidade do ar é o termo usado para traduzir o grau de poluição presente no ar. Este aspeto é importante e deve ser frequentemente analisado pois a poluição no ar tem um forte impacto na saúde do ser humano, para além de contribuir para as alterações climáticas que se fazem sentir nos dias de hoje, danificando assim os ecossistemas. Existem várias fontes de poluição do ar e que são de conhecimento geral, como, por exemplo, os transportes rodoviários, a indústria e suas fábricas, e a produção de energia. Qualquer pessoa pode contribuir em diversas soluções alternativas para que se diminua a emissão de poluentes para a atmos-fera, tais como usar mais frequentemente transportes públicos ou fazer a reciclagem em casa [1].
Com a evolução da tecnologia, através de equipamentos como computadores ou telemóveis e sensores, é possível poder acompanhar e estudar a presença de determinados poluentes na atmosfera bem como a concentração de cada um. Desta forma, a informação recolhida pode ser armazenada, estudada e utilizada de maneira a que seja possível tomar as melhores decisões, preservando assim o meio ambiente e oferecendo as melhores condições de vida aos seres vivos e seus ecossistemas.
A qualidade do ar é algo que afecta qualquer ser vivo, e como tal, é interessante explorar novos e mais fáceis mecanismos de como se pode estudar e perceber a qualidade do ar e como se pode melhorar a mesma. É com este objetivo que são desenvolvidas plataformas para visualização de dados da qualidade do ar; sejam programas, plataformas web ou aplicações móveis.
1.1 Motivação
A maior motivação para o desenvolvimento deste trabalho prende-se com a necessidade de criar novas plataformas para visualização de dados em diferentes equipamentos, facilitando a análise e investigação dos dados referentes à qualidade do ar, bem como atualizar as já
existentes.
O Instituto do Ambiente e Desenvolvimento (IDAD), Instituto do Ambiente e Desenvol-vimento, é uma associação científica e técnica fundada em 1993, sem fins lucrativos, com utilidade pública, que atua ao nível do apoio integrado às necessidades ambientais do mundo das empresas e organizações. Em colaboração com as mesmas, o IDAD tem em vista a transição para a sustentabilidade, atuando em três principais áreas de intervenção: poluição atmosférica, avaliação de impactos e monitorização ambiental e sustentabilidade. Como forma de apoio a projetos, o IDAD possui um laboratório móvel, bem como equipamentos independentes que serão usados nesta dissertação [2].
O IDAD, como detentor de uma vasta experiência na monitorização da qualidade do ar, possui equipamentos relevantes para a aquisição de dados em tempo real. Estes podem ser consultados e analisados em diversas fontes de informação, sendo que, de forma a rentabilizar a investigação, um cenário ideal incluiria todos eles numa única plataforma onde possam ser acedidos por por todas as pessoas autorizadas e em diversos dispositivos como computadores ou dispositivos móveis.
Estima-se que, em todo o mundo e todos os anos, morram aproximadamente 1.3 milhões de pessoas como consequência da poluição do ar em ambiente urbano [1]. Como a qualidade do ar é uma componente relevante do ambiente, bem como um fator determinante da saúde pública e do equilíbrio dos ecossistemas, este trabalho vai de encontro à necessidade da aquisição e interligação de dados de diversos equipamentos e plataformas, contribuindo desta forma para o desenvolvimento de uma solução eficaz na gestão da qualidade do ar.
1.2 Objetivos
O principal objetivo desta dissertação é criar uma solução que esteja disponível em várias plataformas e que permita a aquisição e visualização de dados dos equipamentos disponíveis no IDAD, bem como a inclusão de dados de fontes externas públicas. Os objetivos deste trabalho são os seguintes:
• Reativação e migração da plataforma web já existente;
• Desenvolvimento de uma aplicação móvel cross-platform que inclua os dados presentes na plataforma web;
• Extensão da solução anterior para aquisição de dados de vários pontos de recolha; • Integração de fontes de informação públicas, relacionadas com a previsão da qualidade
1.3 Estrutura da Dissertação
Esta dissertação encontra-se dividida em 8 capítulos.
No capítulo 1, encontram-se apresentados os objetivos do trabalho a ser desenvolvido e a motivação para o mesmo.
No capítulo 2, é abordado o contexto do problema e quais as melhores tecnologias a usar em cada vertente para chegar à solução pretendida. Neste contexto, serão revistos conceitos acerca das métricas usadas na investigação da qualidade do ar, tal como um estudo sobre o desenvolvimento de aplicações móveis.
No capítulo 3, será abordado o sistema de recolha de dados pré-existente bem como as suas limitações.
No capítulo 4, serão explicados os requisitos do sistema de modo a que o mesmo seja desenvolvido de acordo com as necessidades dos utilizadores que irão usufruir do mesmo.
No capítulo 5, será explicada a arquitetura do sistema e como os diversos componentes da solução desenvolvida interagem entre si.
No capítulo 6, será explicada detalhadamente a implementação de todo o sistema e seus componentes.
No capítulo 7, serão apresentados os resultados onde estará refletida a avaliação do IDAD ao sistema desenvolvido e a utilização exploratória do mesmo.
Para finalizar, o capítulo 8, apresenta a conclusão da dissertação, uma análise do trabalho realizado e que trabalho futuro é proposto para melhorar a solução obtida.
CAPÍTULO
2
Estado da Arte
2.1 Qualidade do Ar
2.1.1 Definição
O índice da qualidade do ar é um valor obtido diariamente nas estações existentes para este efeito. Estas estações são geridas pelas Comissões de Coordenação e Desenvolvimento Regional (CCDR) em Portugal continental e pelas Direções Regionais do Ambiente (DRA) nas regiões autónomas dos Açores e da Madeira.
Para além de um valor numérico, este índice permite adequar comportamentos e ações no sentido da proteção da saúde humana pois é através da análise dos resultados deste valor que se consegue determinar qual o estado da qualidade do ar diariamente.
A legislação da União Europeia estipulou Valores Limite (VL) e limiares de informação e alerta para os níveis de qualidade do ar a curto prazo (horário ou diário) e a longo prazo (anualmente) relativamente aos poluentes relevantes tais como:
• Partículas com diâmetro inferior a 10 micrómetros (µm) (PM10); • Partículas com diâmetro inferior a 2.5 micrómetros (µm) (PM2.5);
• Dióxido de Azoto (NO2);
• Dióxido de Enxofre (SO2);
• Ozono (O3).
Para os níveis de longo prazo, os VL são mais restritivos do que em relação aos de curto prazo, dado que a exposição a longo prazo a determinados poluentes pode afetar gravemente a saúde do ser humano [3].
2.1.2 Cálculo do Índice QualAr
O índice QualAr consiste numa classificação baseada nas concentrações dos poluentes registadas nas estações de qualidade do ar (monitorizado hora a hora). Para esta classificação, foi elaborada uma escala de cores dividida em cinco classes, em que cada classe representa um tipo de aviso [4]:
• Mau: toda a população deve evitar atividades físicas ao ar livre. Os grupos mais sensíveis, tais como crianças, idosos e indivíduos com problemas no sistema respiratório, deverão permanecer em casa com as janelas fechadas e utilizar sistemas de circulação/refrigeração do ar;
• Fraco: pessoas sensíveis, tais como crianças, idosos e indivíduos com problemas a nível respiratório, devem evitar atividades ao ar livre. Deste grupo de pessoas, aos quais tenha sido diagnosticado um problema do foro respiratório ou cardiovascular, devem ainda respeitar os tratamentos médicos em curso e procurar cuidados médicos caso os seus sintomas se agravem. A população em geral deve evitar a sua exposição a outros fatores de risco;
• Médio: pessoas sensíveis, tais como crianças e idosos, devem limitar as suas atividades ao ar livre;
• Bom: nenhum aviso;
• Muito Bom: nenhum aviso.
O cálculo do índice é efetuado tendo em conta as médias aritméticas dos poluentes, cuja medição é realizada nas estações de qualidade do ar, de acordo com os seguintes critérios [3]:
• Zonas: é obrigatória a medição dos poluentes O3 e partículas PM10 ou PM2.5;
• Aglomerações: é obrigatória a medição dos poluentes NO2 e partículas PM10 ou PM2.5.
Para o cálculo, pode-se ainda incluir o poluente SO2 caso haja medições do mesmo.
A classificação do índice é disponibilizada segundo dois níveis de informação, apresentado ao nível da [3]:
• Zona/Aglomeração: o índice global numa certa área é determinado pelo pior resultado obtido em relação aos poluentes monitorizados nas estações em cada área, sendo que os poluentes com a concentração mais elevada serão os responsáveis pelo índice;
• Estação: o índice QualAr pode ser determinado em dois níveis diferentes:
– Índice QualAr Global, determinado pelo pior resultado obtido em relação aos
poluentes monitorizados sendo que, mais uma vez, os poluentes com concentração mais elevada são os responsáveis por este índice;
– Índice QualAr por Poluente, calculado para os diferentes poluentes (NO2, O3,
PM10, PM2.5) e para o próprio dia. Resulta da comparação dos valores médios me-didos mais recentemente com as gamas de concentrações definidas na escala de cores. No mapa apresentado na figura 2.1 estão presentes vários balões. Estes balões representam as localizações das estações de qualidade do ar, os quais têm a si cores atribuídas. Estas cores correspondem ao índice QualAr registado, permitindo assim tirar conclusões acerca do estado da qualidade do ar na região onde se encontra cada estação [5].
Figura 2.1: Estações de Monitorização da Qualidade do Ar em Portugal.
As cores apresentadas, na figura 2.1, em cada estação, podem corresponder a três tipos diferentes de informação [3]:
• Cor sólida: existem dados suficientes para o cálculo do índice sendo que, para o dia atual, correspondem a dados das últimas três horas;
• Cor com transparência: índice calculado com dados medidos há mais de três horas; • Cor cinzenta: não existem dados suficientes para o cálculo do índice.
2.1.3 Classes do Índice
Como referido na secção 2.1.2, existem cinco intervalos diferentes de classificação do índice: Mau, Fraco, Médio, Bom e Muito Bom. Estes intervalos já sofreram algumas alterações de acordo com os valores recomendados na legislação vigente da qualidade do ar, nomeadamente nos anos entre 2001 e 2010.
No início de 2019, efetuou-se uma revisão da metodologia do cálculo do índice. Esta revisão deveu-se ao aprofundamento do conhecimento dos efeitos dos poluentes na saúde pública e na alteração do referencial para os valores recomendados pela Organização Mundial de Saúde (OMS), levando então a valores mais restritivos em alguns intervalos das várias classes [3]. Na tabela da figura 2.2 é possível observar-se os novos valores e classes para diferentes poluentes.
Figura 2.2: Classes do Índice QualAr.
2.1.4 Aplicações Existentes
Atualmente existem diversas aplicações e plataformas dedicadas à visualização e análise dos dados recolhidos nas estações de qualidade do ar, sejam elas aplicações do tipo desktop como mobile. Vários exemplos dessas aplicações serão analisados seguidamente.
QualAr [6]
Esta aplicação, desenvolvida pela Agência Portuguesa do Ambiente (APA), permite ao utilizador manter-se informado, em tempo real, acerca da qualidade do ar que respira. Esta fornece as seguintes funcionalidades:
• Verificação da previsão da qualidade do ar numa determinada localização; • Consulta dos avisos e conselhos de saúde consoante o índice QualAr previsto; • Previsão da qualidade do ar num destino europeu;
• Verificação dos índices da qualidade do ar na estação mais próxima do utilizador (Fonte: CCDR/DRA);
• Previsão metereológica em locais de interesse (Fonte: Instituto Português do Mar e Atmosfera (IPMA)).
O serviço da previsão da qualidade do ar é fornecido pela Universidade de Aveiro (UA) e complementado, se necessário, pelo Serviço de Monitorização Atmosférico Copernicus (CAMS).
BreezoMeter [7]
Esta plataforma, desenvolvida pela BreezoMeter, encontra-se disponível em 93 países e
contém dados acerca do índice da qualidade do ar (poluentes como PM10, NO2, NOx, CO,
para pais, atletas que pratiquem atividades ao ar livre e pessoas que tenham doenças do foro respiratório e cardiovascular. A BreezoMeter é reconhecida pela sua análise dos dados da qualidade do ar em tempo real, oferecendo:
• Mapas com dados sobre a qualidade do ar em tempo real; • Recomendações de saúde personalizáveis;
• Notificações quando se verificam mudanças na qualidade ao ar, fornecendo ao utilizador a possibilidade de guardar as suas localizações favoritas e monitorizar a qualidade do ar nesta localizações durante todos os dias da semana, a qualquer hora.
Através de algoritmos de dispersão que calculam a qualidade do ar em mais de 300 mi-lhões de localizações de hora a hora, é possível depreender como é que a qualidade do ar se move e dispersa, conseguindo observar-se na plataforma uma previsão de cinco horas da mesma.
AirVisual [8]
Esta plataforma, desenvolvida pela IQAir, foca-se na visualização de dados da quali-dade do ar com prévia análise dos mesmos, contendo ainda dados metereológicos. Esta permite:
• Dar a conhecer ao utilizador a qualidade do ar na localização do mesmo (através de auto-localização);
• Informar o utilizador de quais as ações a tomar mediante a poluição do ar;
• Visualização de dados de diversos poluentes: PM2.5, PM10, O3, NO2, CO2 e SO2;
• Previsão da qualidade do ar durante sete dias permitindo ao utilizador planear as suas atividades no exterior durante as alturas em que a qualidade do ar não apresente valores prejudiciais;
• Alertar o utilizador quando os valores da qualidade do ar não estiverem de acordo com os seus standards;
• Visualizar notícias sobre poluição do ar e recursos educacionais relacionado com este tema.
Air Matters [9]
Esta aplicação, desenvolvida pela Air-Matters, fornece informação do índice da qualidade do ar em tempo real, dados da dispersão e quantidade de pólen, previsão metereológica e recomendações relativamente à exposição à poluição. As principais funcionalidades que esta aplicação fornece são:
• Visualizar dados de mais de 10000 estações de monitorização da qualidade do ar. Existem dados de mais de 50 países sendo que a informação fornecida ao utilizador é dada pela estação de monitorização mais próxima do mesmo;
• Visualização de informações sobre a dispersão do pólen no ar (apenas para os Estados Unidos da América, Alemanha, Áustria e Suiça);
• Fornecer alertas sobre a poluição e o pólen;
• Possibilidade de conectar a aplicação a um purificador de ar (Purificador de Ar da Philips) ou a um dispositivo de monitorização do ar (Kaiterra Laser Egg), controlando-o assim remotamente e tendo ainda a oportunidade de comparar a qualidade do ar em espaços fechados e no exterior. O utilizador receberá conselhos de saúde de acordo com os dados recolhidos.
AIR by Plume Labs [10]
Aplicação, desenvolvida pela Plume Labs, onde se pode visualizar os níveis de poluição em tempo real em qualquer localização através de dados provenientes de satélites. Para além da monitorização em tempo real, através de algoritmos de machine-learning, fornece ainda a previsão da qualidade do ar para o dia seguinte e informações do foro meteorológico de ambos os dias. Através desta aplicação, os utilizadores podem:
• Aceder a dados da qualidade do ar em tempo real bem como a previsão da mesma nas 24 horas seguintes;
• Visualizar dados recolhidos anteriormente através de uma timeline;
• Visualizar dados acerca de cada poluente (PM10, PM2.5, NO2 e O3) presente na atmosfera bem como a sua concentração;
• Comparar a qualidade do ar entre cidades;
• Ser notificados acerca da poluição para o próprio dia.
A tabela 2.1 resume algumas das funcionalidades observadas nas diferentes aplicações.
QualAr BreezoMeter AirVisual Air Matters AIR
Multiplataforma Sim Sim Sim Sim Sim
Previsão da qualidade do ar
24 horas 5 dias 7 dias 5 dias 24 horas
Consulta de avisos e conselhos de saúde
Sim Sim Sim Sim Sim
Notificações sobre a qualidade do ar
Verificação do índice da qualidade do ar
Sim Sim Sim Sim Sim
Consulta de valores de diversos poluentes
Sim Sim Sim Sim Sim
Previsão
metereológica Sim Não Sim Sim Sim
Outros -Dados sobre os vários tipos de pólen presentes na atmosfera (que provocam reações alérgicas). Dados sobre a exposição do utilizador a ambientes muito poluídos. Possibilidade de conectar a aplicação móvel com um purificador de ar ou um dispositivo de monitorização do ar (equipamentos específicos). Mapa mundial com o índice da qualidade do ar nos diferentes países.
Tabela 2.1: Funcionalidades das aplicações existentes para a monitorização da qualidade do ar.
2.2 Desenvolvimento Web
Esta secção destina-se à introdução e discussão de algumas tecnologias usadas para o desenvolvimento de plataformas web.
2.2.1 Backend
O backend, também conhecido como server-side, consiste em toda a lógica da aplicação que não se encontra exposta ao utilizador. Esta face das aplicações web fornece ainda o acesso à base de dados e integridade dos dados existentes, segurança e escalabilidade.
Atualmente, existem diversas tecnologias que podem ser usadas para o desenvolvimento do backend das aplicações web, entre as quais se encontram:
• Express: framework de Node.js que permite a criação de um conjunto de funcionalidades, definidas no backend, para aplicações web e mobile. O Express caracteriza-se por ser uma layer em cima de um servidor Hypertext Transfer Protocol (HTTP) em Node.js,
fornecendo routing declarativo, ou seja, podendo-se declarar facilmente o que se pretende fazer através de métodos como por exemplo, o app.get() e app.use() e contendo ainda funções de um padrão de middleware básico como funções que têm acesso aos objetos pedidos (req) e aos de resposta (res). Esta framework é usada por empresas tais como Accenture, IBM e Uber [11];
• Django: framework de alto nível baseada em Python que encoraja o design e desen-volvimento limpo e pragmático de plataformas web, e implementa ainda o padrão de arquitetura Model-Template-View (MTV). Para além de ser grátis e open source, per-mite um rápido desenvolvimento das aplicações web, tendo sempre em conta a segurança da aplicação, e proporcionando ainda uma elevada e rápida escabilidade caso seja pretendido [12]. O Django é, por exemplo, usado pelo Instagram;
• Ruby on Rails: framework open source baseada em Ruby e que usa o padrão Model-View-Controller (MVC) para a organização da aplicação em três camadas: Model (componente que lida com a lógica da aplicação), Controller (componente que lida com as ações do utilizador) e a View (interfaces da aplicação). É considerada uma framework ideal para os iniciantes dado que é fácil começar a criação de uma aplicação web, sendo depois possível adicionar novas funcionalidades gradualmente. No entanto, o Ruby on Rails leva algum tempo para fazer o seu deploy num ambiente de produção. Existem várias aplicações que foram desenvolvidas com o uso de Ruby on Rails, tal como o GitHub e o Basecamp [13];
• Spring: framework desenvolvida com Java que permite ter uma aplicação a ser executada facilmente com configurações mínimas através do uso de Spring Boot. O Spring permite o desenvolvimento de vários componentes desde Representational State Transfer (REST) Application Programming Interface (API), WebSocket e streams, tendo sempre em conta a segurança da aplicação. Esta framework tem suporte para Structured Query Language (SQL) e Not Only Structured Query Language (NoSQL) bem como para Tomcat, Jetty e Undertow, contendo ainda funcionalidades importantes para o seu
deploy em ambientes de produção [14].
2.2.2 Frontend
O frontend, também conhecido como client-side, consiste nas interfaces que serão apresen-tadas ao utilizador. Esta face das aplicações web tem como objetivo a criação das views que deverão ser intuitivas, permitindo uma navegação fácil, por parte do utilizador, na plataforma. A stack básica do desenvolvimento do frontend das aplicações web, conta com o uso de HyperText Markup Language (HTML), Cascading Style Sheets (CSS) e JavaScript (JS). Atualmente, e dada a constante evolução da tecnologia, têm surgido novas frameworks que podem ser usadas para o desenvolvimento do frontend das aplicações web. De entre todas, as mais populares, e que foram desenvolvidas com JS, são:
• Angular: framework que permite o desenvolvimento para todas as plataformas (web,
mobile e desktop) a partir do mesmo código. O Angular é considerado ideal para
aplicações single-page. Apesar desta framework ter sido desenvolvida com o uso de JS, posteriormente acabou por adoptar o uso de Typescript. Uma das vantagens do Angular, é a possibilidade de uso do RxJS e dos Observables. Em relação às outras frameworks, o Angular acaba por ficar para trás dada a sua dimensão reduzida quando comparada com as seguintes [15]. Angular é usado, por exemplo, pela Google e Microsoft;
• React: o React não é uma framework mas sim uma biblioteca de JS para o desen-volvimento das User Interface (UI), apesar de ser muitas vezes mencionado com uma
framework. Esta biblioteca baseia-se numa arquitetura de componentes, onde são
desen-volvidas views para cada estado da aplicação, sendo que o React irá fazer o render à UI assim que os dados se alterarem. O React foi desenvolvido pelo Facebook e é usado nesta rede social bem como no Instagram [16];
• Vue: apesar de o Vue ter começado como um projeto individual, é atualmente uma das
frameworks de JS mais usadas. Esta framework é caracterizada por ser progressiva
dada a possibilidade de se poder adaptar facilmente a projetos já existentes. Para além disso, o Vue permite tornar aplicações single-page em aplicações sofisticadas através de várias bibliotecas desenvolvidas para esta framework. Tal como React, a sua arquitetura é também baseada em componentes. O uso de Vue pode ser verificada na plataforma do GitLab, que usa esta framework para o seu frontend [17].
2.2.3 Containers
Um container, representado na figura 2.3, consiste num sistema operativo lightweight que se encontra a ser executado num sistema hospedeiro, e que executa instruções nativas para o processador [18]. É visto como uma ferramenta para usar software em ambientes de produção [19]. Os containers permitem uma poupança no consumo de recursos sem que haja a sobrecarga da virtualização, ao mesmo tempo que oferece ainda isolamento, isto é, separa a execução de um processo do resto do sistema. Em comparação com as Virtual Machine (VM), fornece o mesmo nível de isolamento e segurança, mas encontra-se mais integrado com o sistema operativo hospedeiro [18].
Durante anos, as Virtual Machines (VMs) foram o suporte principal na camada da infraestrutura fornecendo sistemas operativos virtualizados. Ao contrário dos containers, as VMs fazem alocação e gestão de hardware (resumidamente, máquinas que podem ser ligadas e desligadas). Para correr uma VM é necessária a totalidade da imagem do sistema operativo, tal como os binários e bibliotecas necessárias para a aplicação. Isto leva a um problema de espaço em memória e em disco para além de tornar a inicialização mais lenta [19].
Por outro lado, os containers apresentam uma melhoria de performance e tempos de inicia-lização reduzidos [18]. Esta agilidade combinada com a arquitetura baseada em micro-serviços,
onde o software é separado em pequenas unidades funcionais - unidades estas que podem funci-onar, falhar, ser mantidas e reusadas independentemente -, torna os sistemas mais robustos [20].
Figura 2.3: Esquema de um container. Fonte: Red Hat1
Existem várias implementações de containers, seja para Linux, Windows ou Platform-as-a-Service (PaaS) na cloud. Para Linux são exemplos o Docker e os Linux Containers (LXC), para Windows o Sandboxie e para PaaS na cloud pode-se usar Warden (no Cloud Foundry) ou LXC (no OpenShift). Seguidamente serão detalhados alguns destes exemplos para Linux, dado que foi o sistema operativo com que se trabalhou neste projeto [18]:
• LXC: conjunto de um ou mais processos organizados isoladamente do sistema [21]. Este tipo de implementação é suportado em poucos ambientes Linux tais como Ubuntu ou Oracle Linux. A maior vantagem destes containers é ser uma implementação lightweight que é executada a uma rápida velocidade fornecendo assim melhor isolamento da rede e sistema de ficheiros. No entanto, existem algumas limitações, tais como o facto de os
containers usarem um kernel partilhado, ser limitado a ambientes Linux;
• Warden Container: implementação de containers usada no projeto Cloud Foundry, projeto este que permite o host de aplicações [22]. Este tipo de containers permite uma implementação independente do kernel que pode ser ligada a múltiplos sistemas operativos hospedeiros. O uso de namespaces para isolamento do processo e da rede, o uso do conceito de cgroups do Linux para isolamento de recursos, ou cada container poder executar múltiplos processos, são alguns dos atributos chave deste tipo de implementação [18];
• Docker: daemon que fornece a possibilidade de gerir containers Linux como se fossem imagens independentes. O Docker usa o LXC para a implementação dos containers propriamente dita e adiciona a gestão de imagens (através das capacidades do Unix File System (UFS)). Os containers Docker são caracterizados por ter um único processo (com um único ID e um endereço Internet Protocol (IP) privado), isolamento de recursos (uso de cgroups e namespaces), isolamento da rede e do sistema de ficheiros (funcionalidade
proveniente do LXC), ciclo de vida (gerido usando um daemon e a linha de comandos) e um estado (possibilidade de visualizar o estado do container). Como o Docker é baseado nos LXC, muitas limitações dos LXC estão a ser trabalhadas de modo a melhorar a segurança [18];
• Google lmctfy: esta implementação fornece uma Application Programming Interface (API) de configuração de recursos que simplifica a gestão dos containers. Neste tipo de containers, a configuração pode ser feita sem ser preciso compreender o conceito de
cgroups e remove as dificuldades presentes nas API instáveis dos LXC. Neste tipo de
implementação, os containers têm a si atribuído um Process Identification Number (PID)
namespace, existe isolamento dos recursos (uso de cgroups), da rede e do sistema de
ficheiros e os mesmos possuem um ciclo de vida sendo possível monitorizá-los [18]; • OpenVZ: implementação que usa um kernel Linux modificado com um conjunto de
extensões. Estes containers gerem múltiplos servidores físicos e virtuais, usando partições dinâmicas em tempo real. Tal como as outras implementações, o OpenVZ tem também várias características a si atribuídas: cada container tem um PID e Inter-Process Communication (IPC) namespace (este segundo com a sua memória partilhada, semáforos e mensagens), gestão de recursos, isolamento de rede (tem o seu próprio endereço IP e tabelas de routing) e sistema de ficheiros (fornece isolamento para ficheiros da aplicação e bibliotecas do sistema), ciclo de vida (um container pode ser pode ser criado, iniciado, alterado e parado) e estado associado [18].
Todas estas implementações têm as suas vantagens e desvantagens e a escolha da melhor implementação para uma determinada plataforma deve ter em conta o ecossistema onde vão estar inseridos os containers, como se irá lidar com o isolamento dos recursos, quais as ferramentas disponíveis para gerir o ciclo de vida do container, se existe a possibilidade de migrar containers entre hosts e suporte para múltiplos sistemas operativos e kernels [18].
2.3 Desenvolvimento de Aplicações Móveis
Os telemóveis começaram por ser um aparelho inventado para se poder comunicar à distância. Apesar de o telemóvel moderno ser completamente distinto do telefone original, é também um dispositivo de comunicação, apesar de também ser visto como um pequeno computador pessoal por todas as funcionalidades presentes no mesmo. Hoje em dia os telemóveis são vistos como um dispositivo onde é possível fazer quase tudo, desde enviar e receber mensagens de texto e voz, possibilidade de ligação à internet, acesso às mais variadas aplicações, compra e venda de bens sem recorrer fisicamente a dinheiro ou uso de mapas com localização automática [23].
O termo smartphone foi referido a primeira vez pela Ericsson em 1997. A maioria dos
Phone. Atualmente, os sistemas operativos mais usados são [24]:
• Android: plataforma de software e sistema operativo para dispositivos móveis que foi desenvolvida pela Google, em Java e baseada no Linux. É o sistema operativo que regista o maior número de utilizadores atualmente e está presente nos dispositivos móveis produzidos, por exemplo, pela Samsung e Huawei;
• iOS: um dos sistemas operativos produzido pela Apple e baseado no MacOS, partilhando assim uma série de semelhanças com o mesmo. O iOS foi desenvolvido para dispositivos móveis tais como iPhone e iPad;
• Windows Phone: um dos sistemas operativos produzido pela Microsoft para o Windows Phone. Este é o sistema operativo para dispositivos móveis com menos utilizadores dos três mencionados.
Na figura 2.4 está representada a quota do mercado de cada sistema operativo para dispositivos móveis, a nível mundial. A percentagem do uso de utilizadores de Android é de 76.08%, iOS é de 22.01% e Windows é de 0.2% [25].
Figura 2.4: Gráfico estatístico acerca de cada sistema operativo e do seu uso pelos utilizadores de
smartphones(Julho 2018 - Julho 2019). Fonte: StatCounter2
2.3.1 Plataforma Android
O Android é o sistema operativo dominante no mercado dos dispositivos móveis [25], sendo utilizado nos mais diversos dispositivos tais como smartphones, tablets, SmartTV’s,
smartwatches, entre outros. Inicialmente, o Android OS foi desenvolvido para melhorar os
sistemas operativos das câmaras digitais. Hoje, a plataforma Android representa muito mais do que aquilo que era o seu objetivo inicial. Em 2005, a empresa criadora do Android foi adquirida pela Google onde se desenvolveu o sistema operativo para agir como um pequeno
computador pessoal em qualquer dispositivo móvel. O sistema operativo resultante era baseado em Linux e determinou-se que esta plataforma seria oferecida a qualquer fabricante de smartphones, podendo ser livrementes instalada em qualquer dispositivo [26].
Nas aplicações Android existem quatro componentes principais:
• Activity: representa uma classe de uma interface do utilizador. As atividades são normalmente reunidas para formar os componentes da UI da aplicação;
• Service: componente que permite que as tarefas sejam executadas em threads em
background na aplicação sem afectar os componentes da UI;
• Content Provider: permite que a aplicação aceda a dados armazenados por si ou noutras aplicações, fornecendo ainda um meio para partilhar dados com outras aplicações; • Broadcast Receiver: componente que permite que a aplicação envie ou receba mensagens
broadcast do sistema operativo ou de outras aplicações Android, semelhante ao padrão publish-subscribe. É semelhante a este padrão pois as aplicações podem registar se
querem receber determinado broadcast e a aplicação irá receber o broadcast pretendido caso ocorra um evento que o desencadeou.
Para o desenvolvimento de aplicações que possam ser executadas neste sistema operativo, os programadores podem usar Java ou Kotlin através do Android Studio. O Android Studio oferece suporte de alto nível ao Kotlin e possui ainda ferramentas integradas que ajudam a conversão de Java para Kotlin. O Kotlin foi adoptado como a linguagem oficial de programação moderna para o desenvolvimento de aplicações para Android e é caracterizado por [27][28]:
• Ser um projeto de código aberto da licença do Apache 2.0 e gratuito;
• Ser uma linguagem moderna e expressiva: permite que o programador se concentre no essencial, escrevendo menos código boilerplate;
• Execução mais segura de código: esta linguagem conta, por exemplo, com tipos que permitem evitar NullPointerExceptions e ainda outros recursos para ajudar a evitar erros comuns de programação, como, por exemplo, type checks e casts automáticos; • Interoperabilidade: antes do Kotlin, as aplicações para Android eram desenvolvidas
recorrendo a Java. O Kotlin foi então criado de modo a ser completamente interoperável com o Java dando possibilidade ao programador de ter ambas as linguagens no seu projeto;
• Compatibilidade: é totalmente compatível com o Java Development Kit (JDK) 6 garantindo que todas as aplicações desenvolvidas em Kotlin possam ser executadas em dispositivos móveis Android mais antigos sem qualquer problema;
• Performance: uma aplicação desenvolvida em Kotlin é executada tão rapidamente como uma em Java dada a semelhança da estrutura do bytecode;
• Tempo de compilação: Kotlin suporta compilações incrementais que costumam ser tão ou mais rápidas em relação a quando se usa Java;
• Curva de aprendizagem rápida: para programadores que se encontrem bastante familiarizados com Java, a aprendizagem de Kotlin é bastante rápida.
As aplicações Android não são exclusivas a smartphones; os programadores podem desenvolver aplicações para smartphones, Wear OS by Google, Android TV, Android Auto ou Android Things, de tal forma que a Google fornece documentação, tutoriais, referências para API e outros recursos para que o desenvolvimento destas aplicações seja possível [29]. As aplicações Android são criadas como uma combinação de componentes que podem ser invocados e manipulados individualmente: uma aplicação deve ter no mínimo uma Activity, que, por norma, é aquela para onde o utilizador é direccionado após premir o ícone da aplicação no seu dispositivo móvel. Adicionalmente, existem Services e Broadcast Receivers que permitem executar determinadas tarefas em segundo plano.
O Android permite criar diversos layouts para tamanhos de ecrã variados adequando-se depois ao dispositivo em questão que se encontra a ser usado. As aplicações, caso programadas para tal, podem ainda fazer uso dos componentes de hardware do dispositivo tais como a câmara ou o Global Positioning System (GPS), mediante a permissão dada pelo utilizador [30]. Atualmente, é possível a criação de layouts dinâmicos que se adequam posteriormente ao tamanho do ecrã do dispositivo aquando da execução da aplicação. De modo a que as interfaces visuais das aplicações em Android sejam de alguma forma uniformizadas, é fornecido a programadores e designers um conjunto de normas padrão para o desenho e implementação das interfaces, que vai desde as cores dos elementos visuais ao tamanho e formato dos ícones [31].
2.3.2 Plataforma iOS
O iOS é um sistema operativo desenvolvido pela Apple que apenas pode ser encontrado legalmente em dispositivos móveis da própria marca, tais como iPhones, iPads e iPods.
A Apple desenvolveu a plataforma iOS para o lançamento do iPhone original em 2007. O primeiro iPhone não suportava 3G, funções como copy and paste, anexos de e-mails, Multimedia Messaging Service (MMS) e não executava aplicações de terceiros. Apenas em 2009, com o lançamento do iPhone 3G, a App Store foi então introduzida, criando assim suporte para aplicações desenvolvidas por outros programadores que não os da Apple [32]. Desde a primeira versão do iOS em 2007, várias versões foram desenvolvidas sempre com novas funcionalidades e melhorias em relação à versão anterior, sendo a mais recente a 13.2.3 (lançada no dia 18 de Novembro de 2019) [33]. Uma vantagem que o iOS tem em relação ao Android é que enquanto o último é integrado em vários dispositivos de diferentes tipos e marcas, o iOS está apenas presente num número reduzido de dispositivos, todos eles desenhados pela Apple, o que permite um maior suporte a este sistema operativo [34].
As aplicações para iOS podem ser desenvolvidas usando Swift ou Objective-C. Swift é uma linguagem desenvolvida pela Apple e foi apresentada ao público a 9 de Setembro de 2014, já sendo usada pelos programadores desde Junho do mesmo ano [35]. É uma linguagem de programação que permite o desenvolvimento de aplicações tanto para iOS, macOS, watchOS e tvOS [36]. Tal como Objective-C, Swift é uma linguagem imperativa também orientada a objetos, ambos usam o mesmo compilador - o Low Level Virtual Machine (LLVM) - mas incorpora ainda componentes de programação funcional e a sua sintaxe é ainda mais simples, não usando, por exemplo, ponteiros como acontece em Objective-C [35].
Como referido anteriormente, o número de dispositivos móveis que usam iOS, ou seja, os dispositivos produzidos pela Apple, é bastante reduzido quando comparado com o total de dispositivos que usam o sistema operativo Android, sendo esta uma das grandes vantagens tanto para o desenvolvimento de aplicações móveis como para o suporte dado a este sistema operativo. Tal como em Android, e apesar de haver um número bastante reduzido de dispositivos móveis, é possível a criação de layouts dinâmicos recorrendo ao Auto Layout. O
Auto Layout permite a criação de interfaces que, aquando da execução de uma aplicação, se
adequem ao tamanho e resolução do ecrã [37].
2.3.3 Soluções Cross-Platform
Face à abordagem do desenvolvimento de aplicações nativas, em que um programador desenvolve uma aplicação apenas para Android, iOS ou Windows Phone, na abordagem
cross-platform, o programador apenas precisa de desenvolver código uma vez e terá uma
aplicação que será executada em vários sistemas operativos. Com a necessidade de otimizar o processo do desenvolvimento de aplicações móveis, a ideia de desenvolver apenas uma aplicação que é executada em mais do que um sistema operativo tornou-se um objetivo a cumprir [38]. Podem, então, considerar-se três tipos de soluções para o desenvolvimento de aplicações móveis, que serão de seguida abordadas.
Abordagens Nativas
O desenvolvimento de uma aplicação nativa é baseada apenas num sistema operativo. Neste caso, a aplicação é desenvolvida com a linguagem de programação própria para aplicações do sistema operativo pretendido, isto é, caso a aplicação seja desenvolvida para Android, seria usado Java ou Koltin, enquanto que para iOS, seria usado Swift ou Objective-C. Estas aplicações podem depois ser encontradas na Play Store ou App Store, onde é possível fazer o download das mesmas. No caso das abordagens nativas, as aplicações podem sempre tirar proveito das funcionalidades cedidas pelo hardware do dispositivo móvel [38].
Abordagens Web (Web Apps)
Este tipo de aplicações funcionam como websites, ou seja, podem ser acedidas no disposi-tivo móvel através do browser. Em termos de linguagem de programação, as web apps são desenvolvidas com linguagens destinadas a desenvolvimento web tal como HyperText Markup Language (HTML), Cascading Style Sheets (CSS) e JavaScript (JS) e depois são adaptadas para se adequarem ao tamanho do ecrã do dispositivo móvel, sendo este tipo de apps os chamados websites responsivos. A maior desvantagem desta abordagem é que não se consegue ter acesso às funcionalidades do hardware do dispositivo móvel tais como GPS e câmara. Para além disso, as aplicações deste tipo requerem sempre uma ligação à internet para o acesso às mesmas [38]. O mais recente desenvolvimento nas web apps são as chamadas Progressive Web Applications (PWA), que apesar de serem também criadas com tecnologias web, este tipo de aplicações usa service workers, que permitem que a aplicação seja adicionada ao
home screendo dispositivo móvel do utilizador, não instalando assim a aplicação como
aplica-ção nativa, mas permitindo ainda que a aplicaaplica-ção seja executada sem ligaaplica-ção à internet [39][40].
Abordagens Híbridas
Nas abordagens híbridas, os programadores apenas necessitam de desenvolver a aplicação uma vez (através de uma linguagem ou framework específica), de tal modo a que a aplicação fique disponível para várias plataformas. Este tipo de aplicações pode ser encontrado, por exemplo, na Play Store e na App Store, onde é possível fazer-se o download da aplicação pretendida. Nos dias de hoje, já existem várias frameworks que permitem o desenvolvimento deste tipo de aplicações. Podem ainda ser adotadas diferentes abordagens para o desenvolvi-mento das aplicações híbridas - Runtime, Source Code Translator, Web-to-native wrapper, entre outras - sendo que é comum ouvir-se falar de tecnologias web, PhoneGap, frameworks de JS para o desenvolvimento das aplicações híbridas, entre outras [38]. Mais recentemente, tecnologias como o React Native, Flutter e Ionic são as mais populares para este tipo de desenvolvimento [41].
2.3.4 Padrões de Arquitetura em Aplicações Móveis
Uma aplicação móvel é geralmente estruturada como uma aplicação com múltiplas camadas, consistindo essencialmente nas camadas representativas da interface do utilizador, a aplicação propriamente dita e os dados da aplicação [42].
No início, o modelo mais usado, tanto em Android como iOS, era o MVC. Em muitos tutoriais em plataformas educativas, este era o padrão de arquitetura promovido para uso nas aplicações móveis. Ao longo dos tempos foram surgindo novos padrões tais como o Model-View-Presenter (MVP) e o Model-View-ViewModel (MVVM), que serão abordados nas próximas subsecções. O MVP surgiu como uma maneira de resolver alguns dos problemas existentes no Controller do MVC. Mais tarde, foi introduzido o MVVM que introduziu o
ViewModel como uma maneira de representação da View e do seu estado.
Model-View-Controller (MVC)
O MVC é o padrão de arquitetura mais usado no desenvolvimento de aplicações móveis, seja em Android como em iOS. Este modelo separa a aplicação em três partes [43]:
• Model: componente responsável pelo processamento dos dados como conexão e queries à base de dados. Este componente envia os dados para a View sem ter em consideração a apresentação e/ou transformação dos dados;
• Controller: componente usado para estabelecer a comunicação entre o Model e a View. Tendo como base o input do utilizador a partir da View, este componente pode efetuar mudanças no Model, fazer processamento de dados e voltar a passar os dados para visualização dos mesmos na View;
• View: componente que corresponde à representação gráfica da aplicação, isto é, toda a parte visual da mesma. A apresentação e formatação dos dados é da responsabilidade da View, ou seja, a visualização dos dados é função deste componente sendo que não tem em conta nenhuma das operações ligadas à base de dados.
A figura 2.5 representa este padrão de arquitetura.
Model (Business logic and
Data) Controller (Application behavior) View (User interface) Displays
Model changed Update model Update UI User actions
Figura 2.5: Model-View-Controller [44]
Um dos problemas do padrão MVC, como por exemplo nas aplicações Android, é o de a componente View estar distribuída pelos ficheiros Extensible Markup Language (XML) correspondentes ao layout da interface bem como pelas Activities e os Fragments. Isto acaba por gerar um problema pois o Controller corresponde também a estes dois componentes referidos, o que leva à combinação da lógica destes dois componentes. O Model pode ainda estar presente nesses mesmos ficheiros quando se faz o acesso aos dados. Para além disso, a manutenção de código, em grande quantidade, bem como a execução de testes acabam por ser tarefas complicadas. O MVC é então considerado uma possibilidade para aplicações pequenas que são fáceis de gerir e com uma navegação simples [43].
Model-View-Presenter (MVP)
No MVP, o Model tem a mesma função do que no MVC, sendo que pode ser criado um ou mais models com diferentes tarefas e referentes a diferentes tipos de dados. Neste tipo de arquitetura, nunca se deve ter uma referência do Presenter ou da View no Model. A View tem conhecimento do Presenter mas o contrário não acontece. Neste padrão de arquitetura, o Controller do MVC é alterado para o chamado Presenter. O Presenter tem a função de comunicar com o Model e atualizar a View, sendo chamado de "entidade mediadora"entre estes dois componentes [43].
Neste padrão, o Presenter - que é o único que consegue ler e fazer o retorno de dados do
Model - comunica diretamente com a View correspondente, portanto é mais fácil fornecer
informação de um determinado Model ao utilizador. No MVP, é possível usar o Presenter para múltiplas views e não existe lógica implementada na View [43].
O padrão MVP foi incialmente introduzido em 1990 com o objetivo de resolver o problema de o Model, a View e o Controller estarem todos ligados entre eles no MVC. O MVP resolve um dos problemas do MVC o problema de múltiplas views poderem atualizar o Controller -dado que remove as dependências e introduz então o Presenter que age como uma interface para a View [43]. Desta maneira, e em relação ao MVC, o MVP elimina os problemas de testabilidade, modularidade e flexibilidade.
O MVP é introduzido então de modo a ser possível a realização de testes e para haver separação da View e do Model como é possível verificar-se na figura 2.6 [43].
Model (Business logic and
Data)
Presenter (Mediator)
View (User interface)
Model changed Update model Update UI User actions
Figura 2.6: Model-View-Presenter [44]
Model-View-ViewModel (MVVM)
Numa perspectiva geral, o padrão MVVM apresenta três camadas [42]:
• View: camada de apresentação que diz respeito à UI. Esta camada contém todos os elementos presentes na UI, ou seja, forms, views e tudo o resto que diga respeito à
interação com o utilizador. A View foca-se em ter também elementos de input, cujos dados inseridos nestes elementos serão enviados posteriormente para camadas inferiores para processamento dos mesmos;
• ViewModel: camada da aplicação propriamente dita. O ViewModel contém a lógica e funcionalidades que a aplicação irá executar, ou seja, foca-se em como as tarefas irão ser executadas;
• Model: camada correspondente aos dados. O Model, tal como no MVC e no MVP, é responsável por expôr os dados armazenados na base de dados.
Neste padrão, a View contém a View base (aquela que é apresentada ao utilizador após abrir a aplicação) e todas as outras que poderão ser apresentadas ao utilizador durante a execução da aplicação. O ViewModel, além de outros elementos, contém um comando de
delegate para aceder aos diferentes models da aplicação. O Model contém os modelos da
aplicação e a base de dados, onde é feita ainda a validação dos dados [42].
O ViewModel é uma classe responsável por preparar e gerir os dados para uma View. Gere também a comunicação deste tipo de componente com a restante aplicação. A View deve conseguir observar as mudanças no ViewModel que expõe os dados. Na figura 2.7 é possível verificar-se a comunicação entre a View, o ViewModel e o Model [45].
Model
(Business logic and Data)
ViewModel
(Presentation logic)
View
(User interface)
Send notifications Send notifications
Updates the model Data bindings and commands
Figura 2.7: Model-View-ViewModel [44]
A complexidade da aplicação é reduzida e a aplicação torna-se mais responsiva do ponto de vista do utilizador quando usado o padrão MVVM. A arquitetura por camadas deste padrão aumenta a modularidade da aplicação, o que facilitará posteriormente na manutenção e atualização do software [42].
CAPÍTULO
3
Solução Anterior
O trabalho desenvolvido tem como base uma dissertação desenvolvida em 2016 [46] por um aluno do Mestrado Integrado em Engenharia de Computadores e Telemática - Ricardo Martins -, e também em colaboração com o IDAD. Este projeto tem como objetivo a monitorização da qualidade do ar fornecendo suporte na parte de visualização dos dados acerca da mesma, seja para clientes privados ou para a população no geral.
3.1 Solução Existente
Este projeto engloba várias vertentes referentes à qualidade do ar como a monitorização e previsão da mesma através de diversos equipamentos instalados em pontos remotos do meio urbano ou ainda através de sensores instalados em laboratórios móveis, como é o caso do IDAD. Os dados podem ser visualizados através de uma plataforma web ou de aplicações móveis. No que diz respeito à solução mobile, este projeto continha já uma aplicação Android cujo público alvo são os clientes privados a quem o IDAD fornece dados recolhidos correspondentes à qualidade do ar em determinado local. A plataforma web é também disponibilizada a esses mesmos clientes para que possam ter estas duas hipóteses de visualização de dados.
Na figura 3.1 é possível visualizar a arquitetura global do projeto. Do lado esquerdo, é possível observar-se o laboratório móvel do IDAD onde os dados são inicialmente recolhidos. Para além dos equipamentos que contêm sensores e dizem respeito à medição de diferentes poluentes individualmente, este contém ainda um computador instalado com o software Atmis, onde se dá início à recolha e agregação dos dados dos diferentes equipamentos. No computador instalado na carrinha existe ainda um worker - desenvolvido com o uso de Celery - configurado através de código Python. Este worker envia os dados para a plataforma web de hora a hora pois é esta a periodicidade de recolha dos dados por parte do laboratório móvel. Os dados são enviados por um broker RabbitMQ que depois os encaminha para a plataforma
web.
Figura 3.1: Arquitetura da solução anterior.
Do lado direito da imagem, pode observar-se o bloco correspondente ao backend da plataforma web que, para além da base de dados (desenvolvida com PostgreSQL), contém o mesmo worker que envia os dados do laboratório móvel. No entanto, este recebe os dados da carrinha pelo broker. Na plataforma web existe ainda uma REST API para enviar os dados do servidor para a aplicação móvel. Na parte inferior da imagem, estão os blocos correspondentes ao frontend da plataforma web, correspondente a uma dashboard que é atualizada em tempo real com dados enviados do laboratório móvel, e à aplicação móvel que contém os mesmos dados apresentados na plataforma web.
3.2 Fontes de Informação
Na solução previamente desenvolvida, o sistema recolhia os dados anteriormente proveni-entes dos sensores (figura 3.2) incluídos no laboratório móvel.
Os equipamentos presentes no laboratório móvel permitem recolher dados referentes
aos poluentes PM10, PM2.5, O3, NO2, SO2, Monóxido de Carbono (CO), Monóxido de
Azoto (NO), Óxidos de Azoto (NOx), entre outros. As concentrações da maioria dos poluentes são medidas em µm3 mas existem outros que são em partes por milhão (ppm), mBar (milibar) e w/m2. Cada poluente tem a si associado o seu nome, unidade de medição, valor e estado. Estes valores relativos aos poluentes permitem tirar conclusões acerca da qualidade do ar nas
diferentes localidades.
Figura 3.2: Sensores instalados no LabQAr.
Para além dos poluentes, os equipamentos na carrinha podem ainda medir dados tais como temperatura, humidade, velocidade e direção do vento.
3.3 Limitações e Oportunidades
Como parte integrante do trabalho desta dissertação, foi feita uma análise às plataformas desenvolvidas anteriormente.
Relativamente à plataforma web, o servidor encontrava-se disponibilizado através do Red Hat’s Openshift Cloud que fornecia um sistema hospedeiro onde o servidor podia ser integrado e funcionar sem problemas. Posteriormente ao desenvolvimento da dissertação original, o OpenShift sofreu algumas atualizações a nível de configurações e a plataforma deixou de ser disponibilizada para os seus utilizadores. Face a este problema, era necessário encontrar um serviço que fornecesse acesso à plataforma sempre que necessário e onde não existisse o problema de possíveis novas configurações ou atualizações que impeçam o funcionamento normal da plataforma.
O broker RabbitMQ era usado através do serviço CloudAMQP que fornecia uma queue de mensagens por onde os dados passavam desde o laboratório móvel até à plataforma web. O facto desta operação ocorrer através de um serviço externo na cloud tem sempre as suas desvantagens. Mais uma vez, caso hajam novas configurações ou atualizações, pode levar à indisponibilidade do serviço.
Recursos necessários, tais como o PostgreSQL e o worker desenvolvido com Celery encontravam-se diretamente instalados na plataforma hospedeira, que anteriormente era o Red Hat’s Openshitf Cloud como já foi referido. Uma das funcionalidades de que este sistema poderia beneficiar era do uso de containers. Isto permitiria uma redução do tempo de inicialização e deployment de uma aplicação ou infraestrutura. Como abordado na secção 2.2.3, existem várias vantagens na utilização dos containers, aspeto que se encontrava em falta na solução desenvolvida para este projeto.
Relativamente à aplicação móvel, a mesma encontrava-se apenas desenvolvida para o sistema operativo Android. Apesar deste sistema operativo ser o mais usado mundialmente, existirão sempre utilizadores com dispositivos com outros sistemas operativos. Desta maneira, surgiu a oportunidade de desenvolver a aplicação de modo a poder ser executada em diferentes dispositivos móveis com diferentes sistemas operativos.
