wiki

StudyFlow: mudanças entre as edições

← Edição anterior
Junioormario (discussão | contribs)
editors
12 edições
 
(32 revisões intermediárias por 3 usuários não estão sendo mostradas)
Linha 11: Linha 11:


== Requisitos Funcionais ==
== Requisitos Funcionais ==
<br>
=== Fase 1 - 2025-1 ===
<br>
* RF01 - Cadastro de Usuários
** Permite que novos usuários criem uma conta na plataforma, informando dados como nome, e-mail e senha
<br>
* RF02 - Verificação de Usuários
** Permite confirmar a autenticidade de usuários cadastrados, validando seus dados por meio de envio de código de confirmação por e-mail, garantindo que apenas contas legítimas tenham acesso ao sistema.
<br>
* RF03 - Login de Usuários
** Permite que usuários já cadastrados e verificados acessem o sistema, informando e-mail e senha previamente registrados.
<br>
* RF04 - Cadastro de Matérias
** Permite que o usuário cadastre matérias na plataforma.
<br>
* RF05 - Cadastro de Tarefas
** Permite criar tarefas vinculadas a uma matéria, definindo título, descrição e prazo.
<br>
* RF06 - Cadastro de Resumos
** Permite registrar resumos de conteúdo, associando-os a matérias específicas, com título e conteúdo do resumo.
<br>
* RF07 - Edição de Matérias
** Permite que o usuário altere as informações de matérias cadastradas.
<br>
* RF08 - Edição de Tarefas
** Permite que o usuário edite informações de tarefas existentes, como título, descrição, prazo ou status.
<br>
* RF09 - Edição de Resumos
** Permite que o usuário altere o conteúdo e detalhes de resumos já cadastrados.
<br>
* RF10 - Edição de Perfil de Usuário
** Permite que o usuário edite seus dados pessoais, como nome, e-mail e senha.
<br>
* RF11 - Remoção de Matérias
** Permite que o usuário exclua matérias cadastradas, removendo também as tarefas e resumos vinculados.
<br>
* RF12 - Remoção de Tarefas
** Permite que o usuário exclua tarefas cadastradas no sistema.
<br>
* RF13 - Remoção de Resumos
** Permite que o usuário exclua resumos cadastrados no sistema.
<br>
* RF14 - Encerramento de Conta
** Permite que o usuário encerre sua conta, removendo permanentemente todos os dados associados a ela.
<br>
* RF15 - Gerenciamento de Timer com Técnica Pomodoro
** Permite que o usuário utilize um cronômetro baseado na técnica Pomodoro, com ciclos de foco e descanso para otimizar o estudo.
<br>
* RF16 - Visualização Geral de Desempenho com Dashboard
** Exibe métricas e gráficos sobre tarefas concluídas, tempo de estudo, progresso por matéria e desempenho geral.
<br>
* RF17 - Gerenciamento de Cronograma de Estudos
** Permite que o usuário crie e gerencie um plano de estudos, organizando horários, prazos matérias de forma visual.
<br>
=== Fase 2 - 2025-2 ===
<br>
* RF01: Visualizar o desempenho geral do ''Dashboard''
* RF02: Visualizar as tarefas no modelo ''Kanban''
<br>
<br>


