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 | 09/02/2026 | xx | |
| 2 | 23/02/2026 | xx | |
| 3 | 02/03/2026 | xx | |
| 4 | 09/03/2026 | xx | |
| 5 | 16/03/2026 | xx |