\chapter{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 capítulo, são apresentados três 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; e o diagrama de
sequência, que detalha a comunicação entre os objetos ao longo do tempo. Esses
diagramas complementam-se mutuamente, proporcionando uma visão abrangente do
comportamento e da arquitetura do sistema.

\section{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]{casos-de-uso.png}
\source{O autor}
\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.

\section{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 2, pode-se observar os elementos descritos acima:

\begin{figure}[h]
\centering
\caption{Diagrama de Classes}
\label{fig:classes}
\includegraphics[width=0.9\linewidth]{diagrama-classes.png}
\source{O autor}
\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.