Neste capítulo é apresentada uma proposta de um guia móvel de biodiversidade para trilhos pedestres que possibilite ao utilizador o georreferenciamento de espécies da biodiversidade encontrada nos trilhos. Esta aplicação, do ponto de vista do utilizador, deverá passar pela criação de um sistema que, com recurso à Internet e ao sistema GPS permita, a qualquer utilizador com um dispositivo móvel com o sistema operativo Android, utilizar a aplicação, em qualquer local, para georreferenciar e fotografar as espécies existentes nesses locais, assim como visualizar as espécies que aí podem ser encontradas.
Neste capítulo, numa primeira fase, é descrita a arquitetura da aplicação juntamente com a lista de requisitos, funcionais e não-funcionais. Numa segunda fase, são apresentados o modelo de dados da aplicação e a especificação da aplicação móvel e do backoffice.
1.
Arquitetura da Aplicação
1.
Apresentação Geral
Uma vez que existe a necessidade de ter vários clientes/utilizadores a acederem a uma base-de-dados comum optou-se por uma arquitetura cliente/servidor, em que a base de dados será armazenada num servidor. Para a arquitetura do protótipo desenvolvido, são disponibilizados dois serviços interligados entre si, um destinado ao utilizador comum, que interage através do dispositivo móvel, e outro para o utilizador de administração, responsável pela interação com um backoffice, presente no servidor. Com o objetivo de manter a informação armazenada em rede e ao mesmo tempo facilitar a troca de dados entre administração e a aplicação móvel, é importante que este projeto siga uma arquitetura que assim o permita.
Na arquitetura proposta (Figura 11) existe uma aplicação, instalada no dispositivo móvel de cada utilizador, com a qual o utilizador interage e efetua pedidos. Estes pedidos são enviados para o servidor.
Como é possível verificar, existe um utilizador que executa a aplicação móvel no dispositivo móvel. Este utilizador, está abilitado a efetuar marcações georreferenciadas e captação de imagens através do dispositivo, juntamente com todas as capacidades que a aplicação móvel disponibiliza, fazendo dele o navegador da aplicação móvel. Existe também, inserido no servidor, uma aplicação web relativa à gestão da biodiversidade disponível ao utilizador móvel. Esta aplicação web, destinada à administração, garante acesso à página inicial através de toda a web, no entanto só é permitido o acesso total após introdução das credenciais administrativas.
Para apresentar a informação, a aplicação do lado cliente efetua pedidos ao servidor através da internet. Em resposta, o servidor envia os dados atualizados, os quais são recebidos pelo cliente móvel.
2.
Requisitos da Aplicação
Com o objetivo de tornar o funcionamento desta aplicação possível, deverão ser tidos em conta alguns requisitos. Esses requisitos deverão garantir o funcionamento básico da aplicação, assim como a interação pretendida com o utilizador.
Nesta secção serão apresentados os requisitos funcionais e não-funcionais, quer para o cliente móvel, quer para o servidor. Os requisitos funcionais descrevem as funcionalidades e serviços do sistema, enquanto os não-funcionais definem propriedades e restrições do sistema. Nos pontos seguintes, são elencados esses requisitos.
1.
Requisitos Funcionais – Cliente Móvel
Requisitos Funcionais F1 F2 F3 F4 F5 F6 F7 F8 F9 F10
O utilizador deverá ser capaz de visualizar todos os elementos georreferenciados por si e por outros utilizadores.
O utilizador deverá ser capaz de selecionar todos os elementos da biodiversidade. O utilizador deverá ser capaz de visualizar a sua localização atual.
O utilizador deverá ser capaz de visualizar toda a lista de biodiversidade.
O utilizador deverá ser capaz de filtrar através de texto a informação na lista de biodiversidade.
O utilizador deverá ser capaz de selecionar qualquer elemento na lista da biodiversidade.
O utilizador deve ser capaz de visualizar a informação específica de cada elemento. Cada elemento deverá ter informação científica, juntamente com uma imagem da espécie.
O utilizador deve ter a possibilidade de capturar imagens.
O utilizador deve ser capaz de visualizar as próprias marcações da biodiversidade.
2.
Requisitos Não-funcionais – Cliente Móvel
Requisitos Não-funcionais NF1 NF2 NF3 NF4 NF5 NF6 NF7O cliente deve ser uma aplicação móvel.
A aplicação deve atualizar a informação criada no backoffice. O utilizador deve estar autenticado para aceder ao sistema.
O cliente deve ter a navegação padronizada consoante as regras padrão do sistema operativo utilizador.
O cliente deve ter o mínimo de recursos alojados no dispositivo móvel. O dispositivo deve ter capacidade de acesso à rede.
O dispositivo deve ter capacidade de acesso ao sistema GPS.
Tabela 4: Requisitos Não-funcionais do Cliente Móvel
3.
Requisitos Funcionais – Servidor
Requisitos Funcionais
F1 O utilizador deverá efetuar operações CRUD, relativamente à biodiversidade.
4.
Requisitos Não-funcionais – Servidor
Requisitos Não-funcionais NF1 NF2 NF3 NF4A gestão da biodiversidade deve ser feita através de um backoffice. O servidor não deve adicionar marcações de biodiversidade.
O servidor não deve adicionar fotografias relativas aos georreferenciamentos. Deverá existir apenas um utilizador de acesso ao backoffice.
Tabela 6: Requisitos Não-funcionais do Servidor - Backoffice
3.
Modelo de Dados
Nesta proposta, existe uma base de dados relacional que se encontra no servidor, e na qual todos os dados são armazenados. O desenho da base de dados iniciou com a definição do modelo de dados, representado na Figura 12, através de um DER (Diagrama de Entidade- Relacionamento) e respetivos campos, na Figura 13.
Um DER, é uma representação abstrata da estrutura que a base de dados da aplicação
tem (Rodrigues, 2015). Cada tabela da base de dados corresponde a uma entidade, representada por um retângulo, enquanto os relacionamentos entre elas são representados pelos losangos. Podemos assim afirmar, que esta base de dados contém 5 tabelas, em que estas se relacionam igualmente entre si de 5 formas.
É possível exemplificar através da relação entre a entidade utilizador e biodiversidade. Nessa relação, um (1) utilizador (entidade), pode georreferenciar (relação) n (mais que um) elementos de biodiversidade. Por seu lado, a cada elemento de biodiversidade corresponde uma ficha técnica. A ficha técnica contém dados científicos referentes a cada elemento de diversidade biológica, como é o caso do Reino, Ordem, e Classe, dados esses que são comuns na biodiversidade, como é o exemplo do Reino, em que existe o Reino Animalia (animais), o
Plantae (plantas) e o Fungi (fungos). Nesta relação, o elemento de biodiversidade adicionado,
pode ter apenas uma ficha técnica correspondente a si, enquanto há a possibilidade de haver mais que um elemento da biodiversidade avistado com os mesmos valores para a mesma ficha técnica (n). Exemplo disso poderá ser um caso de marcação de uma planta que se encontre em
determinada área, esta mesma pode ser avistada e georreferenciada num outro local. Por sua vez, a cada ficha técnica está associada uma imagem pré-definida. Estas imagens são atribuídas usando a aplicação de backoffice, pelo administrador Cada ficha técnica tem uma imagem representativa do elemento da biodiversidade com o intuito de ajudar o utilizador a efetuar um reconhecimento mais fácil e rigoroso. Dada a possibilidade do utilizador poder adicionar fotografias, tiradas por si, às já disponibilizadas pelo serviço, existe uma outra tabela na qual se encontram as fotografias adicionadas pelo utilizador. Aqui há a possibilidade do utilizador (1), adicionar uma fotografia associada ao elemento de biodiversidade georreferenciada. No entanto, ao longo do percurso, o utilizador pode adicionar várias fotografias, uma para cada georreferenciamento.
Figura 12: Diagrama de Entidade Relacionamento Para a Aplicação Proposta
4.
Especificação Funcional
Nesta secção, para cada uma das aplicações, a que estará instalada no dispositivo móvel e a aplicação de backoffice, é especificado o seu funcionamento, sendo a descrição complementada com um fluxograma para cada uma das aplicações.
1.
Cliente
Na Figura 14 está representado o funcionamento do lado do cliente, ou seja, da aplicação instalada no dispositivo móvel. Quando a aplicação inicia é efetuada uma primeira verificação relativamente à existência ou não de utilizador registado. Caso o utilizador não se encontre registado, deve inserir os dados de registo. Estes dados são posteriormente processados e em caso de sucesso o utilizador é redirecionado para a página inicial, onde pode efetuar a autenticação. Neste processo, o sistema verifica se os dados são inseridos corretamente. Caso não sejam é pedida reintrodução dos mesmos de modo correto. Caso contrário, significa que o utilizador efetuou a autenticação corretamente, sendo redirecionado para o mapa inicial, identificando a sua localização atual, sendo, também, lhe dada a possibilidade de adicionar, ou não, um novo elemento. Se o utilizador pretender adicionar um novo elemento avistado, deverá, segundo a lista de biodiversidade disponibilizada, filtrar a informação, ou não, até chegar ao nome do elemento presente na lista. Se o utilizador não pretender adicionar um novo elemento, poderá navegar livremente pelo mapa que apresenta todos os elementos já adicionados, também denominado mapa inicial. No entanto, se o utilizador pretender adicionar novo elemento, terá a possibilidade de tirar uma fotografia ao mesmo. Após finalizado todo este processo, o reencaminhamento para o mapa, indicado na Figura 14 é automático, e o utilizador está agora habilitado, novamente, a adicionar outro elemento.
2.
Servidor – Backoffice
Paralelamente ao funcionamento do lado do cliente, anteriormente explicado, existe do lado do servidor, uma aplicação de backoffice, representado na Figura 15, que faz a gestão das fichas técnicas de cada elemento de biodiversidade. Assim sendo, esta é uma área destinada apenas à administração do sistema. Numa fase inicial é pedido a introdução dos dados do administrador, utilizador único e inalterável por segurança. Como no fluxo da aplicação para o cliente, quando são introduzidos os dados do administrador é feita a verificação dos dados que foram introduzidos. Caso estejam corretos, o utilizador é autenticado com sucesso, caso contrário deverá reintroduzir os dados corretamente. Após a autenticação com sucesso, é apresentada uma listagem das fichas técnicas guardadas na base de dados, sendo possível a sua edição através das operações usuais de CRUD (Create, Read, Update e Delete). Para cada elemento presente na lista, existem as opções de editar e eliminar. Após a execução da opção pretendida, o administrador é retornado novamente para a lista. Caso o utilizador pretenda adicionar um novo elemento, este preenche o formulário com a respetiva informação e, após confirmação, regressa igualmente à lista, desta vez já contendo o elemento adicionado.