Linha 18: Linha 96:
== Melhores práticas ==
== Melhores práticas ==
<br>
<br>
<h3> <b> Introdução </b> </h3>
O presente documento tem como objetivo apresentar uma análise formal da aplicação dos princípios SOLID e das práticas de Clean Code no módulo de autenticação e nas principais estruturas do backend do projeto StudyFlow. A avaliação é realizada com base nas classes: <code>AuthController</code>, <code>TaskService</code>, <code>SubjectRepository</code>, <code>Subject</code>, <code>Task</code> e outras entidades relacionadas.
O foco está na arquitetura implementada no padrão Controller–Service–Repository, observando como cada princípio de design orientado a objetos é aplicado no código.
<b>Observação:</b> Todos os exemplos de código incluídos neste documento correspondem exatamente às implementações reais presentes no projeto StudyFlow.
<br>
<h3> <b>1. Single Responsibility Principle – Responsabilidade Única </b> </h3>
O <b>SRP</b> afirma que uma classe deve possuir apenas uma responsabilidade.
<b>Exemplo no projeto:</b> 
A classe <code>AuthController</code> apenas controla rotas e delega toda a lógica para <code>AuthService</code>. 
Ela não implementa regras de autenticação, validação, ou persistência.
<b>Observação:</b> 
O <code>AuthController</code> recebe requisições HTTP e invoca métodos do serviço, sem lógica de negócio adicional.
<br>
<h3> <b> 2. Open/Closed Principle – Aberto para Extensão, Fechado para Modificação </b> </h3>
O <b>OCP</b> determina que classes devem estar abertas para extensão e fechadas para modificação.
<b>Exemplo:</b> 
No <code>AuthController</code>:
<pre>
private final AuthService authService;
</pre>
O controlador depende apenas da abstração <code>AuthService</code>. 
Isso permite usar diferentes implementações como:
- <code>AuthServiceV2</code> 
- <code>FakeAuthService</code> para testes 
- <code>ExternalAuthService</code>
Sem modificar o controlador, atendendo ao OCP e ao DIP simultaneamente.
<br>
<h3> <b> 3. Liskov Substitution Principle – Substituição de Liskov </h3> </b>
O <b>LSP</b> garante que subclasses possam substituir suas superclasses sem quebrar o comportamento.
<b>Exemplo:</b>
<pre>
public class User implements UserDetails {
    @Override
    public String getUsername() { return email; }
    @Override
    public String getPassword() { return password; }
    @Override
    public boolean isEnabled() { return isVerified; }
}
</pre>
Onde o Spring espera um <code>UserDetails</code>, pode-se usar <code>User</code> sem problemas — respeitando LSP.
<br>
<h3> <b> 4. Interface Segregation Principle – Segregação de Interfaces </h3> </b>
O <b>ISP</b> recomenda interfaces pequenas e específicas.
<b>Exemplo no projeto:</b> 
As interfaces:
- <code>SubjectRepository</code> 
- <code>TaskRepository</code> 
- <code>UserRepository</code>
têm apenas os métodos necessários e são especializadas para cada entidade.
<br>
<h3> <b> 5. Dependency Inversion Principle – Inversão de Dependência </h3> </b>
O <b>DIP</b> recomenda que módulos de alto nível dependam de abstrações, não implementações concretas.
<b>Exemplo:</b> 
O <code>AuthController</code> depende apenas de <code>AuthService</code>, e o Spring injeta a implementação adequada.
<b>Benefícios:</b>
- menor acoplamento 
- maior flexibilidade 
- facilidade de trocar a lógica de autenticação 
<br>
<h3> <b> 6. Clean Code </h3> </b>
O projeto segue princípios de Clean Code como:
<b>1. Métodos curtos e diretos</b> 
Ex.: <code>createTask</code>, <code>deleteTask</code>, <code>findByUserId</code>
<b>2. Nomes claros e explicativos</b> 
Para classes, métodos e variáveis.
<b>3. Separação de responsabilidades por camadas</b>
1. <b>Controller</b> → trata HTTP 
2. <b>Service</b> → regras de negócio 
3. <b>Repository</b> → persistência 
4. <b>Entities</b> → estrutura dos dados 
<b>4. Ausência de duplicação</b> 
Nenhum controller repete lógica de outro.
<b>5. Code review</b> 
Todo código passou por revisão antes da integração, garantindo consistência e qualidade.
<br>
<h3> <b> Conclusão </h3> </b>
O projeto demonstra aplicação significativa dos princípios SOLID e das práticas de Clean Code. 
Essas práticas contribuíram para:
- reduzir acoplamento 
- melhorar organização 
- aumentar legibilidade 
- facilitar testes e manutenção 
O backend apresenta boa arquitetura e segue padrões adequados para crescimento futuro.
<br>
<b>Equipe StudyFlow</b>
= CRONOGRAMA  =
<br>
{| class="wikitable"
|-
! Item !! Data !! Atividades Study Flow !! Realizado
|-
| 1 || 14/11/2025 || Documentar tópico Investigação || 100%
|-
| 2 || 14/11/2025 || Documentar Visão Geral do sistema || 100%
|-
| 3 || 14/11/2025 || Definir Proposta de Projeto || 100%
|-
| 4 || 14/11/2025 || Validar Visão do Usuário || 0%
|-
| 5 || 17/11/2025 || Especificar RFs e RNFs - Fase 2 || 100%
|-
| 6 || 17/11/2025 || RF01: Visualizar o desempenho geral do Kanban || 100%
|-
| x || 24/11/2025 || TeckWeek ||
|-
| 7 || 01/12/2025 || Melhores Práticas || 100%
|-
| 8 || 01/12/2025 || RF02:  Visualizar o desempenho geral do Dashboard || 100%
|-
| 9 || 15/12/2025 || 2a. Entrega - Vídeo - 19/12/2025 - Teams  - Rfs 1 e 2 || 100%
|-
| 10 || || Desenvolver 3o RF ||
|-
| 11 || || Desenvolver 4o RF ||
|-
| 12 || || Incrementar diferencial tecnológico ||
|-
| 13 || || Vídeo Demo encaminhado para cliente || Aguardando avaliação
|-
|}
{| class="wikitable"
|-
! Item !! Data !! Atividades Study Flow !! Responsável
|-
| 1 || 16/02/2026 || Usabilidade || Pedro
|-
| 2 || 23/02/2026 || Requisitos do Sistema || Mário
|-
| 3 || 23/02/2026 || Projeto de Software || Anna
|-
| 4 || 23/02/2026 || Melhores Práticas || Pedro
|-
| 5 || 02/03/2026 || Versionamento || Renan
|-
| 6 || 02/03/2026 || QA || Paulo
|-
| 7 || — || Processo de Integração || ?
|-
| 8 || — || Segurança de Software || ?
|-
|-
! colspan="4" | IMPLEMENTAÇÃO
|-
| 9 || 23/02/2026 || Protótipo tela do Dashboard || Renan
|-
| 10 || 23/02/2026 || Protótipo tela do Calendário || Anna
|-
| 11 || 23/02/2026 || Back-end Dashboard || Anna
|-
| 12 || 23/02/2026 || Front-end Calendário || Paulo
|-
| 13 || 02/03/2026 || Front-end Dashboard || Renan
|-
| 14 || — || Back-end Calendário || ?
|-
| 15 || 07/03/2026 || Integração Dashboard || Mário
|-
| 16 || 09/03/2026 || Integração Calendário || Paulo
|-
| 17 || 23/03/2026 || Deploy e Ambientes || Renan e Mário
|}

