StudyFlow

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

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

Evolução do projeto

Item	Data	Atividades Study Flow	Realizado
1	14/11/2025	Documentar tópico Investigação	0%
2	14/11/2025	Documentar Visão Geral do sistema	100%
3	14/11/2025	Definir Proposta de Projeto	0%
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 Dashboard	80%
x	24/11/2025	TeckWeek
7	01/12/2025	Melhores Práticas
8	01/12/2025	RF01: Visualizar o desempenho geral do Dashboard
9	01/12/2025	RF02: Visualizar as tarefas no modelo Kanban
10		Desenvolver 3o RF
11		Desenvolver 4o RF
12		Incrementar diferencial tecnológico