INSTITUTO SUPERIOR DE ENGENHARIA DE LISBOA

Área Departamental de Engenharia Eletrónica e Telecomunicações e de Computadores

Licenciatura em Engenharia Informática e de Computadores

Projeto e Seminário

Gestão de Entrega de Encomendas em Cacifos

Relatório de Projeto

João André Remédios nº46539 A46539@alunos.isel.pt Tel: 939008101

Tiago Neves nº46067 A46067@alunos.isel.pt Tel: 916302958

Orientadores: Professor Luís Osório lo@isel.ipl.pt

Professor Mário Pinheiro mario.pinheiro@isel.pt

Junho, 2023
 Índice
1 Introdução ........................................................................................................................ 4
1.1 Apresentação do Problema e Estado da Arte .............................................................. 6
1.2 Enquadramento do Sistema Informático LockerHive .................................................. 7
1.3 Glossário ................................................................................................................... 3
2 Conhecimentos de Base .................................................................................................... 8
2.1 Modelo de Dados ...................................................................................................... 9
2.1.1 Modelo Conceptual .......................................................................................... 10
2.1.2 Modelo lógico .................................................................................................. 12
2.1.3 Modelo físico ................................................................................................... 13
2.2 Modelação Conceptual de Sistemas Informáticos..................................................... 13
2.2.1 Diagrama de requisitos funcionais .................................................................... 14
2.2.2 Diagrama de casos de uso ................................................................................ 14
2.2.3 Diagrama de atividades .................................................................................... 15
2.2.4 Diagrama de blocos.......................................................................................... 16
2.2.5 Diagrama Interno de Blocos ............................................................................. 16
2.3 Interface para interação entre elementos de sistema ............................................... 17
2.3.1 JSON Siren ............................................................ Error! Bookmark not defined.
2.4 Tecnologias .............................................................................................................. 19
2.4.1 PostgreSQL............................................................ Error! Bookmark not defined.
2.4.2 Spring Boot ........................................................... Error! Bookmark not defined.
2.4.3 Jetpack Compose .................................................. Error! Bookmark not defined.
2.4.4 Google Maps API ................................................... Error! Bookmark not defined.
2.4.5 React .................................................................... Error! Bookmark not defined.
3 Análise do Problema e Conceção do Sistema Informático LockerHive .............................. 23
3.1 Requisitos Funcionais............................................................................................... 23
3.2 Requisitos Não Funcionais ....................................................................................... 24
3.3 Diagrama de requisitos ............................................................................................ 25
3.4 Casos de uso ............................................................................................................ 28
3.5 Arquitetura do Sistema Informático LockerHive ....................................................... 29
3.6 Modelo de dados ..................................................................................................... 30
3.6.1 Modelo Entidade-Associação LockerHive.......................................................... 31
3.7 Modelo Relacional ................................................................................................... 31
3.7.1 Passagem de modelo EA para modelo relacional ... Error! Bookmark not defined.
3.8 Implementação dos Casos de uso do Sistema Informático LockerHive ...................... 33

1
 3.9 Medidas de Segurança e Proteção de Dados no Sistema LockerHive ........................ 38
4 Aspetos do Desenvolvimento do Sistema Informático LockerHive .................................... 39
4.1 Base de dados.......................................................................................................... 40
4.2 Segurança e proteção de dados .................................... Error! Bookmark not defined.
4.3 Servidor ................................................................................................................... 40
4.4 Aplicação móvel....................................................................................................... 46
4.4.1 Aspetos gerais da aplicação móvel ................................................................... 46
4.4.2 Detalhes de implementação ............................................................................. 49
4.5 Loja online com parceria .......................................................................................... 50
5 Conclusões, Experiência e Trabalho Futuro ...................................................................... 52
Referências ............................................................................................................................. 55

2
Glossário
Este sistema informático utiliza analogias com colmeias de abelhas, além de outros
termos que possam não ser muito claros ao leitor. Torna-se importante, portanto, a
apresentação de um glossário que define os principais termos e conceitos utilizados,
procurando, desta forma, facilitar a sua compreensão e esclarecer eventuais dúvidas que
possam ocorrer.
Assim, no contexto do sistema informático LockerHive deve ter-se em consideração o
seguinte:

 Célula (Cell): compartimento/cacifo do sistema informático LockerHive, onde se

depositam um ou mais pacotes.
 Pacote (Package): embalagem entregue no centro de distribuição do sistema
informático LockerHive que tem como destino final a colmeia indicada na
embalagem. Esta embalagem pode ser uma parte ou o todo de uma compra que
o cliente adquiriu numa loja online.
 Pacote ou agrupamento de pacotes (Bundle): um ou mais pacotes pertencentes
a um cliente, tendo a mesma colmeia e célula como destino. O agrupamento só
é possível caso haja espaço na célula.
 Colmeia (Hive): conjunto de células pertencente ao sistema informático
LockerHive.

3
1 Introdução
O comércio eletrónico revolucionou a forma como adquirimos todo o tipo de bens.
Desde produtos de mercearia, até às mais recentes tecnologias, a crescente
conectividade global e consequente divulgação desta forma de serviço torna-o uma
realidade cada vez mais presente, tendo a seu favor a comodidade e praticidade que
oferece ao consumidor.

Na última década tem sido observado em Portugal, tal como no resto do mundo, um
crescimento significativo de compras online por parte das pessoas. Segundo um artigo
do Eurostat [2], que apresenta os resultados do “e-commerce” em 2022, desde 2010,
na união europeia, houve um crescimento de cerca de 20% de utilizadores da internet
que efetuaram compras ou serviços online para uso próprio (figura 1)

Figura 1: Previsão de crescimento de utilizadores da internet que compram online, em

Portugal e União Europeia (pré e pós COVID-19)

Este crescimento, observável ao longo dos anos, pode ser justificado por fatores como
o crescimento substancial de utilizadores da internet (figura 2), o aumento de confiança
dos utilizadores nas transações online, a ampla variedade de produtos disponíveis, os
avanços na tecnologia móvel e, mais recentemente, à pandemia COVID 19.

4
 Figura 2: Previsão de crescimento de utilizadores da internet em Portugal e União
Europeia (pré e pós COVID-19)

A pandemia COVID19 que afligiu fortemente o planeta nos últimos anos, foi responsável
por grandes restrições de deslocamento das pessoas, tendo também levado a um
aumento da insegurança e ao fecho de várias lojas físicas. Esta situação proporcionou, a
nível global, um crescimento maior do que o previsível neste tipo de compra online. Em
Portugal, de acordo com o artigo do “O jornal económico”, baseado num estudo da “In-
Store Meida”, em 2022, que analisou os hábitos dos portugueses que realizam compras
online, ocorreram aumentos de cerca de 30%, em algumas categorias, durante o
período do confinamento.

Após o final do confinamento e da pandemia, esperava-se que as compras online

começassem a cair. No entanto, embora tenham desacelerado o ritmo, verificou-se que
continuam em crescimento e que as pessoas se acostumaram a realizar este tipo de
compra. Com base em estudos recentes, como o “E-Commerce & Last Mile 2023”
divulgado no jornal “Observador” [7], prevê-se um aumento do crescimento do valor de
receitas das compras online em Portugal.

Diante deste cenário, muitas empresas têm vindo a apostar na melhoria da qualidade
dos serviços de entrega das compras online, procurando soluções para as adversidades
associadas a este tipo de serviço. Uma das soluções encontradas consistiu no
aproveitamento do conceito de as compras online serem entregues num cacifo
escolhido por quem faz a compra.

Embora o conceito acima referido seja antigo, não era muito conhecido ou usado. Com
o aumento das compras online, a utilização destes cacifos está a ter um enorme
crescimento. Estes cacifos permitem ao comprador não ter de estar presente no
momento da entrega para recolher a encomenda e evita a necessidade de ter de ir
buscá-la mais tarde a alguma loja ou esperar por uma nova entrega, havendo a
possibilidade de não estar novamente em casa.

5
Contudo, apesar deste mercado estar em crescimento em Portugal, ainda existe um
grande número de pessoas que não experimentou este serviço. Isto deve-se, em certa
parte, a algumas limitações que ainda subsistem na sua utilização. Deste modo, para
aumentar a visibilidade e utilização deste tipo de serviço em Portugal, é preciso
implementar melhorias e torná-lo mais atrativo. Em alguns países é possível observar
soluções muito interessantes que já se encontram implementas. A Polónia, por
exemplo, com o serviço InPost[9], já possui uma vasta rede de cacifos com resultados
bastante positivos.

Com o intuito de resolver algumas limitações e adicionar funcionalidades não existentes

aos serviços atuais portugueses, é apresentado o projeto de um sistema informático ao
qual se deu a designação LockerHive, elaborado no âmbito da disciplina de Projeto e
Seminário 2022/2023 da Licenciatura em Engenharia informática e Computadores
(LEIC).

O relatório deste projeto está organizado em cinco capítulos:

1. Introdução;
2. Conhecimento base;
3. Analise do problema
4. Implementação
5. Conclusão
O restante deste capítulo introdutório comtempla as seguintes subsecções:
1.1- Apresentação do problema;
1.2- Enquadramento do Sistema Informático LockerHive.

1.1 Apresentação do Problema

Com base no que foi relatado anteriormente, analisou-se mais em detalhe o serviço
Locky, existente em Portugal, lançado em 2022 por parte dos CTT. Locky é um serviço
que permite a entrega de encomendas através de uma rede de cacifos,
proporcionando assim flexibilidade na sua recolha.

Este serviço utiliza um identificador único para associar um cliente ao cacifo respetivo,
que fica inserido depois do último nome do cliente na etiqueta da encomenda, para que
quando esta chegar ao centro de distribuição, seja possível identificar a quem pertence
e qual o cacifo em que deverá ficar armazenada.

Atualmente, o serviço Locky oferece dois modelos para os clientes das lojas online e do
próprio serviço:

1. No primeiro modelo, caso as lojas online tenham parceria com este serviço, é
oferecido aos clientes, na plataforma da loja, a opção de selecionarem o cacifo Locky
que pretendem para a entrega da encomenda. Sendo, em seguida, gerada
automaticamente a morada correspondente para a etiqueta da encomenda;

2. No segundo modelo, para o caso das lojas online que não têm parceria com este
serviço, os clientes têm a opção de utilizar o serviço ao introduzir manualmente a
morada do cacifo Locky, que é disponibilizada na aplicação Locky.

6
No entanto, este serviço possui algumas adversidades para o cliente. Uma delas é a falta
de flexibilidade em relação ao número de cacifos que cada cliente pode associar à sua
conta, pois só pode ter no máximo um, não permitindo ao cliente utilizar outro cacifo
para outra encomenda enquanto o cacifo que está associado tenha uma encomenda a
caminho.

1.2 Enquadramento do Sistema Informático LockerHive

