eletrotupi / tcc/ commit / c599711

thesis: rework class diagram commentary

Pedro Lucas Porcellis porcellis@eletrotupi.com 23 days ago c59971132fb0f2dfc242afa265329da7fb8e051e
Parents: f2e8f90
1 file(s) changed
  • monografia/chapters/modeling.tex +31 -15
monografia/chapters/modeling.tex
1 1 
\chapter{Modelagem}
2 2
3 3 
De acordo com \cite{guedes:2022}, a modelagem de sistemas é uma etapa fundamental do
4 4 
processo de desenvolvimento de software, pois permite representar graficamente
5 5 
os principais elementos do sistema, seus comportamentos e interações. Essa
▸ 91 unchanged lines
97 97 
papel do sistema como uma ferramenta alinhada com o EMA, gerando assim uma
98 98 
narrativa emocional diária.
99 99
100 100 
\section{Diagrama de Classes}
101 101
102 - 
O diagrama de classes é fundamental para o processo de modelagem de sistemas e
103 - 
constroem uma visão central tanto do relacionamento das entidades quanto de
104 - 
como elas são organizadas. Olhando para \cite[p. 101]{guedes:2022}: ''O
105 - 
principal enfoque é permitir a visualização das classes que o sistema e seus
106 - 
respectivos métodos e atributos''. Portanto, a base fundamental do sistema e
107 - 
seus relacionamentos, que será transformado posteriormente em código (ou
108 - 
diagramas posteriores) encontra-se nesse estágio.
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.
109 108
110 109 
Sobre o diagrama em si, cada classe possui três partes: título, os atributos,
111 110 
que representam as características da classe em si, e seus métodos, que são as
112 - 
ações que o sistema deve realizar \cite{ibm:2021}. Na Figura 2, pode-se
113 - 
observar os elementos descritos acima:
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:
114 113
115 114 
\begin{figure}[h]
116 115 
\centering
117 116 
\caption{Diagrama de Classes}
118 117 
\label{fig:classes}
119 118 
\includegraphics[width=0.9\linewidth]{diagrama-classes.png}
120 119 
\source{O autor}
121 120 
\end{figure}
122 121
123 - 
% TODO: Rewrite this, it feels, weird
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.
124 129
125 - 
Essa representação não se delimita em apenas contribuir para a visualização dos
126 - 
dados e seus comportamentos, mas auxilia também na implementação e evolução da
127 - 
aplicação. A separação entre entidades como Humor, Gatilho, Ações de Cuidado e
128 - 
Usuário, permite a extensão modular do sistema, respeitando os princípios de
129 - 
coesão e baixo acoplamento no desenho da arquitetura.
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.
130 146
131 147 
Ressalta-se, contudo, que o diagrama não contempla, padrões arquiteturais
132 148 
complementares, como \textit{Service Layer}, \textit{Repository} e \textit{Data
133 149 
Access Object (DAO)}, os quais são incorporados na etapa de implementação para
134 150 
garantir uma separação adequada de responsabilidades e facilitar a manutenção e
135 151 
escalabilidade do código, conforme as propostas de \citet{Fowler_2013} e
136 152 
\citet{Gamma:2011}. Esses elementos são importantes, considerando os princípios
137 153 
de legibilidade, simplicidade e responsabilidades, muitos organizados por
138 154 
\citet{Martin_2012}, asseguram que o código produzido seja limpo e sustentável.