wiki

CertificaUFU: mudanças entre as edições

← Edição anterior
 
(15 revisões intermediárias por 2 usuários não estão sendo mostradas)
Linha 94: Linha 94:
** O sistema deve ser estruturado para facilitar futuras atualizações e correções de bugs
** O sistema deve ser estruturado para facilitar futuras atualizações e correções de bugs


== Melhores práticas ==
<h2>Melhores Práticas</h2>
<br>
<p>
O backend (Java) segue uma <strong>Arquitetura de Camadas (Layered Architecture)</strong>, fundamental para o desacoplamento e a manutenibilidade do sistema. A camada de <strong>Controladores (controllers)</strong> é responsável apenas por receber requisições HTTP e rotear os dados, atuando como interface entre o cliente e a lógica de negócio, sem conter regras de validação ou manipulação de dados.
</p>
<p>
O coração da aplicação reside na camada de <strong>Serviços (services)</strong>, onde está concentrada toda a lógica de negócio (validações, cálculos e transformações). Esse isolamento garante que as regras de negócio sejam testáveis independentemente do protocolo web.
</p>
<p>
Complementam essa estrutura as camadas de <strong>Infraestrutura (infra)</strong>, que trata de aspectos técnicos como acesso a bancos de dados, e <strong>Segurança (security)</strong>, dedicada à autenticação e autorização dos usuários.
</p>
<h3>Exemplo de Single Responsibility Principle (SRP)</h3>
<pre>
@RestController
@RequestMapping("/api/certificates")
public class CertificateController {
 
    private final CertificateService certificateService;
 
    @Autowired
    public CertificateController(CertificateService certificateService) {
        this.certificateService = certificateService;
    }
 
    @PostMapping
    public ResponseEntity&lt;CertificateDTO&gt; createCertificate(@Valid @RequestBody CertificateDTO dto) {
        CertificateDTO created = certificateService.createCertificate(dto);
        return new ResponseEntity&lt;&gt;(created, HttpStatus.CREATED);
    }
}
</pre>
<p>
No exemplo acima, o <strong>CertificateController</strong> tem uma única responsabilidade: atuar como interface HTTP, delegando toda a lógica de negócio ao <strong>CertificateService</strong>. Isso está em conformidade com o <strong>Princípio da Responsabilidade Única (SRP)</strong> do SOLID, facilitando a manutenção, testes e evolução do sistema.
</p>
 
<h3>Monorepo com Módulos Independentes</h3>
<p>
O projeto adota a estratégia de <strong>monorepo</strong>, onde múltiplos módulos — como backend, frontend e bibliotecas internas — são gerenciados em um único repositório. Essa abordagem facilita a integração entre as equipes, promove a <strong>reutilização de código</strong> e garante maior consistência entre os diferentes domínios do sistema. Cada módulo pode ser desenvolvido, testado e implantado de forma independente, otimizando o fluxo de trabalho e a manutenção do projeto.
</p>
 
<h3>Documentação Automática com OpenAPI/Swagger</h3>
<p>
A API backend é documentada automaticamente utilizando <strong>OpenAPI/Swagger</strong>. Por meio de anotações no código, toda a especificação dos endpoints é gerada de forma dinâmica, criando uma <strong>documentação viva</strong> e sempre atualizada. Isso facilita a integração com o frontend, acelera o desenvolvimento e reduz dúvidas sobre o funcionamento da API, além de servir como referência para novos desenvolvedores e para a manutenção futura.
</p>


= Evolução do projeto =
= CRONOGRAMA =
<br>
<br>


