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

sistema deve fornecer:

\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 B 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.

Nesse capítulo, abordaremos os testes realizados que ajudam a comprovar e

mapear de forma a garantir consistência e confiabilidade do aplicativo.