A abordagem do sistema informático LockerHive teve como base o serviço Locky dos CTT
e os dois modelos já mencionados na subsecção anterior, utilizando da mesma forma
um identificador único para identificar o cliente e o respetivo cacifo, na etiqueta de cada
encomenda, mas com o desafio de resolver e implementar as seguintes funcionalidades,
não existentes no serviço Locky:
1. Possibilidade de cada cliente poder associar mais que um cacifo;
2. Possibilidade de ser alterado o cacifo de entrega da embalagem enquanto ainda
se encontre no centro de distribuição;
3. Possibilidade de saber o tráfego de cada cacifo;
4. Possibilidade de receber notificações diretamente na aplicação móvel, acerca do
estado da encomenda;
5. Possibilidade de qualquer cidadão utilizar o serviço, mesmo sem ter conta
registada para o efeito;
6. Mapa na aplicação móvel e na loja online com parceria, personalizado com cores
diferentes, consoante seja ou não um cacifo associado ao utilizador registado;
7. Cliente sem conta registada, ter a possibilidade de após compra online feita numa
loja com parceria, usando este serviço, poder se registar no serviço e usufruir das
funcionalidades da aplicação;
8. Possibilidade de adiar a entrega da encomenda para um cacifo, ou aumentar o
tempo limite que esta pode ficar no cacifo, com um custo monetário adicional;
9. Agrupar encomendas do mesmo cliente para o mesmo cacifo, sem custo
adicional.
Nesta primeira fase, apenas se considerou a existência de um centro de distribuição que
vai receber todas as encomendas provenientes, quer de lojas sem parceria LockerHive,
quer de lojas com parceria LockerHive, estando todos os cacifos LockerHive associados
a esse centro de distribuição.
Para acrescentar a funcionalidade de um cidadão, sem conta registada no sistema
informático LockerHive, poder usá-lo numa loja com parceria LockerHive, para a gestão
e entrega da sua encomenda, é-lhe pedido que insira o seu email, nome e contacto na
plataforma da loja, para que depois receba por email o token que irá conter a
informação acerca do estado da encomenda. Após compra realizada, a encomenda será
levada por uma transportadora para o centro de distribuição. Aí será registado
individualmente no sistema informático LockerHive, um ou mais pacotes da mesma,
pois esta pode conter mais do que uma embalagem. Depois, quando o ou os pacotes
forem selecionados, transportados para o cacifo pretendido e colocados na caixa
atribuída pelo sistema informático LockerHive, o cliente poderá recolher a encomenda.
As etapas do serviço de entrega de encomendas LockerHive estão descritas na figura 3.

7
 Figura 3: Contexto de enquadramento do sistema informático LockerHive.

De notar que, caso seja ultrapassado o número de dias permitido para que a encomenda
possa estar depositada no cacifo, esta será recolhida e devolvida ao centro de
distribuição.
O sistema informático LockerHive não considera a gestão do transporte das
encomendas, focando-se na organização e gestão da colocação das encomendas nos
cacifos respetivos.

2 Conhecimentos de Base
Para a realização de um sistema informático é necessário um estudo prévio, com o
auxílio de vários modelos para potencializar as suas funcionalidades, mantendo a
consistência e integridade dos dados, como das tecnologias para as implementar.
Como tal, para o desenvolvimento do sistema informático LockerHive, utilizou-se vários
modelos e ferramentas para tornar este sistema funcional.
Os modelos e ferramentas utilizados encontram-se descritos neste capítulo, de forma a
facilitar a leitura do relatório por pessoas que não estão enquadradas nos conceitos de
modelo e tecnologias que foram utilizados no desenvolvimento do sistema informático
LockerHive.

8
O restante capítulo está organizado por quatro subsecções:

 A primeiro subsecção, a 2.1, refere-se à modelação de dados. Tem como objetivo

abordar os modelos de dados, para organizar, estruturar e armazenar os dados
do sistema em base de dados, com as respetivas associações e restrições. É
essencial para que haja integridade e consistência dos dados nos sistemas.
 A segunda subsecção, a 2.2, refere-se à modelação conceptual de sistemas
informáticos. Tem como objetivo abordar os diagramas realizados no estudo do
sistema informático LockerHive, para facilitar a compreensão dos requisitos
funcionais ou não funcionais do sistema.
 A terceira subsecção, a 2.3, refere-se às interfaces para interação entre
elementos do sistema. Tem como objetivo tornar possível a comunicação entre
elementos do sistema, independentemente da tecnologia de cada elemento,
oferecendo também recursos de segurança que protegem a comunicação entre
os elementos.
 A quarta subsecção, a 2.4, refere-se às tecnologias usadas no desenvolvimento
do sistema informático LockerHive. Tem como objetivo abordar as
funcionalidades de cada tecnologia utilizada no desenvolvimento do sistema
informático LockerHive, e as respetivas vantagens em relação a outras
tecnologias.

2.1 Modelação de Dados

Como já escrito previamente, modelação de dados é essencial em vários sistemas,
podendo mesmo afirmar-se que tem um papel critico em quase todos os sistemas que
usam computadores. Desde sistemas como uma loja pequena, que precisa de guardar
os seus itens para ter um registo do seu inventário, ou em sistemas como instituições
governamentais, que precisam de guardar informações cruciais para gerir o país.
Cada cidadão consegue criar as bases de dados que pretender, sendo implementadas e
mantidas num sistema de gestão de base de dados (SGBD). Os SGBD facilitam o processo
de definição, construção, manipulação e compartilhamento de base de dados entre
vários utilizadores e aplicações.
A forma como os dados são relacionados na base de dados faz toda a diferença de um
sistema funcional para um sistema não funcional.
Portanto, para garantir que os dados são armazenados da melhor maneira, a modelação
de dados realiza-se com três modelos:

 Modelo conceptual, representado pelo modelo ER (entidade-relação), (descrito

na subsecção 2.1.1);
 Modelo lógico (descrito na subsecção 2.1.2);
 Modelo físico (descrito na subsecção 2.1.3).

9
No modelo conceptual realiza-se um esquema para a base de dados com uma descrição
concisa dos requisitos de dados do sistema em causa, que inclui descrições detalhadas
de entidades, relações e restrições. Nesta abordagem não existe preocupações com
detalhes de implementação da base de dados num SGBD.
Já no modelo lógico, e com base no modelo conceptual, é feita a implementação das
entidades, atributos e relações em estruturas de dados especificas de um SGBD,
originando um esquema de base de dados.
Por fim, no modelo físico, é especificado as estruturas internas de armazenamento
físico, a organização de ficheiros, os índices, os caminhos de acesso e otimizações de
desempenho. Este modelo define como os dados são armazenados num SGBD.
Em suma, cada modelo pertence a fases diferentes do processo de modelação de uma
base de dados, cada um possuindo um propósito diferente, garantindo uma correta
implementação, caso seja seguido esta abordagem hierárquica
Após alguma análise e aconselhamento por parte dos orientadores deste projeto, foi
decidido seguir a modelação de dados relacional e as respetivas regras de cada modelo
indicadas por Navathe e Ramez Elmasri, no livro “Fundamentals Of Database Systems”
[2].

2.1.1 Modelo conceptual

A modelação conceptual é uma descrição concisa dos requisitos de dados dos
utilizadores e inclui descrições detalhadas dos tipos de entidades, relações e restrições.
Como estes conceitos não incluem detalhes de implementação, são tipicamente simples
de entender, podendo ser utilizados e interpretados por utilizadores não técnicos, sendo
a maneira mais comum de representar este tipo de modelação, o modelo Entidade-
Relação (ER). Este modelo é usado como ponto de partida para a representação modelar
da estrutura e relações de uma base de dados. Este serve também como base para a
criação de modelos mais detalhados e com especificações relativas à implementação de
uma base dados, como o modelo lógico e modelo físico.
Principais constituintes deste tipo de modelos:

 Entidades: Objetos ou conceitos do mundo real que são representados no

contexto de uma base de dados relacional. Existem dois tipos principais de
entidades, sendo estas entidades fortes ou regulares - existem de forma
independente, ou seja, podem existir mesmo que não estejam relacionadas a
outras entidades, contendo uma chave que as identificam inequivocamente, e
entidades fracas - dependem de uma entidade forte para existir, não tendo chave
própria, requerem uma chave parcial, que vai ser o atributo identificador, que
inclua a chave primária da entidade identificadora. A representação gráfica de
cada entidade encontra-se na figura 2.

Entidade forte ou regular

10
 Entidade fraca

Figura 2: Representação dos principais tipos de entidades no modelo ER

 Atributos: Propriedades descritivas de cada membro de um conjunto de
entidades. Estes podem ser simples - representam informações atômicas e
indivisíveis, compostos - atributos que podem ser divididos em subpartes, cada
uma com significado próprio, multi-valor - atributos que podem ter múltiplos
valores associados a uma única instância da entidade, derivados - atributos que
são derivados de outros atributos existentes na entidade, e chave: identificam
exclusivamente cada instância de uma entidade.

Atributo Simples

Atributo Composto

Atributo Chave

Atributo Multivalor

Atributo Derivado
Figura 4: Representação dos tipos de atributos existentes no modelo ER

 Relações: Constituem as associações entre as entidades, como "trabalha para",

"cria", "possui", etc. Uma relação poderá ser considerada identificadora caso
uma das entidades que a constitui dependa da outra, tendo uma relação “pai” e
“filho”. Às relações estão também associados dois conceitos que as caracterizam:
cardinalidade e participação.
A cardinalidade especifica o número máximo de instâncias desta relação que
cada entidade pode ter, podendo esta ter a razão de 1:1, 1:N, N:1 e M:N, sendo
M e N valores que indicam quantidade ilimitada. A título de exemplo, admitindo
uma relação TRABALHA_PARA, que relaciona um trabalhador de uma
determinada empresa, com o respetivo departamento,
DEPARTAMENTO:TRABALHADOR, esta relação teria cardinalidade 1:N, indicando
que um departamento poderá ter N trabalhadores, mas cada trabalhador
pertenceria apenas a um departamento.

11
 A participação especifica se a existência de uma entidade depende de outra
entidade através da relação entre as duas, indicando, assim o número minimo de
instâncias desta relação que cada entidade deve ter. Esta caracteristica de uma
relação pode ter dois valores, participação total ou parcial. A participação total
poderá ser exemplificada seguindo o exemplo de uma empresa que dita que cada
trabalhador terá de operar em pelo menos um departamento desta empresa,
ditando assim que numa relação TRABALHA_PARA a participação de cada
trabalhador é total. No mesmo exemplo, ao existir a relação GERE a participação
de cada trabalhador é parcial, já que apenas alguns farão parte da gestão de cada
departamento.

Relação

Relação “Identificadora”

Participação total de E2 em R

Cardinalidade 1:N para E1:E2 em R

Figura 5: Representação dos tipos de relações existentes no modelo ER

2.1.2 Modelo lógico

O modelo lógico refere-se à representação estruturada e detalhada de uma base de
dados que surge como seguimento a uma fase de modelação conceptual. Este modelo
surge após um processo de modelação lógica mapeando entidades para tabelas,
atributos para colunas e estabelecendo relações estabelecidas por meio de chaves
primárias e chaves estrangeiras, através de um conjunto de processos e algoritmos. Para
além destas conversões existe também o processo de normalização. Este processo tem
o objetivo de reduzir redundâncias e problemas de dependências que possam existir no
modelo existente, organizando os dados aplicando regras estabelecidas pelas diversas
formas normais existentes. Apesar de existirem em maior quantidade, apenas foram
consideradas as três formas normais mais comuns:
1. Primeira Forma Normal (1NF): a primeira forma normal exige que cada atributo
de uma tabela contenha apenas valores atómicos, ou seja, não deve haver

12
 atributos multivalor ou repetidos. Além disso, cada tabela deve ter uma chave
