\chapter{Nexo}

aplicação para dispositivos móveis, de forma a preencher essas lacunas

demonstradas tanto pelo questionário, quanto também tentando preencher as

questões analisadas em outros sistemas similares. Como mencionado

anteriormente, o sistema é direcionado para pessoas com TAB, embora, ele também

possa atuar isoladamente como um aplicativo de registro de humor, e portanto, o

garantir uma separação adequada de responsabilidades e facilitar a manutenção e

escalabilidade do código, conforme as propostas de \citet{Fowler_2013} e

\citet{Gamma:2011}. Esses elementos são importantes, considerando os princípios

de legibilidade, simplicidade e responsabilidades, muitos organizados por

\citet{Martin_2012}, asseguram que o código produzido seja limpo e sustentável.

\chapter{Arquitetura e Elementos do Sistema}

Como delineado as tecnologias no capítulo anterior, aqui se apresenta a

arquitetura, demonstrando como todas as tecnologias apresentadas acima se

conectam e conversam entre si.

através de uma plataforma de terceiro, como Google ou Facebook.

Isso se dá, em especial, por dois motivos. Primeiro, o uso de uma tecnologia de

autenticação, como por exemplo, \textit{OAuth} \cite{Hardt:2012} exigiria uma

conexão com plataformas de terceiro, que poderiam então rastrear quais usuários

sobre os mecanismos usados por tais plataformas para rastrear e monitorar o

acesso a dados de usuários, com o fim de vender e monetizar essas informações.

Essa preocupação não é hipotética: um estudo que interceptou o tráfego de rede

de 36 dos aplicativos mais populares de saúde mental (depressão e cessação de

tabagismo) encontrou transmissão de dados a pelo menos um terceiro em 92\%

deles, sendo que 81\% enviavam dados especificamente a serviços operados por

compartilhamento em política de privacidade \cite{Huckvale2019}.

Um estudo posterior, focado exclusivamente em 27 aplicativos de saúde

mental mais populares da Google Play Store, confirmou o mesmo padrão e

o caracterizou formalmente como uma ameaça:

  \cite[p.~3, tradução nossa]{Iwaya:22}

\end{quote}

Como os próprios autores resumem, a mera vinculação de um usuário a um

aplicativo de saúde mental já pode revelar que essa pessoa possui uma condição

particularmente vulneráveis a esse tipo de exposição \cite{Iwaya:22}.

No caso do Nexo, essa cadeia de inferência é especialmente

sensível: a presença do aplicativo na lista de apps instalados de um usuário,

associada ao seu identificador publicitário, permitiria a uma plataforma como a

\label{fig:screenshot-consulta-humor}

\includegraphics[width=0.70\textwidth,height=0.60\textheight,keepaspectratio]{screenshot-create-mood.jpeg}

\source{Elaborado pelo autor (2026)}

\end{figure}

aplicativo procura deixar claro, é importante que seja um momento

reflexivo, não necessariamente preciso.

O usuário pode adicionar uma anotação sobre aquele registro em

específico, padrão que se repete em outras telas do aplicativo.

\source{Elaborado pelo autor (2026)}

\end{figure}

Ao concluir esse processo e salvar, é apresentada ao usuário uma tela

de confirmação, na qual ele pode, opcionalmente, vincular o registro a

EMA, enriquecendo o registro de humor com mais contexto sobre o que

aconteceu.

\begin{figure}[H]

\centering

Por fim, vale mencionar que, após esse processo, é enfileirado

internamente um \textit{background job} que recalcula, sob demanda, o

indicador de energia daquele dia, apresentado na figura

\ref{fig:screenshot-consulta-registros}. Diferentemente deste, os

registro individual, sendo processados apenas pelo job semanal

agendado (seção \ref{sec:insights}).

\section{Indicadores}\label{sec:insights}

Nessa tela é apresentado um conjunto de indicadores construídos a partir

dos registros de humor, sono e gatilho do usuário. Diferente das demais

telas do aplicativo, que operam sobre dados em tempo real, os indicadores

são artefatos pré-computados: um \textit{worker} assíncrono (\textit{BullMQ})

percorre semanalmente todos os usuários ativos e enfileira, para cada

processam a janela dos últimos sete dias e persistem o resultado em uma

