\chapter{Nexo}

O aplicativo proposto por esse trabalho, denominado ``Nexo'', se propõe a ser uma

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

nome reflete essa escolha. A lógica é, de um aplicativo que consegue conectar

diversos pontos, que em um primeiro momento parecem soltos: sono, rotina,

práticas, humor, gatilhos.

A partir das demandas identificadas na pesquisa e dos princípios estabelecidos

para este projeto, delineia-se um sistema de monitoramento de humor centrado no

usuário, com ênfase em personalização, privacidade e utilidade reflexiva. O

funcionamento do sistema parte da premissa de que o humor não é uma variável

universal, mas sim composto por elementos subjetivos que variam entre

indivíduos. Assim, fundamentalmente para cada entrada no diário, o usuário pode

indicar que componentes de humor ele percebe em vigência naquele momento, como

``raiva'', ``tristeza'', ``felicidade'', etc., elementos que ele considera mais

representativos de seu estado emocional, permitindo um mapeamento mais fiel da

sua experiência.

O monitoramento, pode ser gerado em diversos momentos do dia, o que torna o

aplicativo mais flexível, ao invés de uma única entrada no dia. O usuário pode

também anotar para cada momento, algo relevante, através de escrita livre, e

usar uma escala que possa indicar o que ele percebe como indicadores dos níveis

de energia, estresse e ansiedade. Associado a isso, o sistema permitirá a

entrada de gatilhos e eventos significativos, sejam positivos ou negativos, que

poderão ser posteriormente correlacionados com os estados de humor, permitindo

identificar padrões ou ciclos. Esses dados podem ser correlacionados/vinculados

com ``práticas'' ou ``intervenções'', como fármacos, psicoterapia, atividades

físicas.

Outro ponto essencial é a exportação de dados em formatos acessíveis, como o

formato CSV \cite{Shafranovich_2005} \footnote{Formato de arquivo onde cada

coluna é separado por um delimitador, por exemplo: vírgulas, ponto-e-vírgula,

apresentado no RFC 4180}, garantindo que o usuário tenha controle e mobilidade

sobre suas informações, algo frequentemente negligenciado em sistemas fechados.

Além disso, a ferramenta é por inteiro \textit{software} livre, garantindo

transparência de funcionamento, possibilidade de auditoria e fomento a

melhorias comunitárias, especialmente importantes no contexto de tecnologias

sensíveis à saúde mental. Essas características formam a base de um sistema

comprometido com o bem-estar, o respeito à individualidade e a soberania dos

dados pessoais.

Com base nas funcionalidades listadas, pode-se definir os requisitos funcionais

e não funcionais no qual o sistema deve necessitar.

\section{Classificação dos Requisitos}

Como observado por \cite[p.~58]{sommerville:2010}, ``Os requisitos de um sistema são

as descrições dos serviços que o sistema deve prestar e as restrições à sua

operação''. Portanto, requisitos são declarações articuladas descrevendo de

forma clara o que o sistema deve ser capaz de fazer para satisfazer as

necessidades postas anteriormente. São definidas em duas categorias: requisitos

funcionais que descrevem o comportamento e funções do sistema e requisitos não

funcionais que descrevem os critérios específicos que podem ser usados para

avaliar o bom funcionamento do sistema. A separação entre requisitos funcionais

e não funcionais permite uma estrutura clara para priorização, testes e

validação do projeto, respeitando tanto os objetivos técnicos quanto éticos da

proposta. Logo a seguir, serão abordados com mais detalhes cada um deles.

\subsection{Requisitos funcionais}

Os requisitos funcionais dizem respeito às funcionalidades centrais do sistema,

ou seja, declarações de tudo o que o sistema deve e está proposto a fazer e

reagir. Sommerville reforça esse aspecto:

\begin{quote}

  Os requisitos funcionais de um sistema descrevem o que ele deve fazer. Eles

  dependem do tipo de software a ser desenvolvido, de quem são seus possíveis

  usuários e da abordagem geral adotada pela organização ao escrever os

  requisitos. Quando expressos como requisitos de usuário, os requisitos

  funcionais são normalmente descritos de forma abstrata, para serem

  compreendidos pelos usuários do sistema.

  \cite[p.~59]{sommerville:2010}

\end{quote}

Portanto, diante das funcionalidades previstas, que foram brevemente listadas,

no Quadro~\ref{tab:requisitos_funcionais} é apresentado os requisitos que o

sistema deve fornecer:

\newpage

% TODO: Add this to the list of tables