Edição atual tal como às 01h21min de 10 de fevereiro de 2026

Fase 2


Escopo


  • Criar uma plataforma que ofereça uma solução eficiente e intuitiva para a organização dos estudos, auxiliando estudantes no planejamento, acompanhamento e otimização de suas rotinas acadêmicas
  • A proposta é reunir, em um único ambiente, ferramentas que facilitem a gestão do tempo, o estabelecimento de metas, o monitoramento de desempenho e a priorização de tarefas, promovendo uma experiência personalizada e centrada nas necessidades reais dos alunos
  • Com foco na praticidade, a plataforma busca transformar a maneira como os estudantes lidam com seus compromissos acadêmicos, tornando o processo de aprendizagem mais estruturado, produtivo e eficaz.


Requisitos Funcionais


Fase 1 - 2025-1


  • RF01 - Cadastro de Usuários
    • Permite que novos usuários criem uma conta na plataforma, informando dados como nome, e-mail e senha


  • RF02 - Verificação de Usuários
    • Permite confirmar a autenticidade de usuários cadastrados, validando seus dados por meio de envio de código de confirmação por e-mail, garantindo que apenas contas legítimas tenham acesso ao sistema.


  • RF03 - Login de Usuários
    • Permite que usuários já cadastrados e verificados acessem o sistema, informando e-mail e senha previamente registrados.


  • RF04 - Cadastro de Matérias
    • Permite que o usuário cadastre matérias na plataforma.


  • RF05 - Cadastro de Tarefas
    • Permite criar tarefas vinculadas a uma matéria, definindo título, descrição e prazo.


  • RF06 - Cadastro de Resumos
    • Permite registrar resumos de conteúdo, associando-os a matérias específicas, com título e conteúdo do resumo.


  • RF07 - Edição de Matérias
    • Permite que o usuário altere as informações de matérias cadastradas.


  • RF08 - Edição de Tarefas
    • Permite que o usuário edite informações de tarefas existentes, como título, descrição, prazo ou status.


  • RF09 - Edição de Resumos
    • Permite que o usuário altere o conteúdo e detalhes de resumos já cadastrados.


  • RF10 - Edição de Perfil de Usuário
    • Permite que o usuário edite seus dados pessoais, como nome, e-mail e senha.


  • RF11 - Remoção de Matérias
    • Permite que o usuário exclua matérias cadastradas, removendo também as tarefas e resumos vinculados.


  • RF12 - Remoção de Tarefas
    • Permite que o usuário exclua tarefas cadastradas no sistema.


  • RF13 - Remoção de Resumos
    • Permite que o usuário exclua resumos cadastrados no sistema.


  • RF14 - Encerramento de Conta
    • Permite que o usuário encerre sua conta, removendo permanentemente todos os dados associados a ela.


  • RF15 - Gerenciamento de Timer com Técnica Pomodoro
    • Permite que o usuário utilize um cronômetro baseado na técnica Pomodoro, com ciclos de foco e descanso para otimizar o estudo.


  • RF16 - Visualização Geral de Desempenho com Dashboard
    • Exibe métricas e gráficos sobre tarefas concluídas, tempo de estudo, progresso por matéria e desempenho geral.


  • RF17 - Gerenciamento de Cronograma de Estudos
    • Permite que o usuário crie e gerencie um plano de estudos, organizando horários, prazos matérias de forma visual.