tabela dedicada. Vale notar que nem todos os indicadores seguem esse

fluxo agendado: os indicadores diários (energia e sono) são recalculados

sob demanda, no momento em que o usuário registra um novo humor ou

sessão de sono, enquanto os indicadores semanais dependem

    como melhora, piora ou estabilidade a partir de uma margem de $\pm10\%$.

    \item \textbf{Correlação entre sono e energia}: relaciona a duração

    do sono de uma noite com o nível de energia relatado na manhã

    seguinte, através do coeficiente de correlação de Pearson. Exige um

    o indicador simplesmente não é exibido.

    \item \textbf{Padrão de gatilhos}: identifica a categoria de gatilho

    mais frequente na semana e expressa sua predominância como percentual

    do total de registros.

suficientes de ambos os tipos. Optou-se por não exibir uma correlação

calculada com poucos pontos, preferindo comunicar a ausência de dado a

apresentar um número pouco confiável.

O bloco maior no topo da tela, o ``Resumo Semanal'', condensa os

humor (``Estável'', no exemplo). Esse rótulo, no entanto, é o elemento

mais delicado de toda a funcionalidade. Embora exista uma fórmula capaz

de produzir uma classificação de estabilidade a partir da variância dos

especialmente em um aplicativo que é utilizado por pessoas com

Transtorno Afetivo Bipolar, para quem uma leitura equivocada de

exige um embasamento mais cuidadoso do que uma regra estatística

simples. Por esse motivo, o rótulo apresentado nesta versão do

aplicativo é estático (não deriva de fato do cálculo de estabilidade) e

a funcionalidade pode ser inteiramente desabilitada pelo usuário nas

configurações. A decisão de manter ou não uma afirmação automatizada

para exibição, conforme visto na figura \ref{fig:screenshot-history}, nos

cabeçalhos ``terça-feira, 14 de julho'' e ``segunda-feira, 13 de julho''.

Essa unificação é proposital: ao invés de apresentar quatro telas

separadas por tipo de dado, o histórico busca reconstruir uma narrativa