\begin{longtable}{| p{.20\textwidth} | p{.30\textwidth} | p{.40\textwidth} |}

    \caption{Requisitos funcionais}

    \label{tab:requisitos_funcionais} \\

        \hline

        N° & Requisito & Descrição \\

        \hline

        \endfirsthead

        \hline

        N° & Requisito & Descrição \\

        \hline

        \endhead

        \endfoot

        [RF01] &

        Login &

        O sistema deve ser capaz de realizar login com email e senha \\

        \hline

        [RF02] &

        Redefinir senha &

        O sistema permite que o usuário redefina a sua senha, mediante informar

        o email usado \\

        \hline

        [RF03] &

        Cadastro &

        O sistema deve permitir que o usuário crie uma conta \\

        \hline

        [RF04] &

        Desconectar &

        O sistema permite que o usuário faça logout do sistema \\

        \hline

        [RF05] &

        Manter humor &

        O usuário deve poder registrar e atualizar seu estado emocional

        conforme a necessidade \\

        \hline

        [RF06] &

        Registrar gatilho &

        O sistema deve permitir associar sentimentos ou eventos específicos que

        influenciam o humor \\

        \hline

        [RF07] &

        Visualizar histórico &

        O usuário deve ter acesso aos registros anteriores de humor e demais

        tipos de dados como Gatilho, Sono, etc. \\

        \hline

        [RF08] &

        Visualizar detalhes do dia &

        O sistema deve permitir expandir e consultar dados específicos de um

        determinado dia \\

        \hline

        [RF09] &

        Visualizar registros de humor recente &

        O usuário deve poder visualizar os ultimos registros de humor como

        forma de ler \\

        \hline

        [RF10] &

        Manter registro de sono &

        O sistema deve permitir que o usuário possa cadastrar registros de sono \\

        \hline

        [RF11] &

        Manter ações de cuidado &

        O usuário deve poder cadastrar ações de cuidado (atividade, medicamentos, consultas) \\

        \hline

        [RF12] &

        Exportar dados &

        O sistema deve oferecer uma funcionalidade para exportar os dados

        registrados \\

        \hline

        [RF13] &

        Registrar que um medicamento foi tomado &

        O usuário pode marcar que um determinado medicamento foi tomado

        mediante que foi cadastrado \\

        \hline

        [RF14] &

        Associar humor à um gatilho &

        O sistema deve permitir que o usuário vincule um humor específico com

        um gatilho \\

        \hline

        [RF15] &

        Associar consulta com um humor ou gatilho &

        O sistema deve permitir vincular uma consulta específica a um

        gatilho ou humor registrado \\

        \hline

        [RF16] &

        Gerar um relatório com os últimos dados &

        O usuário deve selecionar um período e gerar/exportar um relatório com

        os últimos dados  \\

        \hline

        \multicolumn{3}{c}{\small Fonte: Elaborado pelo autor (2026)} \\

\end{longtable}

\subsection{Requirementos não funcionais}

De acordo com \cite[p.~89]{sommerville:2010}: ``Requisitos não funcionais são

restrições sobre os serviços ou funções oferecidas pelo sistema''. Ou seja,

definem os critérios de qualidade que o sistema deve seguir, abrangendo

aspectos como segurança, usabilidade, desempenho e manutenção. Neste projeto,

destacam-se especialmente a preservação da privacidade do usuário, a

transparência proporcionada pelo código aberto e a possibilidade de utilização

offline, o que garante acessibilidade mesmo em contextos de conectividade

limitada.

\begin{longtable}{| p{.20\textwidth} | p{.30\textwidth} | p{.40\textwidth} |}

    \caption{Requisitos não funcionais}

    \label{tab:requisitos_nao_funcionais} \\

        \hline

        N° & Requisito & Descrição \\

        \hline

        \endfirsthead

        \hline

        N° & Requisito & Descrição \\

        \hline

        \endhead

        \endfoot

        [RNF01] &

        Usabilidade &

        O sistema deve possuir uma interface intuitiva e acessível para

        usuários leigos em tecnologia, com navegação fluída e confirmações

        visuais após cada interação importante \\

        \hline

        [RNF02] &

        Desempenho &

        O tempo de resposta entre a entrada do usuário e a resposta do sistema

        deve ser inferior a 1 segundo; O carregamento do histórico semanal e

        visualizações de ciclos anteriores deve ocorrer em no máximo 2

        segundos. \\

        \hline

        [RNF03] &

        Segurança &

        Os dados do usuário devem ser armazenados de forma criptografada; O

        sistema deve exigir autenticação segura para acesso; A exportação de

        dados deve sempre exigir a confirmação do usuário \\

        \hline

        [RNF04] &

        Confiabilidade &

        O sistema deve garantir a persistência dos dados, mesmo em casos de

        falha de energia ou conexão; Os dados registrados devem ser armazenados

        automáticamente e sincronizados quando ouvir conexão \\

        \hline

        [RNF05] &

        Portabilidade &

        Todos os dados do usuário podem ser exportados a qualquer momento, em

        um formato de texto que permita que ele possa ler e interpretar,

        mediante compreensão mínima da linguagem/formato utilizado \\

        \hline

        [RNF06] &

        Privacidade &

        Nenhuma informação sensível do usuário deve ser compartilhada com

        terceiros e o sistema deve fornecer uma política de privacidade clara e

        acessível; Quaisquer alterações à mesma demanda que o usuário seja

        notificado \\

        \hline

        \multicolumn{3}{c}{\small Fonte: Elaborado pelo autor (2026)} \\