Linha 103: Linha 144:
|-
|-
! Item !! Data !! Atividades CertificaUFU !! Realizado
! Item !! Data !! Atividades CertificaUFU !! Realizado
|- 1
|-
| 1 || 14/11/2025 || Documentar tópico Investigação ||
| 1 || 14/11/2025 || Documentar tópico Investigação || 100%
|- 2
|-
| 2 || 14/11/2025 || Documentar os Manuais ||
| 2 || 14/11/2025 || Documentar os Manuais || 100%
|- 3
|-
| 3 || 14/11/2025 || Definir Proposta de Projeto ||
| 3 || 14/11/2025 || Definir Proposta de Projeto || ??
|- 4
|-
| 4 || 14/11/2025 || Validar Visão do Usuário ||
| 4 || 14/11/2025 || Validar Visão do Usuário || ??
|- 5
|-
| 5 || 17/11/2025 || Especificar RFs e RNFs - Fase 2 ||
| 5 || 17/11/2025 || Especificar RFs e RNFs - Fase 2 || 100%
|- 6
|-
| 6 || 17/11/2025 || Desenvolver Submeter documento para o OCR ||
| 6 || 17/11/2025 || RF01: Submeter documento para o OCR || 100%
|- 7
|-
| 5 || 24/11/2025 || Melhores Práticas ||
| x || 24/11/2025 || TeckWeek ||
|-
| 7 || 01/12/2025 || Melhores Práticas ||
|-
| 8 || 01/12/2025 || RF01: Submeter documento para o OCR || 100%
|-
| 9 || 08/12/2025 || RF01: Submeter documento para o OCR || 100%
|-
| 10 || 08/12/2025 || RF02: Processar a resposta do OCR || 0%
|-
| 11 || 15/12/2025 || 2a. Entrega - Vídeo até 19/12 pelo Teams - RFs 1 e 2 ||
|-
| 12 || || RF03: Persistir o texto pelo OCR || 100%
|-
| 13 || || Incrementar diferencial tecnológico ||
|-
| 14 || 19/01/2026 || Cliente avaliando solução (Apresentação em PDF) ||
|-
| 15 || 19/12/2025 || Vídeo encaminhado para cliente || Aguardando avaliação
|-
|}
 
{| class="wikitable"
|-
! Item !! Data !! Atividades CertificaUFU!! Responsável
|-
| 1 || 09/02/2026 || xx ||
|-
| 2 || 23/02/2026 || xx ||
|-
| 3 || 02/03/2026 || xx ||
|-
| 4 || 09/03/2026 || xx ||
|-
|-
| 7 || || Desenvolver RF Processar a resposta do OCR ||
| 5 || 16/03/2026 || xx ||
|- 8
|-
| 8 || || Desenvolver RF Persistir o texto pelo OCR ||
|- 9
| 9 || || Desenvolver 4o RF ||
|- 10
| 10 || || Incrementar diferencial tecnológico ||
|-
|}
|}

Edição atual tal como às 20h55min de 9 de fevereiro de 2026

Fase 2


Escopo


  • Otimizar o ciclo de vida das atividades complementares e de estágio na Universidade Federal de Uberlândia. A plataforma centraliza desde a divulgação de novas oportunidades de desenvolvimento para os alunos até o envio, acompanhamento e validação dos documentos comprobatórios garantindo mais agilidade e transparência para alunos e coordenadores.


Requisitos Funcionais


FAse 1 - 2025-1


  • RF01 — Autenticação de Usuário
    • O sistema deve permitir login para alunos e administradores.


  • RF02 — Dashboard do Aluno
    • O sistema deve exibir ao aluno um painel com acesso a funcionalidades principais.


  • RF03 — Envio de Documentos
    • O aluno deve conseguir submeter documentos como certificados, relatórios, etc.
    • O sistema deve armazenar esses documentos no banco de dados.


  • RF04 — Consulta de Documentos
    • O aluno deve conseguir visualizar o status de seus documentos e certificados enviados.


  • RF05 — Feed de Oportunidades
    • O sistema deve exibir aos alunos uma lista de oportunidades de estágio, cursos, eventos, etc.


  • RF06 — Gerenciamento de Perfil
    • O aluno deve conseguir visualizar e editar suas informações pessoais.


  • RF07 — Dashboard Administrativo
    • O administrador deve acessar um painel com pendências e funcionalidades de gestão.


  • RF08 — Validação de Documentos
    • O administrador deve visualizar documentos pendentes enviados pelos alunos.
    • O administrador deve aprovar ou rejeitar os documentos, podendo incluir uma justificativa.


  • RF09 — Cadastro de Oportunidades
    • O administrador deve conseguir cadastrar novas oportunidades para o feed dos alunos


Fase 2 - 2025-2



  • RF01: Submeter documento para o OCR
  • RF02: Processar a resposta do OCR
  • RF03: Persistir o texto pelo OCR