primária que identifique unicamente instância dessa entidade.
2. Segunda Forma Normal (2NF): a segunda forma normal exige que uma tabela
esteja na 1NF e que todos os atributos não-chave sejam totalmente dependentes
da chave primária. Isso significa que nenhum atributo não-chave deve depender
parcialmente da chave primária.
3. Terceira Forma Normal (3NF): a terceira forma normal exige que uma tabela
esteja na 2NF e que não haja dependências entre os atributos não-chave. Isto é,
nenhum atributo não-chave deve depender de outro atributo não-chave.

2.1.3 Modelo físico

Um modelo físico de dados é a implementação concreta da base de dados num sistema
de gestão de base de dados (SGBD) específico. O modelo físico descreve como os dados
são armazenados fisicamente e como as operações de acesso e manipulação de dados
são realizadas.
O modelo físico é altamente dependente do SGBD utilizado, pois diferentes sistemas
podem ter abordagens diferentes de implementações e otimizações.

2.2 Modelação conceptual de sistemas informáticos

Para abordagem aos modelos conceptuais escolheu-se desenvolver diagramas de dois
tipos de linguagem, UML e SysML.

A linguagem UML é uma linguagem gráfica de modelação de dados que contem um

conjunto de elementos que descreve a abordagem da estrutura do sistema, que permite
representar um sistema de forma que a compreensão pré-implementação seja mais fácil.

Esta linguagem é expressa através de diagramas. Cada diagrama é composto por

elementos que possuem relação entre si. No desenvolvimento do sistema informático
LockerHive usámos os seguintes diagramas na linguagem UML:

 Diagrama de requisitos – descrito na subsecção 2.2.1;

 Diagrama de casos de uso - descrito na subsecção 2.2.2;
 Diagrama de atividades – descrito na subsecção 2.2.3;
Já a linguagem de modelação gráfica SysML (Systems Modeling Language, (SysML,
2022)), é definida como uma extensão da linguagem UML modificada para engenharia
de sistemas, e que introduz um conjunto de diagramas para a modelação conceptual de
sistemas, partilhando alguns diagramas da linguagem UML, sendo a principal diferença
para a linguagem UML o diagrama fundamental, já que não utiliza diagrama de classes,
mas sim de blocos. É mais orientada para blocos funcionais e é principalmente usado
em sistemas físicos, como os automóveis, etc.

13
No desenvolvimento do sistema informático LockerHive usámos os seguintes diagramas
na linguagem SysML:

 Diagrama de blocos – descrito na subsecção 2.2.4;

 Diagrama interno de blocos – descrito na subsecção 2.2.5;

2.2.1 Diagrama de requisitos funcionais

O diagrama de requisitos é um tipo de diagrama que representa e organiza os requisitos
funcionais e não funcionais de um sistema.
É usado para se identificar melhor os requisitos do sistema e as suas relações de
dependência, com o intuito do sistema poder ser desenvolvido de forma mais eficiente
e eficaz.

A contenção é um relacionamento que descreve a hierarquia dos requisitos, um

requisito é contido por outro requisito de hierarquia superior.
A composição é um relacionamento em que um requisito é composto por outros
requisitos, ficando o requisito composto sem poder ser realizado sem a realização dos
requisitos menores.

A dependência é um relacionamento em que um requisito depende de outro requisito

para ser realizado. O requisito dependente não pode ser realizado sem que o outro
requisito seja realizado primeiro.

O requisito e as duas relações referidas estão representados na figura 6.

Figura 6: Contenção, requisito e dependência.

2.2.2 Diagrama de casos de uso

Um diagrama de caso de uso é um tipo de diagrama UML que identifica as iterações
entre os diferentes utilizadores do sistema e as funcionalidades do mesmo. Os
utilizadores são chamados de atores que são representados por um boneco. Já os casos
de uso são representados por uma elipse, com o nome do caso de uso lá dentro.

As interações são identificadas por um segmento de reta entre o ator e o caso de uso,
sendo que um ator pode estar relacionado a vários casos de uso num mesmo diagrama.
A interação entre ator e caso de uso pode ser visualizada na figura 7.

14
 Figura 7: Iteração entre ator e caso de uso.

2.2.3 Diagrama de atividades

Um diagrama de atividades é um tipo de diagrama da linguagem UML que descreve o
fluxo de atividades executadas por um sistema. Este diagrama descreve e simplifica as
etapas realizadas num diagrama de casos de uso, dado que mostra a sequência de
atividades, como as decisões são tomadas e como as condições afetam o fluxo.

Alguns dos componentes mais comuns e são:

 Ação: uma etapa da atividade em que o utilizador ou sistema realiza uma
determinada tarefa. Representa-se como a figura 8-A

 Nó de decisão: um ramo condicional no fluxo representado por um

diamante. Inclui uma única entrada e duas ou mais saídas consoante
diferentes condições. Representa-se como a figura 8-B

 Símbolo de conector: Mostra o fluxo de direção, ou fluxo de controle, da

atividade. Representa-se como a figura 9-A.

 Símbolo de garfo: Divide um único fluxo de atividade em duas atividades

simultâneas. Representa-se como a figura 9-B.

 Símbolo de junta: Combina duas atividades simultâneas e as reintroduz em

um fluxo onde apenas uma atividade ocorre por vez. Representa-se como a
figura 9-C.

 Símbolo de final de fluxo: Representa o final de um fluxo de um

processo específico. Este símbolo não representa o fim de todos os fluxos em
uma atividade. Representa-se como a figura 10-A.

 Nó inicial: simboliza o início da atividade. É representado por um círculo

preto. Representa-se como a figura 10-B.

 Nó final: representa a etapa final da atividade. Representa-se como a figura

10-C.
A B

Figura 8: Ação; Nó de decisão;

15
 A B C

Figura 9: Conector; Garfo; Junta.

A B C

Figura 10: Final de fluxo; Nó inicial; Nó final.

Os diagramas de atividades são frequentemente usados, pois ajudam a visualizar o fluxo

de trabalho, mas também podem ser aplicados a qualquer sistema ou processo que
tenha atividades sequenciais.

2.2.4 Diagrama de blocos

O diagrama de blocos é um tipo de diagrama utilizado na linguagem SysML que
representa graficamente blocos que compõem um sistema. As interações entre os
blocos são representadas por diferentes tipos de setas. É possível assim descrever a
arquitetura geral do sistema.

Cada bloco é representado por um retângulo e as suas relações por meio de setas, como
representado na figura 11.

Figura 11: Agregação, bloco e composição.

2.2.5 Diagrama interno de blocos

O diagrama de blocos é um tipo de diagrama utilizado na linguagem SysML que
representa graficamente o interior do sistema. Mostra como os elementos do sistema
estão organizados e conectados internamente.

16
Os elementos que são propriedade da parte são representados por um bloco normal, já
os elementos que são propriedade de referência são representados por um bloco que
está tracejado à volta. A representação destes blocos é visível na figura 12.

Figura 12: Bloco propriedade da parte conectado a um bloco de referência.

2.3 Interface para interação entre elementos de sistema

Tendo em atenção a necessidade de haver comunicação segura entre os diferentes
elementos do sistema informático LockerHive, adotou-se a interface API RESTful. É uma
interface API (Interface de Programação de Aplicações) que está em conformidade com
as restrições do estilo da arquitetura REST (Representational State Transfer).
Uma API é um conjunto de regras e protocolos que permite integrar software de uma
aplicação, funcionando como mediador entre sistemas de software. Estes sistemas
podem enviar solicitações como respostas para cada um.
O estilo de arquitetura web, REST, fornece um conjunto de restrições a ser seguidas pelas
aplicações web, para facilitar a comunicação entre as mesmas. Estas restrições incluem
o uso dos métodos HTTP (GET, POST, PUT, DELETE) para o acesso e manipulação de
recursos, a identificação dos recursos por meio de URIs1 (Uniform Resource Identifiers) e
o uso de representações de dados para a comunicação entre cliente e servidor,
estabelecendo um padrão na comunicação e interação entre estes.
Para que uma API seja considerada RESTful, é necessário de estar em conformidade com
as seguintes restrições:

 Arquitetura cliente-servidor - composta por clientes, servidores e recursos, com

solicitações feitas via protocolo HTTP;
 Comunicação Stateless - nenhuma informação do cliente é armazenada entre as
solicitações;
 Cache - os dados devem ser armazenados em cache para simplificar interações
cliente-servidor;
 Interface uniforme - para troca de informações em formato-padrão entre cliente-
servidor;
 Sistema em camadas - as camadas têm de estar organizadas para cada uma ter
uma responsabilidade especifica, sendo organizadas hierarquicamente, não
sendo visíveis para o cliente;

1
sequência de caracteres que identifica de forma única um recurso na web

17
  Código sob demanda - habilidade de enviar código executável do server para o
cliente quando solicitado.
Em suma, uma interface API RESTful segue um conjunto de regras e princípios que
proporcionam vantagens significativas em termos de escalabilidade, flexibilidade e de
independência.
De realçar que no sistema informático LockerHive as representações dos recursos
enviadas pelo servidor para o cliente encontram-se maioritariamente no formato JSON
Siren. Este formato está detalhado na próxima subsecção, 2.3.1, Recursos na arquitetura
REST.

2.3.1 Recursos na arquitetura REST

A API RESTful oferece suporte a diferentes formatos de representação de recursos, sendo
até possível ao cliente indicar o formato de recurso com que é capaz de processar a
resposta proveniente do servidor, no cabeçalho “Accept”. O servidor verifica o cabeçalho
“Accept” da solicitação do cliente e seleciona a representação apropriada para a
resposta.
Nos vários formatos de resposta existentes, encontram-se também os que são chamados
hipermédia, que permitem que na resposta se envie não só os dados dos recursos, mas
também links e informações necessárias para navegar e interagir com esses recursos de
forma dinâmica.
Foi com base no tipo de formato de recursos hipermédia que foi escolhido o formato de
resposta a ser enviado pelo servidor do sistema informático LockerHive, que se designa
por JSON Siren.
JSON Siren é um formato de resposta hipermédia para APIs RESTful. O seu principal
objetivo é fornecer uma estrutura padronizada para descrever o conteúdo de entidades,
onde cada objeto contém informações sobre estas e as relações entre si.
O formato de recursos JSON Siren, apresenta-se desta forma:

 Classe (“class”) – descreve a natureza do conteúdo da entidade;

 Título (“title”) – texto descritivo acerca da entidade;
 Propriedades (“properties”) – um conjunto de pares chave-valor que descrevem
o estado da entidade;
 Entidades (“entities”) – coleção de sub-entidades relacionadas;
 Ações (“actions”) – coleção de objetos ações;
 Links – coleção de itens que descrevem links de navegação, distintos dos
relacionamentos entre entidades. Os itens de link devem conter um atributo rel
para descrever o relacionamento e um atributo href para apontar para a URI de
destino.

18
2.4 Tecnologias usadas no desenvolvimento do sistema
informático LockerHive
Para a implementação do sistema informático LockerHive, a escolha das tecnologias foi
baseada na experiência e familiaridade, bem como na adequação das mesmas aos
requisitos e objetivos do sistema.
Após a elaboração de vários diagramas e esquemas, chegou-se a uma conclusão acerca
dos principais elementos necessários para que o sistema informático LockerHive seja
funcional, estes elementos são:

 Base de dados;
 Servidor;
 Aplicação móvel;
 Aplicação web da loja online.