\end{longtable}

Com essas definições em mãos, pode-se avançar para a etapa de modelagem do

sistema, usando os requerimentos apresentados como fundação para o sistema.

\section{Modelagem}

De acordo com \cite{guedes:2022}, a modelagem de sistemas é uma etapa fundamental do

processo de desenvolvimento de software, pois permite representar graficamente

os principais elementos do sistema, seus comportamentos e interações. Essa

representação facilita a comunicação entre desenvolvedores, usuários e demais

envolvidos, servindo tanto como guia para implementação quanto como instrumento

de validação dos requisitos levantados. Através da modelagem, é possível

antever a estrutura do sistema, simular sua dinâmica e assegurar que ele

atenderá às necessidades específicas dos usuários.

Neste subcapítulo, são apresentados dois tipos principais de diagramas da

\textit{Unified Modeling Language} (UML) empregados na modelagem do sistema

proposto: o diagrama de casos de uso, que descreve as funcionalidades esperadas

a partir da perspectiva do usuário; o diagrama de classes, que estrutura os

elementos do domínio em termos de atributos e relacionamentos. Esses diagramas

complementam-se mutuamente, proporcionando uma visão abrangente do

comportamento e da arquitetura do sistema.

\subsection{Casos de Uso}

O diagrama de casos de uso é o mais geral, informal e simples de compreender

\cite{guedes:2022}. A base dele é o levantamento de requisitos e a pesquisa

realizada, e serve como o pontapé para todo o processo de modelagem.

O diagrama de casos de uso, apresenta de forma simples, os atores, que são

representações das entidades que interagem com o sistema (sejam eles usuários

finais ou outros sistemas), e os casos de uso, que são as funcionalidades que o

sistema oferece. Ambos são conectados por linhas de associação. O sistema

também é delimitado por um retângulo, que contém os casos de uso

\cite{ibm:2021}.

Ao final desse processo, essa modelagem é transformada em documentação, e no

Apêndice A deste documento, contém a mesma, oferecendo uma visão mais detalhada

para cada caso de uso, seus caminhos alternativos e caminhos de exceções.

Pode-se verificar que esse acaba por ser o diagrama mais basilar do projeto

inteiro \cite{guedes:2022}.

\begin{figure}[h]

\centering

\caption{Diagrama de Casos de Uso}

\label{fig:use-cases}

\includegraphics[width=0.9\linewidth]{use-cases.png}

\source{Elaborado pelo autor (2026)}

\end{figure}

Na Figura~\ref{fig:use-cases}, pode-se observar que apenas um ator interage

com o sistema, o próprio usuário final. Também visualiza-se que cada elipse,

se resume a um requisito funcional, e os casos de uso estão interligados por

setas nomeadas com a palavra \textit{``<<extend>>''} que indica conexões onde a

execução de um caso de uso adjacente pode ocorrer dado uma determinada

condição em adição ao caso de uso inicial \cite{ibm:2021}.

Permeando todas as interações no sistema, o caso de uso mais central, o

``Login'', cujo qual estabelece uma base de autenticação, de forma que garante

que apenas usuários autenticados possam interagir com o sistema.

No caso de uso ``Manter Humor'' representa a funcionalidade central do sistema,

permitindo que o usuário registre seu estado emocional ao longo do tempo. Essa

ação ocorre por meio da inserção direta de uma informação de humor, cujo qual o

usuário pode selecionar entre cinco humores ``basais'', além de elementos que

ajudem a compreender, como escalas indicativas dos respectivos níveis de

estresse, ansiedade e quais componentes do humor o usuário identifica com mais

presença. A manutenção do humor no sistema contempla tanto a criação quanto a

edição e a exclusão desses registros.

O caso de uso ``Registrar Intervenção'' contempla o cadastro de estratégias,