Fase 2 - 2025-2


  • RF01: Visualizar o desempenho geral do Dashboard
  • RF02: Visualizar as tarefas no modelo Kanban


Requisitos Não-Funcionais


Melhores práticas


Introdução

O presente documento tem como objetivo apresentar uma análise formal da aplicação dos princípios SOLID e das práticas de Clean Code no módulo de autenticação e nas principais estruturas do backend do projeto StudyFlow. A avaliação é realizada com base nas classes: AuthController, TaskService, SubjectRepository, Subject, Task e outras entidades relacionadas.

O foco está na arquitetura implementada no padrão Controller–Service–Repository, observando como cada princípio de design orientado a objetos é aplicado no código.

Observação: Todos os exemplos de código incluídos neste documento correspondem exatamente às implementações reais presentes no projeto StudyFlow.


1. Single Responsibility Principle – Responsabilidade Única

O SRP afirma que uma classe deve possuir apenas uma responsabilidade.

Exemplo no projeto: A classe AuthController apenas controla rotas e delega toda a lógica para AuthService. Ela não implementa regras de autenticação, validação, ou persistência.

Observação: O AuthController recebe requisições HTTP e invoca métodos do serviço, sem lógica de negócio adicional.


2. Open/Closed Principle – Aberto para Extensão, Fechado para Modificação

O OCP determina que classes devem estar abertas para extensão e fechadas para modificação.

Exemplo: No AuthController: 

private final AuthService authService;

O controlador depende apenas da abstração AuthService. Isso permite usar diferentes implementações como:

- AuthServiceV2 - FakeAuthService para testes - ExternalAuthService

Sem modificar o controlador, atendendo ao OCP e ao DIP simultaneamente.


3. Liskov Substitution Principle – Substituição de Liskov

