\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{``<>''} 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.