práticas ou sugestões que o usuário utiliza ou deseja utilizar para lidar com

oscilações emocionais. As ações de cuidados, podem incluir desde ações

práticas, como caminhar, até técnicas cognitivas ou expressivas, como

atividades criativas, medicamentos utilizados ou atendimentos com profissionais

da área. Essa funcionalidade contribui para que o sistema sirva como uma

central e colabora para construir um registro mais criterioso, visto que o

usuário reconstrói o que aconteceu naquele determinado ponto no tempo.

O caso de uso ``Registrar Gatilho'' visa permitir que o usuário registre

eventos, sejam eles pensamentos, situações, ou estímulos que tenham

influenciado significativamente seu estado emocional. O objetivo é construir um

histórico de causas associadas a variações no humor, de modo a fomentar a

identificação de padrões recorrentes ou específicos. Essa funcionalidade é

especialmente útil para usuários em contextos terapêuticos ou de

autoconhecimento, favorecendo a análise de relações entre circunstâncias

externas e reações internas.

O caso de ``Registro de sono'', permite o usuário, de forma simples, criar no

sistema um registro da quantidade de horas de sono, e adicionar alguma anotação

breve. Esse elemento corrobora com a construção de indicadores, tanto da média

de sono, quanto também de estimular uma correlação entre sono e os níveis de

energia informado em cada humor.

Por fim, o caso de uso ``Vincular humor a um gatilho'' permite ao usuário

estabelecer vínculos entre os gatilhos identificados e os registros de humor,

formando um mapeamento de ação e reação, ou causa e reação. Essa associação

pode servir tanto para consulta futura quanto para, em um futuro, gerar

indicadores. Ao conectar eventos e suas respostas, a funcionalidade fortalece o

papel do sistema como uma ferramenta alinhada com o EMA, gerando assim uma

narrativa emocional diária.

\subsection{Diagrama de Classes}

O diagrama de classes é um dos principais artefatos da UML, responsável por

evidenciar a estrutura estática do sistema, seus atributos, operações e

relacionamentos. Conforme \cite[p. 101]{guedes:2022}: ``O principal enfoque é

permitir a visualização das classes que o sistema e seus respectivos métodos e

atributos''. Dessa forma, esse diagrama constitui a base da modelagem

estrutural que posteriormente será implementada em código.

Sobre o diagrama em si, cada classe possui três partes: título, os atributos,

que representam as características da classe em si, e seus métodos, que são as

operações que o sistema pode operar nos objetos das classes \cite{guedes:2022}. Na

Figura~\ref{fig:classes}, pode-se observar os elementos descritos acima:

\begin{figure}[h]

\centering

\caption{Diagrama de Classes}

\label{fig:classes}

\includegraphics[width=0.9\linewidth]{classes-v2.png}

\source{Elaborado pelo autor (2026)}

\end{figure}

Essa representação apresenta alguns vários elementos importantes. Primeiro, um

acoplamento entre \textit{Usuário} e as demais classes. Isso é natural, e

desejado, considerando que é o único ator. Existe também a separação entre as

entidades como Gatilho, Humor, muito embora exista uma relação de associação

entre elas, através da classe denominada ``VinculoGatilhoHumor'', visto que ela

seria representada por uma tabela auxiliar ligando as duas, aliadas do atributo

de estimativa de impacto.

Necessário destacar aqui que a classe ``AcaoCuidado'' é uma classe abstrata,

representando uma generalização. Essa classe serve como um guarda-chuva para

representar diversos tipos de ações que o usuário pode realizar. O papel dela

aqui se torna guardar elementos em comum entre esses tipos de ações, seus

respectivos vínculos com gatilhos ou humores. A partir dela então, traça-se

outras sub-classes que contem um melhor contexto sobre a atividade em si, por

exemplo, na classe ``Consulta'' guarda-se dados como a duração da consulta, que

tipo de consulta, e potenciais anotações ou comentários em cima da mesma.

Entretanto, uma classe ``RegistroMedicamento'' não precisa guardar mais do que

a relação com qual medicamento e quando ele foi de fato tomado.

Por fim, existe diversos tipos de enumeradores que delimitam exatamente quais

tipos de valores podem ser escolhidos. Esses enumeradores servem também como um

mecanismo de validação, sendo movidos tanto para o próprio banco de dados e

posteriormente sendo implementados como forma de controle em outros pontos como

na API.

Ressalta-se, contudo, que o diagrama não contempla, padrões arquiteturais

complementares, como \textit{Service Layer}, \textit{Repository} e \textit{Data

Access Object (DAO)}, os quais são incorporados na etapa de implementação para

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.