Requisitos Não-Funcionais


  • RNF01 — Segurança
    • O sistema deve proteger os dados dos usuários e documentos através de autenticação segura.
    • Deve haver controle de acesso (permissões diferenciadas entre alunos e administradores).


  • RNF02 — Usabilidade
    • A interface deve ser intuitiva, com navegação clara para ambos os perfis de usuário.


  • RNF03 — Confiabilidade
    • O sistema deve garantir que os documentos enviados não sejam corrompidos ou perdidos.
    • A informação exibida (como status de documentos) deve estar sempre atualizada com o banco de dados.


  • RNF04 — Escalabilidade
    • O sistema deve suportar o crescimento no número de usuários e documentos sem perda de desempenho.


  • RNF05 — Performance
    • O tempo de resposta para login, envio de documentos e visualização de painéis deve ser rápido (idealmente  2s).


  • RNF06 — Compatibilidade
    • O sistema deve funcionar nos principais navegadores Chrome, Firefox, Edge).
    • Deve ser acessível em dispositivos móveis (responsivo).


  • RNF07 — Manutenibilidade
    • O sistema deve ser estruturado para facilitar futuras atualizações e correções de bugs

Melhores Práticas

O backend (Java) segue uma Arquitetura de Camadas (Layered Architecture), fundamental para o desacoplamento e a manutenibilidade do sistema. A camada de Controladores (controllers) é responsável apenas por receber requisições HTTP e rotear os dados, atuando como interface entre o cliente e a lógica de negócio, sem conter regras de validação ou manipulação de dados.

O coração da aplicação reside na camada de Serviços (services), onde está concentrada toda a lógica de negócio (validações, cálculos e transformações). Esse isolamento garante que as regras de negócio sejam testáveis independentemente do protocolo web.

Complementam essa estrutura as camadas de Infraestrutura (infra), que trata de aspectos técnicos como acesso a bancos de dados, e Segurança (security), dedicada à autenticação e autorização dos usuários.

Exemplo de Single Responsibility Principle (SRP)

@RestController
@RequestMapping("/api/certificates")
public class CertificateController {

    private final CertificateService certificateService;

    @Autowired
    public CertificateController(CertificateService certificateService) {
        this.certificateService = certificateService;
    }

    @PostMapping
    public ResponseEntity<CertificateDTO> createCertificate(@Valid @RequestBody CertificateDTO dto) {
        CertificateDTO created = certificateService.createCertificate(dto);
        return new ResponseEntity<>(created, HttpStatus.CREATED);
    }
}

No exemplo acima, o CertificateController tem uma única responsabilidade: atuar como interface HTTP, delegando toda a lógica de negócio ao CertificateService. Isso está em conformidade com o Princípio da Responsabilidade Única (SRP) do SOLID, facilitando a manutenção, testes e evolução do sistema.

Monorepo com Módulos Independentes

O projeto adota a estratégia de monorepo, onde múltiplos módulos — como backend, frontend e bibliotecas internas — são gerenciados em um único repositório. Essa abordagem facilita a integração entre as equipes, promove a reutilização de código e garante maior consistência entre os diferentes domínios do sistema. Cada módulo pode ser desenvolvido, testado e implantado de forma independente, otimizando o fluxo de trabalho e a manutenção do projeto.

Documentação Automática com OpenAPI/Swagger

A API backend é documentada automaticamente utilizando OpenAPI/Swagger. Por meio de anotações no código, toda a especificação dos endpoints é gerada de forma dinâmica, criando uma documentação viva e sempre atualizada. Isso facilita a integração com o frontend, acelera o desenvolvimento e reduz dúvidas sobre o funcionamento da API, além de servir como referência para novos desenvolvedores e para a manutenção futura.

CRONOGRAMA


Item Data Atividades CertificaUFU Realizado
1 14/11/2025 Documentar tópico Investigação 100%
2 14/11/2025 Documentar os Manuais 100%
3 14/11/2025 Definir Proposta de Projeto ??
4 14/11/2025 Validar Visão do Usuário ??
5 17/11/2025 Especificar RFs e RNFs - Fase 2 100%
6 17/11/2025 RF01: Submeter documento para o OCR 100%
x 24/11/2025 TeckWeek
7 01/12/2025 Melhores Práticas
8 01/12/2025 RF01: Submeter documento para o OCR 100%
9 08/12/2025 RF01: Submeter documento para o OCR 100%
10 08/12/2025 RF02: Processar a resposta do OCR 0%
11 15/12/2025 2a. Entrega - Vídeo até 19/12 pelo Teams - RFs 1 e 2
12 RF03: Persistir o texto pelo OCR 100%
13 Incrementar diferencial tecnológico
14 19/01/2026 Cliente avaliando solução (Apresentação em PDF)
15 19/12/2025 Vídeo encaminhado para cliente Aguardando avaliação
Item Data Atividades CertificaUFU 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
Disponível em “http://3.143.69.156/wiki/index.php?title=CertificaUFU&oldid=97165”