única do dia do usuário, aproximando-se do princípio de \textit{Ecological

registro de humor (por exemplo, o gatilho ``Interno'' registrado três

minutos antes, na mesma figura) fica visualmente próximo do evento que

possivelmente o motivou.

A propriedade \texttt{raw} armazena o dado original, permitindo que a

registro de humor, destaca a dimensão mais relevante daquele registro

(como ``Ansiedade alta'' na figura \ref{fig:screenshot-history}); para um

gatilho, indica sua categoria, e assim por diante.

\FloatBarrier

\chapter{Metodologias}

\label{chapter:methodologies}

Como primeiro passo, para conseguir viabilizar construir um \textit{software}

com qualidade, é necessário adotar metodologias que fundamentam a ideia e o

destaque para os modelos de desenvolvimento de \textit{software} sequenciais e

incrementais que moldam boa parte das práticas de engenharia de

\textit{software} nas últimas décadas.

O modelo em cascata (\textit{waterfall}) é um modelo sequencial, dos mais

concluídas antes da próxima etapa começar. Embora forneça uma estrutura rígida

e lógica, é frequentemente criticado pela baixa adaptabilidade em relação às

mudanças durante o processo de desenvolvimento.

Em outro âmbito, o modelo incremental, trabalha com a premissa de que um

burocráticos e em um projeto com um escopo de equipe reduzida e onde necessita

um nível de flexibilidade maior, como este, portanto, uma adoção de uma

metodologia mais flexível se faz necessária.

Pressman, comenta que, por meados de 2001, um grupo de desenvolvedores

desenvolvimento, destacando a satisfação dos patrocinadores do sistema,

entregas mais rápidas, flexibilidade durante o desenvolvimento do

\textit{software} de forma a evitar que os desenvolvedores ficassem empacados e

reduzissem rigidez. Os principais destaques da abordagem ágil é a proposta de

que a mesma não é escrita em pedra, ou seja, permite flexibilidade no como

resultado relevante: 53\% dos participantes afirmaram já ter, em algum momento

da vida, realizado algum tipo de monitoramento de humor.

Em outros horizontes, mais da metade dos participantes expressou interesse em

acompanhar como o humor varia ao longo do tempo, muitas vezes com sugestões

Tal observação reforça a receptividade dos participantes em relação à ideia de

detecção de padrões emocionais, sugerindo que esse tipo de funcionalidade

representa um diferencial positivo frente aos aplicativos existentes.

É notável que os participantes demonstram uma preocupação recorrente com a

realizar uma revisão crítica-reflexiva, analisando os aplicativos que oferecem

algum tipo de diário digital de humor, ou permite algum acompanhamento

reflexivo de variações de emoções.

Para realizar esse processo, de forma a simular também um usuário, foi

https://play.google.com}, por \textit{mood tracker}, retornando centenas de

resultados. Nesse quesito, estabeleceu os seguintes critérios objetivos: (1)

pode ser um aplicativo em português ou inglês; (2) o aplicativo tem que

apresentar algum tipo de gráfico das entradas feitas (3) tem que possuir

entrada textual.

disponíveis atualmente, possuindo como principal característica a simplicidade

de uso. Nota-se que  possui uma linguagem bem lúdica e informal, por exemplo, o

sistema utiliza o conceito de ``feijões'' representando o estado de humor do

usuário. Destaca-se que o aplicativo permite selecionar categorias de

sentimentos e adicionar atividades para preencher melhor o registro do estado

bastante vasta opções de categorias, cada qual com uma ilustração que

informações. Um elemento interssante é que as informações adicionadas também

podem ser \textit{offlines}, até uma certa quantidade de entradas/registros,

necessitando de uma conta para poder continuar salvando os dados informados.

\begin{figure}[H]

grande maioria, são sistemas comerciais. A maior parte dos sistemas também

oferecem algum aspecto de pagamento, bloqueando funcionalidades importantes

atrás de algum tipo de modelo de subscrição. Existe também o fato de

personalização e de exportação de dados, que poucos ou nenhum sistema oferece,

o que faz com que o sistema não tenha portabilidade dos dados inseridos,

fazer com que o usuário não consiga migrar entre sistemas, prendendo-o a usar

aquela aplicação já que seus dados estão lá.

\subsection{Relação entre os dados do questionário e análise de similares}

atenda a essas demandas, mas também adote princípios de transparência, abertura

e controle por parte do usuário. A seguir, serão discutidas as decisões de

projeto que nortearam a construção da ferramenta proposta, baseadas tanto nas

limitações identificadas nos sistemas existentes quanto nas necessidades e

expectativas manifestadas pelo público-alvo da pesquisa.

\chapter{Tecnologias}

Este capítulo apresenta as principais tecnologias empregadas no desenvolvimento

do aplicativo, organizadas de acordo com a camada da arquitetura em que atuam:

\textit{front-end}, \textit{back-end} e infraestrutura/persistência de dados.

Aqui, é possível observar alguns elementos, como a extração direta dos

\textit{enums} mapeados pelo Prisma, citado anteriormente nas linhas 1--5. Em

seguida, são criados os \textit{schemas} de validação: um valida os componentes

de humor de forma aninhada dentro do objeto recebido, e o outro valida os dados

conversão do campo \texttt{moment} para um objeto de data a partir da entrada

recebida; a exigência de ao menos um componente de humor selecionado; entre

outros. Por fim, esses dados são exportados como um \textit{type} do

TypeScript, usado pelo compilador para a verificação estática de tipos no

restante do back-end.

Docker é uma plataforma de conteinerização que permite empacotar uma

aplicação e suas dependências em uma unidade isolada e portátil, capaz de ser

executada de forma consistente em diferentes ambientes \citep{docker:2026}. O

Docker Compose é uma ferramenta complementar que permite definir e orquestrar

arquivo de configuração declarativo \citep{dockercompose:2026}.

No projeto, o Docker Compose é utilizado tanto no ambiente de desenvolvimento

quanto no ambiente de produção para orquestrar os serviços de banco de dados

(PostgreSQL), armazenamento em memória (Valkey) e da própria API, garantindo

ao documentar e automatizar o processo de provisionamento, o projeto

favorece um modelo mais alinhado aos princípios de privacidade e de

autonomia sobre os dados dos usuários, permitindo que instituições ou

indivíduos preocupados com a confidencialidade de dados sensíveis de

saúde mental hospedem e controlem sua própria instância da aplicação.