eletrotupi / tcc/ commit / 639638a

thesis: sync modeling chapter with current diagrams

The class and use case diagrams now include notifications and the report
export, so the prose describes them, drops the stale intervention
naming, and names the three care-action subclasses explicitly. Appendix
use cases for notifications and reports are added, and the orphaned
design-patterns citation is removed
Pedro Lucas Porcellis porcellis@eletrotupi.com · 9 days ago 639638a33f393a399e9112ea8bd95a1d9e34d75c Browse files
Parents bdcdeee
Changed files
9
Additions
+237
Deletions
-41
thesis/chapters/app.tex modified+34 -27
thesis/chapters/app.tex
1 1 
\chapter{Nexo}
2 2
3 3 
O aplicativo proposto por esse trabalho, denominado ``Nexo'', se propõe a ser uma
4 4 
aplicação para dispositivos móveis, de forma a preencher essas lacunas
5 5 
demonstradas tanto pelo questionário, quanto também tentando preencher as
357 357 
ajudem a compreender, como escalas indicativas dos respectivos níveis de
358 358 
estresse, ansiedade e quais componentes do humor o usuário identifica com mais
359 359 
presença. A manutenção do humor no sistema contempla tanto a criação quanto a
360 360 
edição e a exclusão desses registros.
361 361
362 - 
O caso de uso ``Registrar Intervenção'' contempla o cadastro de estratégias,
363 - 
práticas ou sugestões que o usuário utiliza ou deseja utilizar para lidar com
364 - 
oscilações emocionais. As ações de cuidados, podem incluir desde ações
365 - 
práticas, como caminhar, até técnicas cognitivas ou expressivas, como
366 - 
atividades criativas, medicamentos utilizados ou atendimentos com profissionais
362 + 
O caso de uso ``Manter ação de cuidado'' contempla o cadastro e a manutenção de
363 + 
estratégias, práticas ou sugestões que o usuário utiliza ou deseja utilizar
364 + 
para lidar com oscilações emocionais. As ações de cuidado podem incluir desde
365 + 
ações práticas, como caminhar, até técnicas cognitivas ou expressivas, como
366 + 
atividades criativas, medicamentos e tomadas de medicamento, além de
367 + 
atendimentos com profissionais
367 368 
da área. Essa funcionalidade contribui para que o sistema sirva como uma
368 369 
central e colabora para construir um registro mais criterioso, visto que o
369 370 
usuário reconstrói o que aconteceu naquele determinado ponto no tempo.
370 371
371 372 
O caso de uso ``Registrar Gatilho'' visa permitir que o usuário registre
381 382 
sistema um registro da quantidade de horas de sono, e adicionar alguma anotação
382 383 
breve. Esse elemento corrobora com a construção de indicadores, tanto da média
383 384 
de sono, quanto também de estimular uma correlação entre sono e os níveis de
384 385 
energia informado em cada humor.
385 386
386 - 
Por fim, o caso de uso ``Vincular humor a um gatilho'' permite ao usuário
387 + 
O caso de uso ``Vincular humor a um gatilho'' permite ao usuário
387 388 
estabelecer vínculos entre os gatilhos identificados e os registros de humor,
388 389 
formando um mapeamento de ação e reação, ou causa e reação. Essa associação
389 390 
pode servir tanto para consulta futura quanto para, em um futuro, gerar
390 391 
indicadores. Ao conectar eventos e suas respostas, a funcionalidade fortalece o
391 392 
papel do sistema como uma ferramenta alinhada com o EMA, gerando assim uma
392 393 
narrativa emocional diária.
393 394
395 + 
O caso de uso ``Visualizar Notificações'' permite ao usuário consultar os
396 + 
lembretes recebidos, como lembretes diários de registro de humor, lembretes de
397 + 
medicamento e alertas de indicadores. Ao tocar em uma notificação, o usuário é
398 + 
direcionado à tela correspondente.
399 +
400 + 
Por fim, o caso de uso ``Gerar relatório'' permite ao usuário gerar um
401 + 
documento em PDF consolidando os registros de humor do período escolhido, com a
402 + 
distribuição dos humores, os componentes de humor mais frequentes e os níveis
403 + 
de ansiedade, estresse e energia, para compartilhar com um terapeuta ou
404 + 
acompanhar a própria evolução.
405 +
394 406 
\subsection{Diagrama de Classes}
395 407
396 408 
O diagrama de classes é um dos principais artefatos da UML, responsável por
397 409 
evidenciar a estrutura estática do sistema, seus atributos, operações e
398 410 
relacionamentos. Conforme \cite[p. 101]{guedes:2022}: ``O principal enfoque é
407 419
408 420 
\begin{figure}[h]
409 421 
\centering
410 422 
\caption{Diagrama de Classes}
411 423 
\label{fig:classes}
412 - 
\includegraphics[width=0.9\linewidth]{classes-v2.png}
424 + 
\includegraphics[width=0.9\linewidth]{classes.png}
413 425 
\source{Elaborado pelo autor (2026)}
414 426 
\end{figure}
415 427
416 428 
Essa representação apresenta alguns vários elementos importantes. Primeiro, um
417 429 
acoplamento entre \textit{Usuário} e as demais classes. Isso é natural, e
418 430 
desejado, considerando que é o único ator. Existe também a separação entre as
419 431 
entidades como Gatilho, Humor, muito embora exista uma relação de associação
420 432 
entre elas, através da classe denominada ``VinculoGatilhoHumor'', visto que ela
421 433 
seria representada por uma tabela auxiliar ligando as duas, aliadas do atributo
422 - 
de estimativa de impacto.
434 + 
de impacto percebido.
423 435
424 - 
Necessário destacar aqui que a classe ``AcaoCuidado'' é uma classe abstrata,
425 - 
representando uma generalização. Essa classe serve como um guarda-chuva para
426 - 
representar diversos tipos de ações que o usuário pode realizar. O papel dela
427 - 
aqui se torna guardar elementos em comum entre esses tipos de ações, seus
428 - 
respectivos vínculos com gatilhos ou humores. A partir dela então, traça-se
429 - 
outras sub-classes que contem um melhor contexto sobre a atividade em si, por
430 - 
exemplo, na classe ``Consulta'' guarda-se dados como a duração da consulta, que
431 - 
tipo de consulta, e potenciais anotações ou comentários em cima da mesma.
432 - 
Entretanto, uma classe ``RegistroMedicamento'' não precisa guardar mais do que
433 - 
a relação com qual medicamento e quando ele foi de fato tomado.
436 + 
Necessário destacar aqui que a classe ``AcaoCuidado'' representa uma
437 + 
generalização. Essa classe serve como um guarda-chuva para representar
438 + 
diversos tipos de ações que o usuário pode realizar. O papel dela aqui se
439 + 
torna guardar elementos em comum entre esses tipos de ações, seus respectivos
440 + 
vínculos com gatilhos ou humores. A partir dela então, traçam-se três
441 + 
subclasses que contêm um melhor contexto
442 + 
sobre a atividade em si: na ``Consulta'' guarda-se dados como a duração e o tipo
443 + 
da consulta, além de potenciais anotações; na ``Atividade'', o tipo e a duração
444 + 
da atividade; e na ``RegistroMedicamento'', a relação com o medicamento e quando
445 + 
ele foi de fato tomado. O medicamento em si é representado pela classe
446 + 
``RegimeMedicamentoso'', que guarda nome, dosagem, periodicidade e horários. Por
447 + 
fim, a classe ``Notificações'' representa os lembretes enviados ao usuário,
448 + 
diários, de medicamento ou de indicadores, vinculando-se a ele e, quando
449 + 
aplicável, a um regime medicamentoso.
434 450
435 451 
Por fim, existe diversos tipos de enumeradores que delimitam exatamente quais
436 452 
tipos de valores podem ser escolhidos. Esses enumeradores servem também como um
437 453 
mecanismo de validação, sendo movidos tanto para o próprio banco de dados e
438 454 
posteriormente sendo implementados como forma de controle em outros pontos como
439 455 
na API.
440 -
441 - 
Ressalta-se, contudo, que o diagrama não contempla, padrões arquiteturais
442 - 
complementares, como \textit{Service Layer}, \textit{Repository} e \textit{Data
443 - 
Access Object (DAO)}, os quais são incorporados na etapa de implementação para
444 - 
garantir uma separação adequada de responsabilidades e facilitar a manutenção e
445 - 
escalabilidade do código, conforme as propostas de \citet{Fowler_2013} e
446 - 
\citet{Gamma:2011}. Esses elementos são importantes, considerando os princípios
447 - 
de legibilidade, simplicidade e responsabilidades, muitos organizados por
448 - 
\citet{Martin_2012}, asseguram que o código produzido seja limpo e sustentável.
thesis/chapters/tech.tex modified+1 -1
thesis/chapters/tech.tex
1 1 
\chapter{Tecnologias}
2 2
3 3 
Este capítulo apresenta as principais tecnologias empregadas no desenvolvimento
4 4 
do aplicativo, organizadas de acordo com a camada da arquitetura em que atuam:
5 5 
\textit{front-end}, \textit{back-end} e infraestrutura/persistência de dados.
55 55 
usuários, e coordenar o acesso ao banco de dados e a outros serviços
56 56 
auxiliares. No caso do Nexo, essa camada é implementada em Node.js com o
57 57 
framework \textit{Express}, seguindo uma arquitetura em camadas (\textit{Route}
58 58 
$\rightarrow$ \textit{Controller} $\rightarrow$ \textit{Service} $\rightarrow$
59 59 
Prisma) que separa as responsabilidades de validação, lógica de negócio e
60 - 
acesso a dados.
60 + 
acesso a dados \cite{Martin_2012}.
61 61
62 62 
\subsection{Express.js}
63 63
64 64 
Express.js é um \textit{framework} minimalista para aplicações web em
65 65 
Node.js, amplamente utilizado para a construção de APIs \textit{REST},
451 451 
ao documentar e automatizar o processo de provisionamento, o projeto
452 452 
favorece um modelo mais alinhado aos princípios de privacidade e de
453 453 
autonomia sobre os dados dos usuários, permitindo que instituições ou
454 454 
indivíduos preocupados com a confidencialidade de dados sensíveis de
455 455 
saúde mental hospedem e controlem sua própria instância da aplicação.
thesis/extra/use-cases/notifications.tex added+92
/dev/null → thesis/extra/use-cases/notifications.tex
1 + 
% UC10 --- Visualizar Notificações
2 +
3 + 
\begin{longtable}{| p{.40\textwidth} | p{.50\textwidth} |}
4 + 
\hline
5 +
6 + 
\textbf{Nome do Caso de Uso} &
7 + 
UC10 --- Visualizar Notificações \\
8 + 
\hline
9 +
10 + 
\textbf{Ator Principal} &
11 + 
Usuário \\
12 + 
\hline
13 +
14 + 
\textbf{Atores Secundários} &
15 + 
--- \\
16 + 
\hline
17 +
18 + 
\textbf{Resumo} &
19 + 
Permite ao usuário consultar os lembretes recebidos pelo sistema, como
20 + 
lembretes diários de registro de humor, lembretes de medicamento e alertas de
21 + 
indicadores. \\
22 + 
\hline
23 +
24 + 
\textbf{Pré-condições} &
25 + 
Usuário autenticado. \\
26 + 
\hline
27 +
28 + 
\textbf{Pós-condições} &
29 + 
O usuário visualiza as notificações e pode ser direcionado à tela
30 + 
correspondente. \\
31 + 
\hline
32 +
33 + 
\multicolumn{2}{|c|}{\textbf{Cenário Principal}}\\
34 + 
\hline
35 +
36 + 
\textbf{Ações do Ator} &
37 + 
\textbf{Resposta do Sistema} \\
38 + 
\hline
39 +
40 + 
1. Acessa a tela de notificações. & \\
41 + 
\cline{1-2}
42 +
43 + 
&
44 + 
2. O sistema apresenta as notificações do usuário, das mais recentes para as
45 + 
mais antigas. \\
46 + 
\cline{1-2}
47 +
48 + 
3. Toca em uma notificação. & \\
49 + 
\cline{1-2}
50 +
51 + 
&
52 + 
4. O sistema encaminha para a tela correspondente à notificação. \\
53 + 
\hline
54 +
55 + 
\multirow{2}{.40\textwidth}{\textbf{Restrições\\e validações}}
56 + 
&
57 + 
Somente as notificações do usuário autenticado são exibidas. \\
58 + 
\cline{2-2}
59 +
60 + 
&
61 + 
Notificações fora do período de validade são exibidas como expiradas. \\
62 + 
\hline
63 +
64 + 
\multicolumn{2}{|c|}{\textbf{Cenário Alternativo A1 --- Notificação recebida via push}}\\
65 + 
\hline
66 +
67 + 
\textbf{Ações do Ator} &
68 + 
\textbf{Resposta do Sistema} \\
69 + 
\hline
70 +
71 + 
1. Toca na notificação recebida no dispositivo. & \\
72 + 
\cline{1-2}
73 +
74 + 
&
75 + 
2. O sistema abre a tela de origem da notificação. \\
76 + 
\hline
77 +
78 + 
\multicolumn{2}{|c|}{\textbf{Cenário de Exceção E1 --- Nenhuma notificação}}\\
79 + 
\hline
80 +
81 + 
\textbf{Ações do Ator} &
82 + 
\textbf{Resposta do Sistema} \\
83 + 
\hline
84 +
85 + 
1. Acessa a tela de notificações. & \\
86 + 
\cline{1-2}
87 +
88 + 
&
89 + 
2. O sistema informa que não há notificações. \\
90 + 
\hline
91 +
92 + 
\end{longtable}
thesis/extra/use-cases/reports.tex added+108
/dev/null → thesis/extra/use-cases/reports.tex
1 + 
% UC11 --- Gerar Relatório
2 +
3 + 
\begin{longtable}{| p{.40\textwidth} | p{.50\textwidth} |}
4 + 
\hline
5 +
6 + 
\textbf{Nome do Caso de Uso} &
7 + 
UC11 --- Gerar Relatório \\
8 + 
\hline
9 +
10 + 
\textbf{Ator Principal} &
11 + 
Usuário \\
12 + 
\hline
13 +
14 + 
\textbf{Atores Secundários} &
15 + 
--- \\
16 + 
\hline
17 +
18 + 
\textbf{Resumo} &
19 + 
Permite ao usuário gerar um documento em PDF consolidando os registros de
20 + 
humor de um período escolhido, para compartilhar com um terapeuta ou guardar
21 + 
para acompanhamento próprio. \\
22 + 
\hline
23 +
24 + 
\textbf{Pré-condições} &
25 + 
Usuário autenticado. \\
26 + 
\hline
27 +
28 + 
\textbf{Pós-condições} &
29 + 
O usuário obtém um PDF com os registros de humor do período. \\
30 + 
\hline
31 +
32 + 
\multicolumn{2}{|c|}{\textbf{Cenário Principal}}\\
33 + 
\hline
34 +
35 + 
\textbf{Ações do Ator} &
36 + 
\textbf{Resposta do Sistema} \\
37 + 
\hline
38 +
39 + 
1. Acessa a tela de relatório. & \\
40 + 
\cline{1-2}
41 +
42 + 
&
43 + 
2. O sistema apresenta os períodos disponíveis (7, 30 e 90 dias, além do
44 + 
período personalizado). \\
45 + 
\cline{1-2}
46 +
47 + 
3. Seleciona um período. & \\
48 + 
\cline{1-2}
49 +
50 + 
4. Toca em ``Gerar relatório''. & \\
51 + 
\cline{1-2}
52 +
53 + 
&
54 + 
5. O sistema gera o PDF com os registros de humor do período. \\
55 + 
\cline{1-2}
56 +
57 + 
&
58 + 
6. O sistema abre o compartilhamento do documento. \\
59 + 
\hline
60 +
61 + 
\multirow{2}{.40\textwidth}{\textbf{Restrições\\e validações}}
62 + 
&
63 + 
O período deve ter início anterior ao fim. \\
64 + 
\cline{2-2}
65 +
66 + 
&
67 + 
O intervalo não pode exceder 90 dias. \\
68 + 
\hline
69 +
70 + 
\multicolumn{2}{|c|}{\textbf{Cenário Alternativo A1 --- Período personalizado}}\\
71 + 
\hline
72 +
73 + 
\textbf{Ações do Ator} &
74 + 
\textbf{Resposta do Sistema} \\
75 + 
\hline
76 +
77 + 
1. Seleciona ``Personalizado''. & \\
78 + 
\cline{1-2}
79 +
80 + 
&
81 + 
2. O sistema apresenta os campos de data inicial e final. \\
82 + 
\cline{1-2}
83 +
84 + 
3. Informa as datas desejadas. & \\
85 + 
\cline{1-2}
86 +
87 + 
4. Toca em ``Gerar relatório''. & \\
88 + 
\cline{1-2}
89 +
90 + 
&
91 + 
5. O sistema gera o PDF com os registros do período informado. \\
92 + 
\hline
93 +
94 + 
\multicolumn{2}{|c|}{\textbf{Cenário de Exceção E1 --- Falha na geração}}\\
95 + 
\hline
96 +
97 + 
\textbf{Ações do Ator} &
98 + 
\textbf{Resposta do Sistema} \\
99 + 
\hline
100 +
101 + 
1. Toca em ``Gerar relatório''. & \\
102 + 
\cline{1-2}
103 +
104 + 
&
105 + 
2. O sistema informa que não foi possível gerar o relatório. \\
106 + 
\hline
107 +
108 + 
\end{longtable}
thesis/extra/usecases.tex modified+2
thesis/extra/usecases.tex
1 1 
\input{extra/use-cases/login}
2 2 
\input{extra/use-cases/register}
3 3 
\input{extra/use-cases/mood-entries}
4 4 
\input{extra/use-cases/mood}
5 5 
\input{extra/use-cases/trigger}
6 6 
\input{extra/use-cases/sleep}
7 7 
\input{extra/use-cases/care-actions}
8 8 
\input{extra/use-cases/history}
9 9 
\input{extra/use-cases/energy-sleep-correlation}
10 + 
\input{extra/use-cases/notifications}
11 + 
\input{extra/use-cases/reports}
thesis/images/classes-v2.png deleted
thesis/images/classes-v2.png → /dev/null
Binary file
thesis/images/classes.png added
/dev/null → thesis/images/classes.png
Binary file
thesis/images/use-cases.png modified
thesis/images/use-cases.png
Binary file
thesis/thesis.bib modified-13
thesis/thesis.bib
1 1 
@article{Iwaya:22,
2 2 
  title={On the privacy of mental health apps},
3 3 
  volume={28},
4 4 
  DOI={10.1007/s10664-022-10236-0},
5 5 
  number={1},
117 117 
  url        = {https://www.ibm.com/docs/pt-br/rsas/7.5.0?topic=model-modeling-class-diagram-static-structure},
118 118 
  organization = {IBM},
119 119 
  urldate = {2026-07-03}
120 120 
},
121 121
122 - 
@book{Gamma:2011,
123 - 
  address={Boston, Mass. Munich},
124 - 
  edition={39. printing},
125 - 
  author={Gamma, E. and Helm, R. and Johnson, R. and Vlissides, J.},
126 - 
  series={Addison-Wesley professional computing series},
127 - 
  title={Design patterns: elements of reusable object-oriented software},
128 - 
  ISBN={0321700694},
129 - 
  publisher={Addison-Wesley},
130 - 
  year={2011},
131 - 
  collection={Addison-Wesley professional computing series},
132 - 
  language={eng}
133 - 
},
134 -
135 122 
@book{Fowler_2013,
136 123 
  address={Boston San Francisco New York Toronto Montreal London Munich Paris Madrid Capetown},
137 124 
  edition={Nineteenth printing},
138 125 
  series={The Addison-Wesley Signature Series},
139 126 
  title={Patterns of enterprise application architecture},
605 592 
	titleaddon = {martinfowler.com},
606 593 
	author = {Vocke, Ham},
607 594 
  year={2012},
608 595 
  note = {Acessado em 17 out. 2026}
609 596 
}