thesis: improve connection/overall flow for sections/subsections
Pedro Lucas Porcellis porcellis@eletrotupi.com · 1 month ago
485f02189668c0fdb711c8593614af2e32d6da49 Browse filesParents
fef6b4aChanged files
3
Additions
+75
Deletions
-5
monografia/chapters/modeling.tex
1 1
\chapter{Modelagem}
2 2
3 3
De acordo com \cite{guedes:2022}, a modelagem de sistemas é uma etapa fundamental do
4 4
processo de desenvolvimento de software, pois permite representar graficamente
5 5
os principais elementos do sistema, seus comportamentos e interações. Essa
106 106
atributos''. Dessa forma, esse diagrama constitui a base da modelagem
107 107
estrutural que posteriormente será implementada em código.
108 108
109 109
Sobre o diagrama em si, cada classe possui três partes: título, os atributos,
110 110
que representam as características da classe em si, e seus métodos, que são as
111 -
operações que o sistema pode operar nos objetos das classes \cite{ibm:2021}. Na
111 +
operações que o sistema pode operar nos objetos das classes \cite{guedes:2022}. Na
112 112
Figura 2, pode-se observar os elementos descritos acima:
113 113
114 114
\begin{figure}[h]
115 115
\centering
116 116
\caption{Diagrama de Classes}
150 150
garantir uma separação adequada de responsabilidades e facilitar a manutenção e
151 151
escalabilidade do código, conforme as propostas de \citet{Fowler_2013} e
152 152
\citet{Gamma:2011}. Esses elementos são importantes, considerando os princípios
153 153
de legibilidade, simplicidade e responsabilidades, muitos organizados por
154 154
\citet{Martin_2012}, asseguram que o código produzido seja limpo e sustentável.
monografia/chapters/tech.tex
1 1
\chapter{Tecnologias}
2 2
3 3
Este capítulo apresenta as principais tecnologias empregadas no desenvolvimento
4 -
do aplicativo, organizadas de acordo com a camada da arquitetura em que
5 -
atuam: front-end, back-end e infraestrutura/persistência de dados.
4 +
do aplicativo, organizadas de acordo com a camada da arquitetura em que atuam:
5 +
\textit{front-end}, \textit{back-end} e infraestrutura/persistência de dados.
6 6
7 7
\section{Front-end}
8 +
9 +
O termo \textit{frontend} refere-se à camada de um sistema responsável pela
10 +
interação direta com o usuário: a interface visual, a lógica de apresentação e
11 +
o processamento que ocorre no dispositivo do próprio usuário, seja um navegador
12 +
ou, como no caso do Nexo, um aplicativo móvel, conforme
13 +
~\citet{sommerville:2010}. É o frontend que renderiza telas, captura entradas
14 +
do usuário (como toques e formulários) e comunica-se com o \texit{backend}
15 +
através de requisições de rede, geralmente utilizando APIs. No caso do Nexo,
16 +
essa camada é implementada com \textit{React Native} e Expo, permitindo que a
17 +
mesma base de código seja compilada tanto para Android utilizando bibliotecas
18 +
em \textit{TypeScript}.
8 19
9 20
\subsection{React Native}
10 21
11 22
React Native é um \textit{framework} de código aberto, mantido pela Meta, que
12 23
permite o desenvolvimento de aplicativos móveis multiplataforma a partir de
34 45
projeto de escopo individual em que a complexidade adicional de soluções
35 46
mais robustas de gerenciamento de estado não se justifica.
36 47
37 48
\section{Back-end}
38 49
50 +
Já o termo \textit{backend} refere-se à camada de um sistema que processa a
51 +
lógica de negócio, gerencia o acesso e a persistência de dados, e expõe essa
52 +
funcionalidade a clientes (como o frontend) através de uma interface bem
53 +
definida, tipicamente uma API HTTP \cite{Fowler_2013}. O \textit{backend} é
54 +
responsável por validar dados recebidos, aplicar regras de negócio, autenticar
55 +
usuários, e coordenar o acesso ao banco de dados e a outros serviços
56 +
auxiliares. No caso do Nexo, essa camada é implementada em Node.js com o
57 +
framework \textit{Express}, seguindo uma arquitetura em camadas (\textit{Route}
58 +
$\rightarrow$ \textit{Controller} $\rightarrow$ \textit{Service} $\rightarrow$
59 +
Prisma) que separa as responsabilidades de validação, lógica de negócio e
60 +
acesso a dados.
61 +
39 62
\subsection{Express.js}
40 63
41 64
Express.js é um \textit{framework} minimalista para aplicações web em
42 65
Node.js, amplamente utilizado para a construção de APIs \textit{REST},
43 66
oferecendo uma camada fina de abstração sobre o roteamento de requisições HTTP e
80 103
mantém compatibilidade total de protocolo, permanecendo sob licença
81 104
permissiva de código aberto.
82 105
83 106
\section{Infraestrutura e Persistência de Dados}
84 107
108 +
A camada de \textit{infraestrutura e persistência} de um sistema abrange os
109 +
componentes responsáveis por armazenar e gerenciar os dados de forma durável,
110 +
bem como os serviços auxiliares que sustentam o funcionamento da aplicação em
111 +
produção \cite{Fowler_2013}. O elemento central dessa camada costuma ser o
112 +
sistema de gerenciamento de banco de dados (SGBD), responsável por garantir a
113 +
integridade, consistência e durabilidade dos dados armazenados. No caso do
114 +
Nexo, essa função é cumprida pelo PostgreSQL, um SGBD relacional, acessado
115 +
através do Prisma, um \textit{Object-Relational Mapper} (ORM) que traduz
116 +
operações do banco de dados em chamadas de código TypeScript, eliminando a
117 +
necessidade de escrever consultas SQL manualmente na maior parte dos casos.
118 +
119 +
Complementarmente, o Nexo utiliza o Valkey como armazenamento em memória de
120 +
alta velocidade, empregado tanto para cache quanto como \textit{broker} de
121 +
mensagens para o sistema de filas, cujo suas filas são gerenciadas com a
122 +
biblioteca BullMQ para lidar com os \textit{background jobs} enviados. Os
123 +
mesmos são responsáveis por processar os indicadores semanais e diários
124 +
descritos nos capítulos anteriores.
125 +
85 126
\subsection{PostgreSQL}
86 127
87 128
PostgreSQL é um sistema gerenciador de banco de dados relacional, de código
88 129
aberto, reconhecido por sua conformidade com o padrão SQL, robustez e suporte
89 130
a tipos de dados avançados \citep{postgresql:2026}.
107 148
pelo back-end, além de prover checagem de tipos em tempo de compilação para
108 149
as consultas realizadas.
109 150
110 151
\section{Implantação e Automação}
111 152
153 +
Já os termos \textit{implantação} (\textit{deployment}) e
154 +
\textit{automatização} referem-se ao conjunto de práticas e ferramentas
155 +
utilizadas para transformar o código-fonte de uma aplicação em um sistema
156 +
efetivamente disponível e em execução, de forma repetível e com o mínimo de
157 +
intervenção manual \cite{Humble_Farley_2011}. No caso do Nexo, essa camada é
158 +
sustentada por três ferramentas complementares. O Docker é utilizado para
159 +
empacotar a aplicação e suas dependências em contêineres isolados e portáveis,
160 +
garantindo que o ambiente de execução seja idêntico entre desenvolvimento e
161 +
produção; o Docker Compose orquestra a execução conjunta de múltiplos
162 +
contêineres (aplicação, banco de dados, Valkey), definindo suas configurações e
163 +
interdependências em um único arquivo declarativo. O GitHub Actions é
164 +
responsável pela integração e entrega contínuas (CI/CD), automatizando
165 +
etapas como execução de testes e construção de imagens a cada alteração no
166 +
código. Por fim, o Ansible é utilizado para o provisionamento inicial da
167 +
infraestrutura, automatizando a configuração do servidor onde a aplicação é
168 +
hospedada.
169 +
112 170
\subsection{Docker e Docker Compose}
113 171
114 172
Docker é uma plataforma de conteinerização que permite empacotar uma
115 173
aplicação e suas dependências em uma unidade isolada e portátil, capaz de ser
116 174
executada de forma consistente em diferentes ambientes \citep{docker:2026}. O
117 175
Docker Compose é uma ferramenta complementar que permite definir e orquestrar
118 176
múltiplos contêineres -- e as relações entre eles -- por meio de um único
119 177
arquivo de configuração declarativo \citep{dockercompose:2026}.
120 -
121 178
122 179
No projeto, o Docker Compose é utilizado tanto no ambiente de desenvolvimento
123 180
quanto no ambiente de produção para orquestrar os serviços de banco de dados
124 181
(PostgreSQL), armazenamento em memória (Valkey) e da própria API, garantindo
125 182
que as versões e configurações desses serviços sejam idênticas entre as
130 187
que a API só seja iniciada após o banco de dados e o Valkey estarem de
131 188
fato prontos para aceitar conexões, evitando falhas de inicialização
132 189
por condição de corrida (\textit{race condition}), como ilustrado no
133 190
Código~\ref{lst:healthcheck-compose}.
134 191
135 -
\begin{lstlisting}[caption={Configuração dUndefined referencee \textit{healthcheck} do Valkey e de dependência condicional da API no \texttt{docker-compose.yml}}, label={lst:healthcheck-compose}]
192 +
\begin{lstlisting}[caption={Configuração do \textit{healthcheck} do Valkey e de dependência condicional da API no \texttt{docker-compose.yml}}, label={lst:healthcheck-compose}]
136 193
valkey:
137 194
image: valkey/valkey:9.0-alpine
138 195
healthcheck:
139 196
test: ["CMD", "valkey-cli", "ping"]
140 197
interval: 10s
227 284
ao documentar e automatizar o processo de provisionamento, o projeto
228 285
favorece um modelo mais alinhado aos princípios de privacidade e de
229 286
autonomia sobre os dados dos usuários, permitindo que instituições ou
230 287
indivíduos preocupados com a confidencialidade de dados sensíveis de
231 288
saúde mental hospedem e controlem sua própria instância da aplicação.
monografia/monografia.bib
1 1
@article{Iwaya:22,
2 2
title={On the privacy of mental health apps},
3 3
volume={28},
4 4
DOI={10.1007/s10664-022-10236-0},
5 5
number={1},
455 455
number={RFC 4180},
456 456
institution={Internet Engineering Task Force},
457 457
author={Shafranovich, Y.},
458 458
year={2005},
459 459
month=oct
460 +
},
461 +
462 +
@book{
463 +
Humble_Farley_2011,
464 +
address={Upper Saddle River, NJ},
465 +
edition={7th printing 2013},
466 +
series={A Martin Fowler Signature Book},
467 +
title={Continuous delivery: reliable software releases through build, test, and deployment automation},
468 +
ISBN={9780321601919},
469 +
publisher={Addison-Wesley},
470 +
author={Humble, Jez and Farley, David G.},
471 +
year={2011},
472 +
collection={A Martin Fowler Signature Book}
460 473
}