| 1 | \chapter{Modelagem}
|
| 2 |
|
| 3 | De acordo com \cite{guedes:2022}, a modelagem de sistemas é uma etapa fundamental do
|
| 4 | processo de desenvolvimento de software, pois permite representar graficamente
|
| 5 | os principais elementos do sistema, seus comportamentos e interações. Essa
|
| 6 | representação facilita a comunicação entre desenvolvedores, usuários e demais
|
| 7 | envolvidos, servindo tanto como guia para implementação quanto como instrumento
|
| 8 | de validação dos requisitos levantados. Através da modelagem, é possível
|
| 9 | antever a estrutura do sistema, simular sua dinâmica e assegurar que ele
|
| 10 | atenderá às necessidades específicas dos usuários.
|
| 11 |
|
| 12 | Neste capítulo, são apresentados três tipos principais de diagramas da
|
| 13 | \textit{Unified Modeling Language} (UML) empregados na modelagem do sistema
|
| 14 | proposto: o diagrama de casos de uso, que descreve as funcionalidades esperadas
|
| 15 | a partir da perspectiva do usuário; o diagrama de classes, que estrutura os
|
| 16 | elementos do domínio em termos de atributos e relacionamentos; e o diagrama de
|
| 17 | sequência, que detalha a comunicação entre os objetos ao longo do tempo. Esses
|
| 18 | diagramas complementam-se mutuamente, proporcionando uma visão abrangente do
|
| 19 | comportamento e da arquitetura do sistema.
|
| 20 |
|
| 21 | \section{Casos de Uso}
|
| 22 |
|
| 23 | O diagrama de casos de uso é o mais geral, informal e simples de compreender
|
| 24 | \cite{guedes:2022}. A base dele é o levantamento de requisitos e a pesquisa
|
| 25 | realizada, e serve como o pontapé para todo o processo de modelagem.
|
| 26 |
|
| 27 | O diagrama de casos de uso, apresenta de forma simples, os atores, que são
|
| 28 | representações das entidades que interagem com o sistema (sejam eles usuários
|
| 29 | finais ou outros sistemas), e os casos de uso, que são as funcionalidades que o
|
| 30 | sistema oferece. Ambos são conectados por linhas de associação. O sistema
|
| 31 | também é delimitado por um retângulo, que contém os casos de uso
|
| 32 | \cite{ibm:2021}.
|
| 33 |
|
| 34 | Ao final desse processo, essa modelagem é transformada em documentação, e no
|
| 35 | apêndice B deste documento, contém a mesma, oferecendo uma visão mais detalhada
|
| 36 | para cada caso de uso, seus caminhos alternativos e caminhos de exceções.
|
| 37 | Pode-se verificar que esse acaba por ser o diagrama mais basilar do projeto
|
| 38 | inteiro \cite{guedes:2022}.
|
| 39 |
|
| 40 | \begin{figure}[h]
|
| 41 | \centering
|
| 42 | \caption{Diagrama de Casos de Uso}
|
| 43 | \label{fig:use-cases}
|
| 44 | \includegraphics[width=0.9\linewidth]{casos-de-uso.png}
|
| 45 | \source{O autor}
|
| 46 | \end{figure}
|
| 47 |
|
| 48 | Na Figura~\ref{fig:use-cases}, pode-se observar que apenas um ator interage
|
| 49 | com o sistema, o próprio usuário final. Também visualiza-se que cada elipse,
|
| 50 | se resume a um requisito funcional, e os casos de uso estão interligados por
|
| 51 | setas nomeadas com a palavra \textit{''<<extend>>''} que indica conexões onde a
|
| 52 | execução de um caso de uso adjacente pode ocorrer dado uma determinada
|
| 53 | condição em adição ao caso de uso inicial \cite{ibm:2021}.
|
| 54 |
|
| 55 | Permeando todas as interações no sistema, o caso de uso mais central, o
|
| 56 | ''Login'', cujo qual estabelece uma base de autenticação, de forma que garante
|
| 57 | que apenas usuários autenticados possam interagir com o sistema.
|
| 58 |
|
| 59 | No caso de uso ''Manter Humor'' representa a funcionalidade central do sistema,
|
| 60 | permitindo que o usuário registre seu estado emocional ao longo do tempo. Essa
|
| 61 | ação ocorre por meio da inserção direta de uma informação de humor, cujo qual o
|
| 62 | usuário pode selecionar entre cinco humores ''basais'', além de elementos que
|
| 63 | ajudem a compreender, como escalas indicativas dos respectivos níveis de
|
| 64 | estresse, ansiedade e quais componentes do humor o usuário identifica com mais
|
| 65 | presença. A manutenção do humor no sistema contempla tanto a criação quanto a
|
| 66 | edição e a exclusão desses registros.
|
| 67 |
|
| 68 | O caso de uso ''Registrar Intervenção'' contempla o cadastro de estratégias,
|
| 69 | práticas ou sugestões que o usuário utiliza ou deseja utilizar para lidar com
|
| 70 | oscilações emocionais. As ações de cuidados, podem incluir desde ações
|
| 71 | práticas, como caminhar, até técnicas cognitivas ou expressivas, como
|
| 72 | atividades criativas, medicamentos utilizados ou atendimentos com profissionais
|
| 73 | da área. Essa funcionalidade contribui para que o sistema sirva como uma
|
| 74 | central e colabora para construir um registro mais criterioso, visto que o
|
| 75 | usuário reconstrói o que aconteceu naquele determinado ponto no tempo.
|
| 76 |
|
| 77 | O caso de uso ''Registrar Gatilho'' visa permitir que o usuário registre
|
| 78 | eventos, sejam eles pensamentos, situações, ou estímulos que tenham
|
| 79 | influenciado significativamente seu estado emocional. O objetivo é construir um
|
| 80 | histórico de causas associadas a variações no humor, de modo a fomentar a
|
| 81 | identificação de padrões recorrentes ou específicos. Essa funcionalidade é
|
| 82 | especialmente útil para usuários em contextos terapêuticos ou de
|
| 83 | autoconhecimento, favorecendo a análise de relações entre circunstâncias
|
| 84 | externas e reações internas.
|
| 85 |
|
| 86 | O caso de ''Registro de sono'', permite o usuário, de forma simples, criar no
|
| 87 | sistema um registro da quantidade de horas de sono, e adicionar alguma anotação
|
| 88 | breve. Esse elemento corrobora com a construção de indicadores, tanto da média
|
| 89 | de sono, quanto também de estimular uma correlação entre sono e os níveis de
|
| 90 | energia informado em cada humor.
|
| 91 |
|
| 92 | Por fim, o caso de uso ''Vincular humor a um gatilho'' permite ao usuário
|
| 93 | estabelecer vínculos entre os gatilhos identificados e os registros de humor,
|
| 94 | formando um mapeamento de ação e reação, ou causa e reação. Essa associação
|
| 95 | pode servir tanto para consulta futura quanto para, em um futuro, gerar
|
| 96 | indicadores. Ao conectar eventos e suas respostas, a funcionalidade fortalece o
|
| 97 | papel do sistema como uma ferramenta alinhada com o EMA, gerando assim uma
|
| 98 | narrativa emocional diária.
|
| 99 |
|
| 100 | \section{Diagrama de Classes}
|
| 101 |
|
| 102 | O diagrama de classes é um dos principais artefatos da UML, responsável por
|
| 103 | evidenciar a estrutura estática do sistema, seus atributos, operações e
|
| 104 | relacionamentos. Conforme \cite[p. 101]{guedes:2022}: ''O principal enfoque é
|
| 105 | permitir a visualização das classes que o sistema e seus respectivos métodos e
|
| 106 | atributos''. Dessa forma, esse diagrama constitui a base da modelagem
|
| 107 | estrutural que posteriormente será implementada em código.
|
| 108 |
|
| 109 | Sobre o diagrama em si, cada classe possui três partes: título, os atributos,
|
| 110 | que representam as características da classe em si, e seus métodos, que são as
|
| 111 | operações que o sistema pode operar nos objetos das classes \cite{ibm:2021}. Na
|
| 112 | Figura 2, pode-se observar os elementos descritos acima:
|
| 113 |
|
| 114 | \begin{figure}[h]
|
| 115 | \centering
|
| 116 | \caption{Diagrama de Classes}
|
| 117 | \label{fig:classes}
|
| 118 | \includegraphics[width=0.9\linewidth]{diagrama-classes.png}
|
| 119 | \source{O autor}
|
| 120 | \end{figure}
|
| 121 |
|
| 122 | Essa representação apresenta alguns vários elementos importantes. Primeiro, um
|
| 123 | acoplamento entre \textit{Usuário} e as demais classes. Isso é natural, e
|
| 124 | desejado, considerando que é o único ator. Existe também a separação entre as
|
| 125 | entidades como Gatilho, Humor, muito embora exista uma relação de associação
|
| 126 | entre elas, através da classe denominada ''VinculoGatilhoHumor'', visto que ela
|
| 127 | seria representada por uma tabela auxiliar ligando as duas, aliadas do atributo
|
| 128 | de estimativa de impacto.
|
| 129 |
|
| 130 | Necessário destacar aqui que a classe ''AcaoCuidado'' é uma classe abstrata,
|
| 131 | representando uma generalização. Essa classe serve como um guarda-chuva para
|
| 132 | representar diversos tipos de ações que o usuário pode realizar. O papel dela
|
| 133 | aqui se torna guardar elementos em comum entre esses tipos de ações, seus
|
| 134 | respectivos vínculos com gatilhos ou humores. A partir dela então, traça-se
|
| 135 | outras sub-classes que contem um melhor contexto sobre a atividade em si, por
|
| 136 | exemplo, na classe ''Consulta'' guarda-se dados como a duração da consulta, que
|
| 137 | tipo de consulta, e potenciais anotações ou comentários em cima da mesma.
|
| 138 | Entretanto, uma classe ''RegistroMedicamento'' não precisa guardar mais do que
|
| 139 | a relação com qual medicamento e quando ele foi de fato tomado.
|
| 140 |
|
| 141 | Por fim, existe diversos tipos de enumeradores que delimitam exatamente quais
|
| 142 | tipos de valores podem ser escolhidos. Esses enumeradores servem também como um
|
| 143 | mecanismo de validação, sendo movidos tanto para o próprio banco de dados e
|
| 144 | posteriormente sendo implementados como forma de controle em outros pontos como
|
| 145 | na API.
|
| 146 |
|
| 147 | Ressalta-se, contudo, que o diagrama não contempla, padrões arquiteturais
|
| 148 | complementares, como \textit{Service Layer}, \textit{Repository} e \textit{Data
|
| 149 | Access Object (DAO)}, os quais são incorporados na etapa de implementação para
|
| 150 | garantir uma separação adequada de responsabilidades e facilitar a manutenção e
|
| 151 | escalabilidade do código, conforme as propostas de \citet{Fowler_2013} e
|
| 152 | \citet{Gamma:2011}. Esses elementos são importantes, considerando os princípios
|
| 153 | de legibilidade, simplicidade e responsabilidades, muitos organizados por
|
| 154 | \citet{Martin_2012}, asseguram que o código produzido seja limpo e sustentável.
|