De modo a ter-se uma base de dados persistente e relacional em que seja possível
consultar e manipular os dados com a linguagem SQL, decidiu-se usar o SGBD
PostgreSQL, que está explicado mais em detalhe na subsecção 2.4.1.
Para o servidor optou-se por utilizar a framework Spring (descrita com mais detalhe na
subsecção 2.4.2), já utilizada em projetos anteriores, que apresenta ferramentas para
diferentes aspetos, possibilitando o aceleramento do processo de desenvolvimento do
sistema, a garantia de proteção aos dados, com vários recursos de autenticação e
autorização, a integração com a base de dados, entre outras.
No desenvolvimento da aplicação móvel utilizou-se o kit de ferramentas moderno
Jetpack Compose (descrito em mais detalhe na subsecção 2.4.3). Este kit cria interfaces
nativas para o utilizador, que permite um desenvolvimento da aplicação móvel com
menos código e com vários recursos modernos para o Android.

Na simulação da aplicação web da loja online com parceria LockerHive, optou-se pela
biblioteca de JavaScript, React (descrita em mais detalhe na subsecção 2.4.4), pois ao
ter a vantagem da reatividade, é possível fazer alterações de estado e serem
automaticamente refletidas na interface da loja, proporcionando assim uma
experiência mais fluida para a simulação.
Ao longo da implementação dos principais elementos do sistema informático
LockerHive, houve a necessidade de utilização de mais dois elementos, ambos externos
ao sistema, mas vitais para garantir que funcionamento de algumas funcionalidades do
sistema LockerHive. Estes são:

 Firebase Cloud Messaging;

 Google Maps API.
Tendo em atenção a necessidade de se enviar notificações do servidor para a aplicação
móvel do sistema informático LockerHive, escolheu-se o serviço Firebase Cloud

19
Messaging, descrito em mais detalhe na secção 2.4.5. Esta solução permite, entre outras
vantagens, a entrega confiável de mensagens sem custo e a personalização das
notificações.
A escolha da API para ter recursos a mapas na aplicação móvel e na aplicação web da
simulação da loja, foi a Google Maps API (descrita em mais detalhe na subsecção
2.4.6). A escolha muito se deveu em conta à particularidade de ser gratuita, o que para
este tipo de APIs, não é muito comum, e de possibilitar a personalização do mapa,
sendo assim possível alternar a cor dos marcadores da localização das colmeias
LockerHive.

2.4.1 Sistema de gestão de base de dados

Existem vários SGBD no mercado com diferentes funcionalidades sendo uns de acesso
gratuito e outros com custos associados. No entanto, o mais importante na escolha de
um SGBD é o modelo de dados que suporta.

Os modelos de dados mais comuns são:

 Modelo relacional;
 Modelo hierárquico;
 Modelo de ficheiros;
 Modelo de grafos.
As grandes diferenças entre estes modelos são a forma como os dados são estruturados,
organizados e relacionados, havendo uns com vantagens em certas funcionalidades e
outros com vantagens noutras, por isso se diz que a escolha do modelo de dados
depende do contexto do sistema que se quer implementar.
No nosso caso, de acordo aos requisitos do projeto, escolheu-se o modelo relacional. A
principal razão desta escolha residiu na forma como os dados são organizados em
tabelas com colunas e linhas, e com relacionamentos estabelecidos por chaves primárias
e estrangeiras.
Deste modo, optou-se por um SGBD que fosse relacional e que satisfizesse as
necessidades do sistema informático LockerHive. O SGBD escolhido foi o PostgreSQL,
pois é um sistema de gestão de bases de dados relacional de uso gratuito que permite
garantir a integridade, organização e escalabilidade dos dados.

Este SGBD foi o PostgreSQL, é um sistema de gestão de bases de dados relacional de uso
gratuito que permite garantir a integridade, organização e escalabilidade dos dados.
Para facilitar a administração e o desenvolvimento da base de dados PostgreSQL foi
utilizada a ferramenta de administrção pgAdmin, que fornece uma interface gráfica para
gerir e interagir com base de dados em PostgreSQL.

20
2.4.2 Framework para execução de um Servidor
A escolha de uma framework2 de execução do servidor é fundamental para o
desenvolvimento de um sistema informático eficiente e robusto. Existem várias
frameworks disponíveis que oferecem recursos e funcionalidades para facilitar o
desenvolvimento de aplicações web e APIs RESTful.
Uma das frameworks mais populares é o Spring, da plataforma Java3. O Spring simplifica
o processo de criação de microserviços, aplicações Java, etc, oferecendo funcionalidades
como a técnica de injeção de dependência, o aumento da facilidade de interação com as
solicitações HTTP ou a definição de rotas. Esta framework tem uma extensão que se
designa por Spring Boot. O Spring Boot simplica processos de configurações que tinham
de ser configurados manualmente. Isto incluía a configuração de ligações à base de
dados, configurações de segurança, integrações com frameworks web, entre outros.
Assim consegue-se reduzir a quantidade de configuração manual necessária e acelerar
o processo de desenvolvimento.
A framework escolhida para a execução do servidor foi então a Spring, com a extensão
Spring Boot, devido às funcionalidades que acrescentam no desenvolvimento do
servidor, já mencionadas anteriormente.

2.4.3 Ferramenta de Desenvolvimento de Aplicações Móveis

Para o desenvolvimento de um aplicativo móvel, é necessário utilizar uma ferramenta
específica para aplicações móveis, pois estas ferramentas oferecem um conjunto de
recursos para facilitar a criação destas aplicações.
No desenvolvimento da aplicação móvel do sistema informático LockerHive foi utilizada
a ferramenta Jetpack Compose. Esta é uma ferramenta moderna especifica para o
android4, que possibilita a criação de interfaces de utilizador nativas que simplificam e
aceleram o desenvolvimento da interface do utilizador no android. Com o Jetpack
Compose, é possível dar vida às aplicações com menos código, melhores ferramentas e
APIs Kotlin intuitivas.

2.4.4 Interface gráfica de aplicações web

O fornecimento de recursos, tal como o aspeto visual, de uma aplicação web para um
cliente, é realizado por uma interface gráfica de aplicações web. Esta interface, permite
assim, a possibilidade de haver interações entre cliente e aplicação web.
Para fazer a gestão desta interface gráfica da aplicação web da loja online, utilizou-se
React. O React é uma biblioteca de JavaScript que cria interfaces de utilizador interativas
e reativas em aplicações web. É sensível à mudança de estado e utiliza o conceito DOM 5

2
conjunto de bibliotecas, componentes e ferramentas que fornecem uma estrutura para desenvolver
aplicações.
3
Linguagem de programação.
4
Sistema operativo móvel desenvolvido pelo Google.
5
representação estrutural da interface do utilizador como uma árvore.

21
que é uma representação virtual eficiente do verdadeiro DOM, que faz com que o React
apenas atualize as partes da interface do utilizador que foram alteradas, ficando assim,
a renderização mais rápida e eficiente.

2.4.5 Serviço de notificações para aplicações móvel

Para a possibilidade de se poder enviar mensagens de plataformas diferentes, como de
um servidor para uma aplicação móvel, surgiu o conceito de notificações push6. Este
conceito teve como objetivo designar as notificações que aparecem no ecrã ou nas
notificações recebidas no dispositivo móvel, sem a necessidade de a aplicação em causa
estar a ser executada.
Um destes serviços é o FCM (Firebase Cloud Messaging). Este serviço foi desenvolvido
pela Firebase e e possibilita o envio, em tempo real, de mensagens desde o servidor para
dispositivos com o sistema operacional android ou iOS. A utilização deste serviço é
simples de implementar, contudo é necessário criar um projeto em Firebase, para obter
um token único. Este é essencial para que seja possível autenticar as mensagens
provenientes da API do servidor para a Firebase. Ao estarem autenticadas, as mensagens
são reencaminhas da API da FCM para o dispositivo móvel específico.

2.4.6 API de geração de mapa

De modo a ser possível exibir visualmente um mapa com aplicação web ou com uma
aplicação móvel, é necessário a respetiva aplicação solicitar este recurso a API exteriores,
desenvolvidas com este propósito.
Para exibir o mapa com as colmeias constituintes deste sistema informático LockerHive,
foi utilizada a Google Maps API desenvolvida pela Google, esta fornece acesso a uma
grande variedade de funcionalidades relacionadas a mapas, sendo que os
desenvolvedores podem adicionar mapas dinâmicos, interativos e personalizados às
suas aplicações. Na aplicação android foi utilizada a Maps SDK para android e no
simulador da loja online o Maps Embed API. Ambas as APIs permitem ao utilizador
interagir com o mapa.

6
Empurrada.

22
3 Análise do Problema e Conceção do
Sistema Informático LockerHive
Neste capítulo é apresentada a abordagem ao problema e aos modelos de dados
estabelecidos para a sua representação, desenvolvidos antes da implementação das
aplicações do sistema informático LockerHive. De modo a, ao inicializar-se o
desenvolvimento da implementação do sistema, já se saber o que realmente se
pretende como produto final.
O restante capítulo está organizado por secções, na secção 3.1 os requisitos funcionais,
na secção 3.2 os requisitos não funcionais, na secção 3.3 os diagramas de requisitos, na
secção 3.4 os casos de uso, na secção 3.5 a arquitetura, na secção 3.6 o modelo de dados,
na secção 3.7 o modelo relacional, na secção 3.8 os diagramas de atividade e na secção
3.9 as medidas de segurança e proteção de dados no sistema LockerHive.

3.1 Requisitos funcionais

Nos requisitos funcionais é onde estão identificadas as possíveis funcionalidades de um
sistema. Descrevem o que se pretende implementar no sistema.

O sistema informático LockerHive tem os seguintes requisitos funcionais:

REQ1. Receber e gerir pacotes desde um centro de distribuição para uma

colmeia à escolha do utilizador;
REQ2. Acompanhamento e verificação do estado dos pacotes desde o
centro de distribuição (ponto de situação);
REQ3. Receber notificações em determinados momentos chave do processo
(chegada do pacote ao centro de distribuição, chegada do pacote à
célula escolhida, etc);
REQ4. Alteração da colmeia de entrega enquanto o pacote ainda estiver no
centro de distribuição;
REQ5. Associar colmeias à conta sem limitações;
REQ6. Proceder ao registo por parte do utilizador e ser capaz de fazer login,
com o seu email e password;
REQ7. Visualizar o mapa de colmeias;
REQ8. Visualizar mapa com as colmeias associadas ao utilizador;
REQ9. Remover colmeias associadas à conta;
REQ10. Obter informações acerca de determinada colmeia, (dimensões da
maior célula, se possuí refrigeração, horário de funcionamento,
tráfego, etc);
REQ11. Reportar anomalias do processo de entrega do pacote ou do sistema;
REQ12. Visualizar quantas notificações estão por ler;
REQ13. Visualizar histórico de notificações;
REQ14. Obter chave para abrir a/s célula/s com o/s respetivo/s item/s;
REQ15. Visualizar histórico e estado das anomalias reportadas;
REQ16. Visualizar saldo corrente;

23
 REQ17. Visualizar histórico de transações;
REQ18. Carregar saldo;
REQ19. Fazer registo;
REQ20. Visualizar histórico de pacotes recolhidos;
REQ21. Adiar o transporte do centro de distribuição para a colmeia em 30
dias no máximo;
REQ22. Visualizar os pagamentos pendentes que a conta tem;
REQ23. Utilizador editar o seu perfil;
REQ24. Utilizador não registado, após realizar registo, conseguir ver o ponto
de situação dos pacotes que encomendou antes de estar registado,
para alguma colmeia;

Os administradores deste sistema terão as seguintes funcionalidades:

REQ25. Gerir o sistema LockerHive;