O LSP garante que subclasses possam substituir suas superclasses sem quebrar o comportamento.

Exemplo: 

public class User implements UserDetails {
    @Override
    public String getUsername() { return email; }

    @Override
    public String getPassword() { return password; }

    @Override
    public boolean isEnabled() { return isVerified; }
}

Onde o Spring espera um UserDetails, pode-se usar User sem problemas — respeitando LSP.


4. Interface Segregation Principle – Segregação de Interfaces

O ISP recomenda interfaces pequenas e específicas.

Exemplo no projeto: As interfaces:

- SubjectRepository - TaskRepository - UserRepository

têm apenas os métodos necessários e são especializadas para cada entidade.


5. Dependency Inversion Principle – Inversão de Dependência

O DIP recomenda que módulos de alto nível dependam de abstrações, não implementações concretas.

Exemplo: O AuthController depende apenas de AuthService, e o Spring injeta a implementação adequada.

Benefícios:

- menor acoplamento - maior flexibilidade - facilidade de trocar a lógica de autenticação


6. Clean Code

O projeto segue princípios de Clean Code como:

1. Métodos curtos e diretos Ex.: createTask, deleteTask, findByUserId

2. Nomes claros e explicativos Para classes, métodos e variáveis.

3. Separação de responsabilidades por camadas

1. Controller → trata HTTP 2. Service → regras de negócio 3. Repository → persistência 4. Entities → estrutura dos dados

4. Ausência de duplicação Nenhum controller repete lógica de outro.

5. Code review Todo código passou por revisão antes da integração, garantindo consistência e qualidade.


Conclusão

O projeto demonstra aplicação significativa dos princípios SOLID e das práticas de Clean Code. Essas práticas contribuíram para:

- reduzir acoplamento - melhorar organização - aumentar legibilidade - facilitar testes e manutenção

O backend apresenta boa arquitetura e segue padrões adequados para crescimento futuro.


Equipe StudyFlow

CRONOGRAMA


Item Data Atividades Study Flow Realizado
1 14/11/2025 Documentar tópico Investigação 100%
2 14/11/2025 Documentar Visão Geral do sistema 100%
3 14/11/2025 Definir Proposta de Projeto 100%
4 14/11/2025 Validar Visão do Usuário 0%
5 17/11/2025 Especificar RFs e RNFs - Fase 2 100%
6 17/11/2025 RF01: Visualizar o desempenho geral do Kanban 100%
x 24/11/2025 TeckWeek
7 01/12/2025 Melhores Práticas 100%
8 01/12/2025 RF02: Visualizar o desempenho geral do Dashboard 100%
9 15/12/2025 2a. Entrega - Vídeo - 19/12/2025 - Teams - Rfs 1 e 2 100%
10 Desenvolver 3o RF
11 Desenvolver 4o RF
12 Incrementar diferencial tecnológico
13 Vídeo Demo encaminhado para cliente Aguardando avaliação
Item Data Atividades Study Flow Responsável
1 16/02/2026 Usabilidade Pedro
2 23/02/2026 Requisitos do Sistema Mário
3 23/02/2026 Projeto de Software Anna
4 23/02/2026 Melhores Práticas Pedro
5 02/03/2026 Versionamento Renan
6 02/03/2026 QA Paulo
7 — Processo de Integração ?
8 — Segurança de Software ?
IMPLEMENTAÇÃO
9 23/02/2026 Protótipo tela do Dashboard Renan
10 23/02/2026 Protótipo tela do Calendário Anna
11 23/02/2026 Back-end Dashboard Anna
12 23/02/2026 Front-end Calendário Paulo
13 02/03/2026 Front-end Dashboard Renan
14 — Back-end Calendário ?
15 07/03/2026 Integração Dashboard Mário
16 09/03/2026 Integração Calendário Paulo
17 23/03/2026 Deploy e Ambientes Renan e Mário
Disponível em “http://3.143.69.156/wiki/index.php?title=StudyFlow&oldid=97200”