REQ26. Fazer autenticação;
REQ27. Gerir colmeias;
REQ28. Mudar o estado do pacote;
REQ29. Eliminar contas;

As lojas online com parceria com o sistema informático LockerHive terão as seguintes
funcionalidades:

REQ30. Exibir mapa com todas as colmeias;

REQ31. Permitir que um cliente da loja online escolha uma colmeia do
sistema informático LockerHive como destino da sua encomenda;
REQ32. Se o cliente da loja se autenticar no sistema informático LockerHive
no momento de escolher a colmeia, o mapa das colmeias terá as
colmeias associadas do utilizador de cor diferente;

3.2 Requisitos não funcionais

Os requisitos não funcionais são requisitos que estão relacionados com as características
de qualidade, desempenho, segurança, confiabilidade, etc, não focando em específico,
com as funcionalidades do sistema, mas que são inerentes a um sistema que deseja ser
funcional.

O sistema informático LockerHive deverá ter os seguintes requisitos não funcionais:

1. Proteção contra acesso não autorizado;

2. Cumprir os regulamentos aplicáveis, tais como o Regulamento Geral sobre a
Proteção de Dados (RGPD);
3. A localização está disponível em inglês e português.

24
3.3 Diagrama de requisitos
O diagrama de requisitos da aplicação móvel está representado em três partes devido
ao seu tamanho (parte 1 na figura 13, parte 2 na figura 14 e parte 3 na figura 15.

Figura 13: Parte 1 do diagrama de requisitos da aplicação móvel LockerHive.

25
Figura 14: Parte 2 do diagrama de requisitos da aplicação móvel LockerHive.

26
Figura 15: Parte 3 do diagrama de requisitos da aplicação móvel LockerHive.

27
3.4 Casos de uso
Para uma melhor compreensão da organização dos requisitos funcionais do sistema
informático LockerHive, utilizou-se um diagrama de casos de uso para o nosso sistema.

Na figura 16 encontra-se representado o diagrama de casos de uso que destaca as

principais funcionalidades e as interações entre atores externos e o sistema (já descritos
na secção 2.2.2).

Figura 16: Diagrama de casos de uso da aplicação móvel do sistema informático

LockerHive.

28
3.5 Arquitetura do Sistema Informático LockerHive
Para se definir a arquitetura de um sistema, tem-se de ter em conta os elementos que
possui e as suas interações.

A arquitetura do sistema informático LockerHive é representado pelo diagrama

presente na figura 17. Este é constituído por uma aplicação móvel que será utilizada
pelo cliente do serviço LockerHive. A API da aplicação móvel comunica com a API do
servidor que atende as solicitações do cliente e obtém informação acerca destes,
proveniente de uma base de dados. A API do servidor comunicará também com a API
da aplicação web dos administradores. Já para realizar a simulação de uma loja online
com parceria LockerHive, foi desenvolvido uma aplicação web que irá também interagir
com o servidor.

Figura 17: Sistema informático LockerHive.

29
Para uma representação não tanto abstrata como a anterior, utilizou-se a linguagem de
modelação de sistemas SysML no desenvolvimento de um diagrama de blocos para
representar o sistema informático LockerHive na figura 18.

Figura 18: Diagrama de blocos do sistema informático LockerHive.

Para se representar graficamente a organização interna dos elementos, com as
respetivas interações, do sistema informático LockerHive, optou-se por utilizar do
mesmo modo que o diagrama anterior a linguagem SysML para produzir um diagrama
interno de blocos, representado na figura 19.

Figura 19: Diagrama interno de blocos do sistema informático LockerHive.

3.6 Modelo de dados

Esta secção está dividida na subsecção 3.6.1, onde se encontra o modelo entidade-
relação desenvolvido e 3.6.2 que está o nosso modelo relacional.

30
3.6.1 Modelo Entidade-Relação LockerHive
Para representar os dados do nosso sistema informático foi realizado o modelo de
entidade-relação representado na figura 20:

Figura 20: Modelo Entidade-Associação do sistema informático LockerHive.

A entidade que representa o cliente do sistema informático LockerHive, é a entidade
costumer. Esta serve de base para as entidades Unregistered Costumer, Registered
Costumer e Registered Store, constituindo, assim, uma relação IS-A, sendo a chave
primária de cada uma, costumer_id. A entidade Costumer possui também três relações
fracas com Anomaly, Notification e Transaction, que representam respetivamente as
anomalias, notificações e transações de saldo associadas a um cliente do sistema.
A representação de cada Hive e das suas Cells é feita através de entidades com o mesmo
nome, sendo que cada Cell é uma entidade fraca de Hive. Cada Hive irá conter o
identificador do centro de distribuição a que está associado, sendo este representado
pela entidade Distribution Center. Além disto tem uma relação fraca com a entidade
State_Atl_Date, em que Cell irá ter também. A entidade State_Alt_Date tem como
objetivo registar as mudanças de estado e quando foram feitas de Hive e Cell.

31
Costumer e Hive, ao possuírem uma relação M-N constituem uma relação que foi
designada de Costumer Hive. Esta representa os Hives que o Costumer do sistema tem
associados na sua conta.
A entidade Package representa os pacotes que um determinado Costumer comprou e
pretende enviar para um certo Hive, sendo que estes Packages terão o Hive, escolhido
pelo Costumer, associado na relação Costumer_Hive. Esta entidade tem também duas
relações fracas com ela própria para que seja possível o Costumer alterar o Hive de cada
Package, havendo assim necessidade de se criar outro Package, este novo Package vai
ter a referência para o Package anterior, e o anterior para o novo Package. O Package ao
estar prestes a ser transportado para o Hive, irá ficar associado a um Bundle. Esta
entidade possibilita, caso seja possível, a junção de vários Packages que são do mesmo
Costumer e têm o mesmo Hive como destino, e que através de uma verificação de
condições (tamanho, condições de armazenamento), podem ser agrupados e
depositados na mesma Cell. A mudança de estado do Package vai ser guardado em State
Alt Packages, que vai conter as datas desta mudança de estado, permitindo saber o
histórico de mudança de estado do Package.
A entidade Costumer_Request vai guardar os pedidos do Costumer, como a mudança de
Hive de um Package. Existe também a entidade Package_Bundle gerada pela relação M-
N entre Package e Bundle, onde se pode associar cada Bundle a um ou mais Packages.

A entidade Bundle irá ficar associada a um Operator quando for altura de a transportar
para a Cell indicada pelo sistema informático LockerHive. Quando o Bundle estiver
entregue e pronto a ser recolhido pelo Costumer, ser-lhe-á fornecido um Code que
permite que este consiga abrir a Cell que contém o Bundle. Este Code é então
representado pela entidade Pickup Code.

3.7 Passagem de modelo EA para modelo relacional

Após a criação do modelo de Entidade-Associação realizou-se a passagem do modelo ER
para o modelo relacional de acordo com as regras em Fundamentals Of Database
Systems[2].

Entidades no modelo relacional:

 HIVE (PK (hive_id), state, name, traffic, address, longitude, latitude, FK(dc_id ref
DISTRIBUTION_CENTER));
 DISTRIBUTION_CENTER (dc_id, address, name)
 COSTUMER (PK (costumer_id), name, contact, email)
 REGISTERED_COSTUMER (PK (costumer_id), FK(costumer_id ref COSTUMER),
balance, nif, password, notif_token, registered_time)
 UNREGISTERED_COSTUMER (PK (costumer_id), FK(costumer_id ref COSTUMER)
 REGISTERED_STORE (PK (costumer_id), password, FK(costumer_id ref
COSTUMER)
 COSTUMER_HIVE (PK (id), random_string, FK(costumer_id ref COSTUMER)
FK(hive_id ref HIVE));

32
  PACKAGE(PK(package_id, costumer_id, hive_id) dc_arrival_time, max_length,
max height, max_width, max_weight, store_temp, state, token, FK(costumer_id
ref COSTUMER), FK(hive_id ref HIVE), FK(next_pkg_id, costumer_id, hive_id ref
PACKAGE), FK(previous_pkg_id, costumer_id, hive_id ref PACKAGE));
 BUNDLE (PK (bundle_id), state, max_cell_days, duration, FK (operator_id ref
OPERATOR), FK (cell_id, hive_id ref CELL));
 CELL (PK (hive_id, cell_id), max_temp, min_temp, state, length, width, height, FK
(hive_id ref HIVE));
 TRANSACTION (PK (transaction_id, costumer_id)), value, time_date, state,
description, FK(costumer_id ref REGISTERED_COSTUMER), FK(package_id,
costumer_id, hive_id) ref PACKAGE) )
 ANOMALY (PK(anomaly_id, costumer_id)), title, state, description, response,
time_date, FK(package_id, costumer_id, hive_id ref PACKAGE), FK(costumer_id
ref COSTUMER));
 COSTUMER_REQUEST(PK (request_id), type, time_date, FK(costumer_id ref
REGISTERED_COSTUMER), FK(package_id, costumer_id, hive_id ref PACKAGE));
 NOTIFICATION(PK(notification_id, costumer_id ), state, type, time_date,
description, FK(costumer_id ref COSTUMER), FK(package_id, costumer_id,
hive_id ref PACKAGE));
 OPERATOR(PK(operator_id), name);
 PICKUP_CODE(PK(code_id, bundle_id), duration, code, FK(bundle_id ref
BUNDLE);
 STATE_ALT_DATE(PK (alt_id,hive_id) new_state, prev_state, time_date, FK
(hive_id ref HIVE), FK (cell_id ref CELL);
 PACKAGE_BUNDLE(PK (id), FK(package_id, costumer_id, hive_id ref PACKAGE),
FK(bundle_id ref BUNDLE);
 STATE_ALT_PACKAGES(PK (alt_package_id,package_id, costumer_id, hive_id)
new_state, prev_state, time_date, FK (package_id, costumer_id, hive_id ref
PACKAGE).

3.8 Implementação dos casos de uso do sistema

informático LockerHive
De modo a descrever a implementação dos casos de uso do sistema informático
LockerHive, utilizou-se diagramas de atividade para ser mais percetível de como se
pretende implementá-los.
A atividade de autenticação verifica se o cliente já possui conta ou não. Caso a tenha
poderá fazer o registo normalmente, com o email e password. No caso contrário, terá de
proceder ao registo e criar conta para aceder ao sistema informático LockerHive. Após
registo, efetuado com sucesso poderá se autenticar.
Na figura 21 está representada a atividade de autenticação.

33
 Figura 21: Diagrama de atividades: Autenticação.

Na atividade de visualizar o mapa de colmeias o utilizador irá dispor de um mapa com

todas as colmeias do sistema, sendo que poderá optar pelo mapa com apenas as
colmeias que tem associadas. Cada colmeia é selecionável. Se o utilizador selecionou
uma colmeia que não é associada à conta, irá aparecer a opção de a associar à conta e
também outros detalhes referentes às características e informações personalizadas
acerca dos dados a introduzir numa compra, caso queira que esta lhe seja entregue na
colmeia selecionada. Caso a colmeia selecionada pelo utilizador já for associada à conta,
irá aparecer a opção de a desassociar, e também os detalhes referentes à característica
da colmeia.
Na figura 22 está representada a atividade de visualizar o mapa de colmeias.

34
 Figura 22: Diagrama de atividades - visualização do mapa de colmeias.

Na atividade de reportar uma anomalia, irá aparecer duas opções Se o utilizador tiver já
anomalias reportadas, poderá visualizá-las e ver o estado em que se encontram ou poder
reportar uma nova anomalia.

Na figura 23 está representada a atividade de reportar uma anomalia.

Figura 23: Diagrama de atividades: reportar uma anomalia.

35
Na atividade de visualizar o saldo, o utilizador terá o seu saldo corrente ao longo dos
diferentes ecrãs, sendo que poderá carregar o saldo com um valor à sua escolha.
Também será possível o utilizador visualizar o histórico de transações.
Na figura 24 está representada a atividade de visualizar saldo.

Figura 24: Diagrama de atividades: visualizar o saldo.

Na atividade de visualizar notificações, caso o utilizador tenha notificações por ler,
poderá saber ao certo quantas são e poderá visualizá-las. Também poderá visualizar o
histórico de notificações já marcadas como lidas.
Na figura 25 está representada a atividade de visualizar notificações.

36
 Figura 25: Diagrama de atividades: Visualização de notificações.
Na figura 26 está representada a atividade de acompanhamento do pacote a partir do
centro de distribuição até à célula, só possível para os utilizadores que tenham pacotes/s
registado/s por recolher. O utilizador terá as opções de visualizar o estado do pacote,
aceder à chave para a abertura da célula onde estiver o pacote e, se quiser, alterar a
colmeia que escolheu para recolher o pacote, para outra. Se esta for de outro centro de
distribuição relativamente à colmeia escolhida originalmente, terá custos adicionais.
Caso o utilizador não tenha saldo para esta mudança, não a poderá fazer e terá de
carregar o saldo necessário.

37
 Figura 26: Diagrama de atividades: acompanhamento do pacote a partir do centro de
distribuição até à célula.

3.9 Medidas de segurança e proteção de dados no

sistema informático LockerHive
A segurança desempenha um papel fundamental em qualquer sistema, quer para
garantir segurança no sistema de ataques exteriores, quer para proteger os dados
pessoais dos clientes dos sistemas.

Deste modo, existem certas medidas que tem de estar presentes nos sistemas, sendo
estas:

 Confidencialidade – Prevenção de divulgação não autorizada de informação;

 Integridade – Informações/dados recebidos estão exatamente como foram
enviados por uma entidade autorizada;
 Disponibilidade – Propriedade de ser acessível e utilizável mesmo sob falhas.
Há várias formas de garantir que estas medidas estejam presentes nos sistemas. No caso
do sistema informático LockerHive, destaca-se:
Para garantir confidencialidade:

 Acesso Limitado: o acesso aos dados será restrito apenas a clientes autorizados.
Cada cliente terá acesso apenas às suas próprias informações, não conseguindo
aceder a informações de outros clientes ou de recursos para os quais não tem

38
 autorização. A solicitação de recursos de origens não reconhecidas pelo servidor,
também não serão possíveis.
 Identificação por Cookies: cada cliente ao fazer a sua autenticação no sistema
informático LockerHive, é-lhe atribuído um cookie que o identifica. Neste cookie
está adicionado o atributo HttpOnly7 aplicado nos cabeçalhos da resposta,
impedindo que os cookies sejam acedidos por scripts do lado do cliente.
Para garantir integridade:

 Hash8: para a garantia de integridade das passwords dos utilizadores, será

utilizado um mecanismo de hash, dado que é computacionalmente inviável
reverter o hash para obter a entrada original, a mesma entrada produzirá o
mesmo hash, portanto apenas se guarda o hash da password uma vez e uma
alteração nos dados de entrada resulta numa mudança significativa no valor do
hash.
 Uso de tokens: o token será utilizado para guardar a identificação do cliente e a
respetiva role, é gerado por um algoritmo de encriptação, não sendo possível
decifrar o seu conteúdo sem a chave secreta.
Já para garantir a disponibilidade do sistema informático LockerHive deverão ser
realizados testes para identificar as possíveis falhas no sistema e implementar blocos de
try-catch9, tornando possível que se trate das falhas de forma personalizada e assim
tornar o servidor tolerável à falha.

4 Aspetos do Desenvolvimento do
Sistema Informático LockerHive
Neste capítulo aborda-se os principais aspetos relacionados com o desenvolvimento e
implementação dos principais elementos do sistema informático LockerHive.
Estes elementos já foram referidos anteriormente neste documento, estando visíveis no
diagrama de blocos do capítulo anterior.
A descrição da implementação destes elementos está descrita nas seguintes subsecções:

 4.1 – Base de dados;

 4.2 – Segurança e proteção de dados;
 4.3 – Servidor;
 4.4 – Aplicação móvel;
 4.5 – Loja online com parceria;
 4.6 – Aplicação web para os administradores.

7
atributo que protege o cookie.
8
é uma sequência de bits geradas por um algoritmo de dispersão.
9
são blocos que lidam com as falhas.

39
4.1 Base de dados
O sistema de gestão de base de dados escolhido para a persistência dos dados do sistema
informático LockerHive foi o PostgreSQL, devido às vantagens mencionadas
anteriormente na secção 2.4.1.
As tabelas de cada entidade foram estabelecidas de acordo a secção 3.7. Para garantir a
integridade e a consistência dos dados das tabelas, foram criados vários triggers que são
executados sempre que o evento associado ocorra, antes ou depois, sendo evento uma
inserção, atualização ou remoção numa tabela.

4.2 Servidor
O servidor do sistema informático LockerHive foi desenvolvido com a framework Spring
(já descrita na secção 2.4.2) utilizando a extensão Spring Boot e com a linguagem de
programação Kotlin.
A organização do servidor é feita por oito componentes principais:

 Config – encontra-se as configurações para que seja permitido a API da aplicação

web da loja simulada conseguir interagir com a API do servidor;
 Controllers – é onde se encontram os controladores que lidam com as
solicitações e respostas HTTP do cliente. Este componente está organizado em
doze subcomponentes, tendo cada um, um URI base diferente.
 Data - é onde se manipula a resposta dos controladores para enviar ao cliente.
Os controladores que usem este componente, retornam uma resposta em
formato JSONSiren;
 Exceptions – é onde se encontram as personalizações de possíveis falhas que
poderão ocorrer durante o tratamento das solicitações, permitindo ao cliente
saber mais em detalhe o porquê de ter havido a falha;
 Firebase – onde estão as configurações para que seja possível enviar mensagens
como notificações para Android;
 Model – onde se encontram os objetos de domínio;
 Pipeline – onde ocorre a manipulação dos pedidos antes de irem para os
controladores e das respostas antes de irem para o cliente;
 Repositories – onde se encontram as implementações à interface
CrudRepository que agrega as operações de manipulação de dados;
Este servidor ao atuar como elemento central entre as interações dos vários elementos
do sistema (como ilustrado no diagrama interno de blocos da figura 17), teve-se de ter
em atenção na forma como se interage com a base de dados e como se envia, recebe e
protege dados.
Dado isto, dividiu-se o restante desta secção, em quatros subsecções que descrevem as
implementações para cada funcionalidade:

40
  Interação com a base de dados – subsecção 4.2.1;
 Formato de envio de dados – subsecção 4.2.2;
 Processo de tratamento de solicitações – subsecção 4.2.3;
 Segurança dos dados – subsecção 4.2.4.

4.2.1 Interação com a base de dados

A conectividade da base de dados para acesso e manipulação dos dados ao servidor do
sistema informático LockerHive é realizado através do módulo Spring Data JPA, da Spring.
Este módulo é uma camada de abstração sobre o JPA10 (Java Persistence API), mas mais
flexível, simplificando o desenvolvimento de aplicações JPA, em conjunto com o
framework Spring.
O acesso e manipulação de dados é realizado através de anotações JPA, interfaces de
repositório e operações CRUD (Create, Read, Update, Delete), disponíveis no Spring Data
JPA. O Spring Data JPA faz a tradução das operações realizadas nas interfaces de
repositório em consultas SQL e utiliza a biblioteca JDBC 11 (Java Database Connectivity)
para as executar na base de dados.
A realização destas operações sobre a base de dados é feita por métodos predefinidos
presentes na interface CrudRepository da Spring Data.
Deste modo, desenvolveu-se uma interface de acesso a dados especifica para cada
entidade e relação, com a necessidade de estenderem a interface CrudRepository. Ao
estenderem desta, é-lhes disponibiliza os métodos para realizar as operações CRUD. Nas
interfaces de acesso a dados criadas, teve-se de adicionar a anotação @Repository para
indicar ao Spring que é um componente de acesso a dados, para que se adicione os
recursos necessários para a sua finalidade.

4.2.2 Formato de envio de dados

O formato de envio de dados escolhido, como já referido anteriormente, foi o JSONSiren,
contudo, o servidor suporta também outros formatos, como o formato de texto, HTML,
XML, entre outros. Caso não haja nenhuma restrição no cabeçalho Accept, o formato a
ser enviado é o JSONSiren.

Para implementar este formato de envio, teve-se de ter uma representação

personalizada para cada recurso, desenvolvida por nós, seguindo a especificação Siren
do documento no github “Siren: a hypermedia specification for representing entities” [].

Nos recursos manipulados, adicinou-se este formato de resposta, colocando no

cabeçalho Content-Type o tipo de media “application/vnd.siren+json”, para indicar ao
cliente que a resposta tem o formato JSONSiren.

10
É uma API do Java que descreve uma interface comum para frameworks de persistência de dados.
11
É uma API do Java que permite a ligação e interação com bases de dados.

41
De notar que foi adicionada uma propriedade required para indicar quais dos campos a
inserir ou atualizar, são obrigatórios ou opcionais, para a solicitação ter sucesso. Se
forem obrigatórios terão o valor true, caso contrário, false. Para exemplificar este
formato, na figura 28 está o exemplo de uma resposta à solicitação com método GET
./cell com o id 2.
{
"class": [
"cells"
],
"title": "Cell '2'",
"properties": {
"id": 2,
"state": "not available",
"min_temp": 10.5,
"max_temp": 25.5,
"length": 40.0,
"height": 25.0,
"width": 50.0,
"hive": {
"href": "http://localhost:8080/hives/1"
}
},
"actions": [
{
"name": "delete-cell2",
"title": "Delete Cell '2'",
"method": "DELETE",
"href": "http://localhost:8080/cells/2"
},
{
"name": "update-cell2",
"title": "Update Cell '2'",
"method": "PATCH",
"href": "http://localhost:8080/cells/2",
"type": "application/x-www-form-urlencoded",
"fields": [
{
"name": "min_temp",
"type": "number",
"required": "false"
},
{
"name": "max_temp",
"type": "number",
"required": "false"
},
{
"name": "state",
"type": "text",
"required": "false"
}
]
}
],
"links": [
{
"rel": [
"self"
],
"href": "http://localhost:8080/cells/2"
}
]
}
Figura 28 – Corpo de resposta a uma solicitação GET /cell pelo identificador.

Caso haja algum erro numa solicitação e o servidor tiver capacidade de manipular, o
corpo da resposta terá formato application/problem+json. A figura 29 exemplifica o
formato do corpo destas respostas.

42
{
"instance": "/costumers/login",
"detail": "Registered Costumer with email costumer11@example.com not found
",
"type": "about:blank",
"title": "Not Found",
"status": 404
}
Figura 29: Corpo de resposta de um erro.
Já o envio de notificações para a aplicação móvel é feito com o Firebase Cloud Messaging
(FCM). De modo a ser possível o servidor enviar notificações para a aplicação móvel, é
necessário o token referente ao dispositivo do cliente, e o token de autenticação do
servidor. O servidor obtém o token referente ao dispositivo do cliente no cabeçalho da
solicitação ao autenticar-se no sistema informático LockerHive. Já o token de
autenticação necessário para o servidor se autenticar na Firebase, é obtido na altura que
se criou e registou o projeto LockerHive no Firebase. Estando em posse de ambos os
tokens, a API do servidor pode agora fazer uma solicitação de autenticação à API do FCM,
com o token de autenticação do servidor no cabeçalho, e o token do dispositivo móvel
no corpo da solicitação, junto com a mensagem que se pretende enviar para o respetivo
dispositivo móvel. Ao ser validada a solicitação de autenticação do servidor, o FCM
reencaminha a mensagem para o dispositivo específico.

4.2.3 Processo de tratamento de solicitações

A framework Spring tem bastantes ferramentas para que se possa personalizar o
tratamento às solicitações vindas da API RESTful. Desde logo, tem interfaces que, ao
serem implementadas, permitem que haja o acesso à solicitação antes desta chegar aos
controladores, sendo possível assim otimizar algumas funcionalidades.

No nosso caso, temos uma classe que implementa a interface

HandlerMethodArgumentResolver, que permite adicionar um objeto, ao qual demos a
designação de RequestUrl, como parâmetro de cada controlador. Este objeto vai conter
o URL12 absoluto e relativo da solicitação, sendo assim possível otimizarmos o processo
de identificação da localização do recurso no formato de resposta JSONSiren.
Já para o encaminhamento da solicitação para o controlador certo, foi necessário
adicionar as anotações de @RestController e @RequestMapping. A anotação
RestController marca a classe como um controlador da API RESTful. A anotação
RequestMapping é usada para mapear o URI 13 base das solicitações, de modo a serem
reencaminhadas para o respetivo controlador que tem esse URI como base. Cada
controlador pode ter várias funções para mapear as solicitações de acordo o seu método
HTTP e URI, podendo assim executar a lógica apropriada para retornar a resposta
adequada à solicitação.

A API do servidor do sistema informático LockerHive disponibiliza o mapeamento para

os seguintes recursos:

 Criar, editar ou remover um utilizador registado ou não registado;

12
Uniform Resource Locator – é a localização de um recurso.
13
Uniform Resource Identifier – é a identificação de um recurso.

43
 Criar e eliminar loja registada;
 Fazer a autenticação de um cliente;
 Obter lista de todos os utilizadores;
 Obter informação de um utilizador em específico;
 Obter lista de todos os centros de distribuição;
 Obter informação de um centro de distribuição em específico;
 Criar ou remover centro de distribuição;
 Criar, editar ou remover bundle;
 Obter todos os bundle;
 Obter informação de um bundle em específico;
 Criar, editar ou remover pacote;
 Obter lista de todos os pacotes;
 Obter informação de um pacote em específico;
 Obter o token do pacote;
 Obter lista de todas as colmeias;
 Obter informação de uma colmeia em específico;
 Criar, editar ou remover colmeia;
 Obter lista de todas as células;
 Obter informação de uma célula em específico;
 Criar, editar ou remover célula;
 Obter lista de todas as notificações;
 Obter informação de uma notificação em específico;
 Editar, criar ou remover uma notificação;
 Obter lista de todas as transações;
 Obter informação de uma transação em específico;
 Editar, criar ou remover uma transação;
 Obter lista de todas as anomalias;
 Criar, editar ou remover uma anomalia;
 Obter informação de uma anomalia em específico;
 Obter todos os códigos de abertura da célula;
 Obter um código em específico;
 Criar um código;
 Obter lista de todos os operadores;
 Criar ou remover um operador;
 Obter a informação de um operador em específico;
 Criar etiqueta do pacote.

44
4.2.4 Segurança
De modo implementar o que se referiu nas medidas de segurança especificadas na
secção 3.9, utilizou-se cookies, a biblioteca JJWT (Java JWT) e a interface
WebMvcConfigurer do Spring.
Devido há necessidade de cada utilizador ter um cookie que o identifica, resolveu-se
utilizar tokens JWT. Este token é estruturado em 3 partes:

 Cabeçalho;
 Conjunto de reivindicações;
 Assinatura digital.
Na criação deste token, o identificador único e a role do cliente são adicionados ao
conjunto de reivindicações. Este token é assinado por uma chave secreta, gerada pela
biblioteca JJWT, que é alterada sempre que se volta a executar o servidor. É utilizado o
algoritmo HS256 que usa uma função de hash SHA-256 para gerar a chave secreta. O uso
desta chave permite não só, a garantia da integridade do token, verificando se este não
foi adulterado, mas também a garantia da autenticidade, não sendo possível ser
conhecido o conteúdo do token sem ser descodificado com a chave secreta.

Após o cliente se autenticar com sucesso, será adicionado aos cabeçalhos da resposta o
cookie com o token.

Com o obejtivo de restringir o acesso a recursos a apenas clientes com a respetiva

autorização, utilizou-se a abordagem de roles14. Cada cliente só poderá aceder a recursos
nos quais a sua role permita.

A distribuição de roles no sistema informático LockerHive foi feita na seguinte maneira:

 “ADMIN” – vai ser o cliente com identificador 1. Caso exista, terá sempre a role
de administrador, sempre que se autentique. Ao não se ter realizado uma
aplicação web para autenticar os administradores do sistema, foi decidido dar
esta role a apenas um cliente, para ser possível ter acesso a todas as rotas do
servidor do sistema informático LockerHive;
 “REGISTERED_COSTUMER” – qualquer cliente que possua conta registada no
sistema e a sua informação se encontre na tabela REGISTERED_COSTUMER na
base de dados. Ao realizar a autenticação no sistema informático LockerHive é-
lhe imposta esta role, ficando com permissão para aceder a rotas limitadas;
 “REGISTERED_STORE” – qualquer cliente que possua conta registada no sistema
e a sua informação se encontre na tabela REGISTERED_STORE na base dados. Ao
realizar a autenticação no sistema informático LockerHive é-lhe imposta esta
role, ficando com permissões limitadas para aceder a rotas limitadas.
A verificação destas roles dá-se nos controladores do servidor. Sendo que, antes de os
controladores saberem a role do cliente que fez a solicitação, a solicitação é intercetada.

14
Papel que desempenha o cliente identificado.

45
Nesse momento, é verificada qual a rota que o cliente pretende aceder. Se a rota
requerer autenticação, é verificado se o token e o seu conteúdo é válido (ao ser assinado
o token com a chave secreta do servidor). Caso seja válido, o identificador e a role do
cliente são obtidos do token e inseridos num atributo da solicitação, chegando assim ao
controlador da rota em forma de atributo, sendo depois verificados para se confirmar se
o cliente tem ou não a autorização para aceder ao recurso solicitado.
Com a necessidade de interação entre a API do servidor e a API da aplicação web que
simula uma loja online, foi essencial configurar a permissão para que se permita pedidos
cross-origin15. Para isso, teve-se de implementar numa classe a interface
WebMvcConfigurer, do Spring, que disponibiliza métodos para tal. Portanto, foi
adicionada a origem http://localhost:3000, como origem permitida a interagir com a API
do servidor.

4.3 Aplicação móvel

A aplicação móvel do sistema informático LockerHive, foi desenvolvida com uma
complexidade para um novo utilizador simples. Isto é, ter interfaces simples e diretas
que facilitam a interação e utilização das funcionalidades do sistema pelo utilizador.

Esta secção encontra-se dividida em subsecções, a subsecção 4.4.1 onde se encontra

descrita a organização e funcionamento geral da aplicação móvel LockerHive, e 4.4.2
onde estão descritos os detalhes da sua implementação.

Serão apresentados mocks de todos os ecrãs da aplicação móvel realizados na

ferramenta Figma [4].

4.3.1 Aspetos gerais da aplicação móvel

Na figura 30 encontra-se representado o fluxo de navegação entre cada um dos ecrãs da
aplicação móvel do sistema LockerHive.

Figura 30 - Diagrama de navegação da aplicação

Esta aplicação tem como objetivo principal ser a plataforma que fornece ao cliente do
sistema informático LockerHive as informações que necessita para usufruir do sistema,

15
Mecanismo que permite recursos restritos numa aplicação serem acedidos por outro domínio fora do
domínio dessa aplicação.

46
como tokens de acesso, estado de pacotes, etc. O acesso a estas informações está
dependente da autenticação do cliente, tendo esta aplicação interfaces que o permitem
fazer (figura 31).

Figura 31 – Mocks de ecrã de login e sign-up

Após a criação de conta e/ou autenticação do cliente será apresentado o menu principal
(representado na figura 32), que possui vários botões que o permite navegar para
diferentes ecrãs e realizar diferentes operações ou consultar informações:

 Pacotes Ativos: apresenta ao utilizador uma listagem dos pacotes que se

encontram ativos, ou seja, pacotes do cliente registados no sistema que ainda
não foram recolhidos pelo cliente (figura 33);
 Mapa Colmeias: expõe ao cliente o mapa de todas as colmeias do serviço, sendo
feita a distinção entre associadas, ativas e inativas. Neste ecrã poderá associar,
ou desassociar uma determinada colmeia ao seu perfil, tornando-a assim
disponível ou indisponível para ser escolhida no momento de seleção do local de
entrega (figura 34);
 Pagamentos Pendentes: ecrã que terá uma listagem dos pagamentos que tem
por efetuar, que impedirão a sua encomenda de ser recolhida, já que a realização
deste pagamento é condição obrigatória para o token de abertura da célula ser
fornecido (figura 35);
 FAQ: ecrã que esclarecerá algumas questões frequentes que o utilizador poderá
ter em relação à utilização do serviço.

47
Figura 32: Mock do menu principal Figura 33: Mock do menu de pacotes ativos

Figura 34: Mock do ecrã do mapa Figura 35: Mock de pagamentos pendentes

48
Existe também um botão de saldo nos vários ecrãs que, para além de informar o cliente
do seu saldo atual, ao clicar permite realizar a simulação de depósito. Nas notificações,
existe um icon que indica o número de notificações que o cliente possui, que ao clicar,
as apresenta como uma lista, aparecendo as por ler e as já marcadas como lidas.
A aplicação possui ainda um botão de dropdown, onde o cliente terá acesso a outros
ecrãs e funcionalidades tais como:

 Perfil: ecrã onde poderá consultar o seu email e alterar a sua password;
 Histórico de transações: lista de depósitos e pagamentos efetuados;
 Histórico de pacotes entregues: ecrã que lista os pacotes entregues e
recolhidos pelo cliente e informações associadas;
 Anomalias: lista de anomalias reportadas pelo utilizador e os seus dados;
 Logout.

4.3.2 Detalhes de implementação

Esta aplicação foi desenvolvida no sistema operativo Android, sendo utilizada a
linguagem de programação Kotlin, utilizada em conjunto com o toolkit Jetpack Compose.

Com o Jetpack Compose, foi possivel desenvolver a aplicação utilizando o modelo MVVM
(Model-View-ViewModel), que consiste na atualização do interface utilizador através da
observação de alterações de estado no ViewModel desencadeadas pelo Model. Esta
alteração da interface do utilizador, é feita também no momento de receção de
notificações por parte do servidor através do serviço Firebase Cloud Messaging, sendo
as alterações feitas em tempo real, mesmo com a aplicação em funcionamento.
A aplicação móvel no total tem três classes Activity, onde estão os elementos de
interface do utilizador
Os mapas expostos foram obtidos através da API Maps SDK para Android, juntamente
com o suporte fornecido pelo toolkit Compose que simplifica a sua representação.
Para as solicitações à API do servidor, foi usado o framework assíncrono Ktor. Sendo
assim possível assim configurar uma solicitação HTTP. Como requisito para a realização
de cada solicitação HTTP, como a chamada de uma função Ktor é assíncrona, utilizou-se
corrotinas para chamar fazer a respetiva chamada, de modo a não bloquear a thread
principal enquanto a operação de configurar a solicitação e de enviá-la é realizada.
De modo ao utilizador conseguir navegar na aplicação móvel, é necessário que contenha
o cookie de autenticação consigo, gerado no servidor, e que lhe foi entregue no
momento da autenticação. Isto é necessário devido à realização de solicitações por parte
da aplicação móvel, após a autenticação, para a API do servidor, com vista a obter as
informações do utilizador.
Com o objetivo de guardar a informação do cookie de autenticação e adicionar a
possibilidade de o utilizador guardar os dados de acesso para não ser necessário realizar

49
sempre a autenticação, utilizou-se sharedPreferences, que possibilita o armazenamento
local de dados no aplicativo Android. Assim, consegue-se guardar o token do cookie e os
dados de acesso do cliente para ser utilizados durante a navegação da aplicação móvel
na realização de solicitação à API do servidor.

4.4 Loja online com parceria LockerHive

A simulação da aplicação web da loja online com parceria, foi desenvolvida com a
biblioteca React na linguagem de programação JavaScript e executada em Node.js.
Esta aplicação web apenas simula o processo de escolha de serviços de entrega de
encomendas e da seleção da colmeia do sistema informático LockerHive num mapa. Este
processo vai ser diferente consoante o utilizador for registado no sistema informático
LockerHive ou não.
As solicitações à API do servidor são realizadas com a função fetch, pertencente ao
JavaScript. Como já referido na secção 4.2.4, só é possível enviar solicitações à API do
servidor provenientes do exterior se a origem for conhecida, portanto a API da aplicação
da loja encontra-se numa das origens reconhecidas pelo servidor como permitida.
A simulação da loja funciona na seguinte maneira:
1. Cliente escolhe o tipo de serviço de entrega de encomenda que pretende;
2. Ao escolher o sistema informático LockerHive, é-lhe perguntado se tem ou não
conta registada no sistema;
3. Caso tenha conta, terá de introduzir os dados para se autenticar no sistema
informático LockerHive. Caso não tenha, é pedido na mesma forma dados como
email, nome e contacto, sendo enviados os dados para a API do servidor
LockerHive. Em ambos os casos, é enviado antes uma solicitação de autenticação
da loja. Caso a loja não se autentique, não ocorre o envio dos dados do cliente
para a API do servidor.
4. Caso as solicitações e respostas sejam válidas, é enviado um pedido de obtenção
da lista de todas as colmeias disponíveis e a respetiva informação de cada uma à
API do servidor, para serem colocados os marcadores no mapa, na localização
das mesmas.
5. O cliente consegue então selecionar no mapa a colmeia onde pretende que lhe
seja entregue a encomenda, sendo enviada esta informação à API do servidor
que responde com as informações a serem inseridas na etiqueta da encomenda
(figura 35), para que quando chegar ao centro de distribuição LockerHive, seja
possível saber, de que cliente é, e qual o destino da mesma.
6. No caso do cliente autenticado, é recebida uma notificação na aplicação móvel
que confirma que houve uma compra numa loja online com parceria LockerHive,
com uso do sistema informático LockerHive.

50
{
"class": [
"labels"
],
"properties": {
"name": "joao silva LQLDTQD",
"address": "Bairro Exemplo 3",
"postal_code": "1234-565",
"location": "Gaia",
"district": "Porto"
}
}
Figura 37: Corpo de resposta da API do servidor para a loja após confirmação de
compra da encomenda.

51
5 Conclusões, Experiência e Trabalho
Futuro
Atualmente, o sistema informático LockerHive, apresenta as funcionalidades
implementadas, referidas na secção relativa ao enquadramento deste sistema (secção
1.2), com exceção da possibilidade de se adiar a entrega da encomenda para um cacifo.
Na altura de análise do projeto também foram abordadas outras possíveis
funcionalidades, que seriam interessantes e acrescentariam valor ao sistema, mas,
tendo em atenção o reduzido período para a realização do projeto, não nos foi possível
implementá-las, por serem dado prioridades a algumas a que foram consideradas mais
importantes, ou por questões de tempo, nomeadamente:

 Loja online com parceria LockerHive poder arrendar colmeias para uso próprio;
 Loja online com parceria LockerHive ter a possibilidade fazer a própria gestão da
colmeia e das células;
 Pacote proveniente da loja online com parceria LockerHive ter a descrição do
que contém, permitindo ao cliente saber qual o conteúdo do pacote desde que
foi registado no sistema;
 Possibilidade de alterar o destino da encomenda para uma morada introduzida
pelo cliente;
 Rotinas de manutenção mês a mês para limpar os dados em excesso que não
têm uso, como por exemplo, o conjunto de caracteres aleatórios gerados para
associar um cliente não registado a uma colmeia.
 Possibilidade de o operador ter uma interface própria para poder ir atualizando
o estado dos pacotes que transporta;
 Possibilidade de os administradores do sistema terem a respetiva aplicação
web, para fazerem a gestão do mesmo;
 Possibilidade da loja online com parceria se autenticar numa aplicação web do
sistema, para fazer a respetiva gestão das colmeias que arrendou;
 Possibilidade de o cliente poder reservar células por um limite de tempo, por
um custo monetário adicional;
 Possibilidade de os pacotes serem entregues diretamente nas colmeias
arrendadas pela loja online, não tendo de passar pelo centro de distribuição do
sistema;

Em certas funcionalidades implementadas também faltou potencializar o seu valor ao

máximo, o que traria, naturalmente, uma melhoria da experiência para o cliente, como:
 Possibilidade de avisar o cliente que a data de recolha permitida para o(s)
pacote(s) está a terminar;
 Possibilidade de se alterar a colmeia de destino de cada pacote não só quando o
pacote se encontrar no centro de distribuição;
 Quando se cria conta ou quando o cliente não registado insere o email e contacto
na loja online com parceria LockerHive, haja um email ou SMS para o mesmo

52
 com um código de confirmação, certificando que confirma que o email e
contacto introduzidos são realmente do cliente;
 Quando o pacote não é recolhido dentro do prazo estipulado, enviar ao cliente
uma notificação para que este decida se pretende que o pacote se mantenha
armazenado por mais tempo, por um custo monetário adicional;

 Quando o pacote é retorna para o centro distribuição, após ter terminado o

tempo máximo de armazenamento na célula, o cliente ter a possibilidade de
poder escolher um novo destino do pacote;
 Os dados de autenticação LockerHive inseridos na loja online com parceria, não
serem irem para a aplicação web da loja online, mas sim para uma interface
especifica de autenticação segura.
 Possibilidade por um custo monetário acrescido, o ou os pacotes do cliente
terem prioridade sobre outros para serem transportados para a colmeia;
 Possibilidade de o operador apenar transportar pacotes com caraterísticas
especiais, como, por exemplo, necessidade de refrigeração.

 Possibilidade de, caso a sequência de caracteres do pacote não seja reconhecida

pelo sistema LockerHive, associar o respetivo pacote, a informação na etiqueta
do contacto do cliente, se esta estiver referida;

O número de testes realizados ao sistema informático LockerHive deveria ter sido maior,
de forma a garantir que todo o processo foi bem desenvolvido, despistando erros que
eventualmente ainda possam ocorrer, corrigindo-os.

A realização do projeto LockerHive permitiu-nos ter uma perspetiva diferente da análise

e estudo do desenvolvimento de um projeto. Esta foi a nossa primeira abordagem real
ao desenvolvimento de um projeto com todas as suas vertentes.

A execução das diferentes etapas que foram planificadas no início do projeto,

permitiram-nos conhecer e ultrapassar algumas das adversidades inerentes ao
desenvolvimento de um projeto desta envergadura, o que nos deu mais experiência,
consistência e confiança para novos desafios.
Em suma, ficámos satisfeitos por realmente compreender o que envolve o
desenvolvimento de um projeto, bem como da importância dos conteúdos apreendidos
nas unidades curriculares do programa de estudos do ISEL, para a execução do mesmo.
Portanto, o nosso reconhecimento, em primeiro lugar ao ISEL, por nos facultar uma
grande preparação para o mercado de trabalho, oferecendo-nos assim, várias opções de
escolha a nível profissional.
Em segundo lugar, queremos agradecer aos nossos orientadores, Professor Luís Osório
e Professor Mário Pinheiro, por nos terem orientado e aconselhado na realização de um
projeto.
Em terceiro lugar, também queremos exprimir o nosso agradecimento ao docente da
unidade curricular, Projeto e Seminário, Professor Fernando Sousa, por fornecer as
ferramentas para clarificar o que é realmente um projeto e como se desenvolve o seu
53
relatório, e também pela dinamização de seminários interessantes, sobre as perspetivas
profissionais dos alunos e o mercado de trabalho, com a participação de representantes
de empresas e professores.

54
Referências
[1] SysML, 2022 - https://www.omg.org/spec/SysML/1.7/Beta1/PDF
[2] Fundamentals Of Database Systems, de Shamkant B. Navathe e Ramez Elmasri, 2016
[3] Representational State Transfer (REST) :
https://roy.gbiv.com/pubs/dissertation/rest_arch_style.htm
[4] Figma - https://www.figma.com/
[5] https://ec.europa.eu/eurostat/statistics-explained/index.php?title=E-
commerce_statistics_for_individuals (Eurostat, 2022)

[6] https://blog.made2web.com/a-importancia-de-uma-loja-online-inclui-estatisticas-de-2020

[7] Mercado online português vale 7.130 milhões de euros em 2023 e 9.300 milhões de euros
em 2025 (https://observador.pt/2023/05/23/mercado-online-portugues-vale-7-130-milhoes-
de-euros-em-2023-e-9-300-milhoes-de-euros-em-2025/)
[8] https://www.publico.pt/2022/05/18/p3/noticia/novos-cacifos-locky-querem-encomendas-
espera-cliente-2006626

[9] https://www.inpost.pt/

Artigos:
Mais de 60% dos portugueses faz compras online – (DN, 2021)

Sete em cada dez pessoas em Portugal faz compras online várias vezes por mês –
(jornaleconomico, 2022)

Noticias:
Mais de 60% dos portugueses faz compras online – (DN, 2021)

Sete em cada dez pessoas em Portugal faz compras online várias vezes por mês –
(jornaleconomico, 2022)

https://ec.europa.eu/eurostat/statistics-explained/index.php?title=E-
commerce_statistics_for_individuals (Eurostat, 2022)

https://observador.pt/2023/05/23/mercado-online-portugues-vale-7-130-milhoes-de-euros-
em-2023-e-9-300-milhoes-de-euros-em-2025/ (observador, 2023)

https://github.com/kevinswiber/siren JSON SIREN

https://jornaleconomico.pt/noticias/ctt-dizem-que-numero-de-encomendas-nos-novos-
cacifos-tem-aumentado-de-forma-recorrente-922681/

https://www.pgadmin.org/

https://github.com/kevinswiber/siren

55
https://nodejs.org/en

https://inpost.pl/en

56