Desacoplamento do Motor WOKDEX em Microsserviço e Conectores LMS/LTI (Moodle VPL e CodeRunner)

Especificação OpenAPI, conteinerização e adaptadores desacoplados para integrar o diagnóstico WOKDEX ao DOMjudge e a ambientes Moodle

[object Object]
Feedback Formativo
Sem CEP
Data de Publicação

14/11/2026

Data de Modificação

14/11/2026

Código: TCC 02 · Trilha: Trilha 1: Sistemas e Juízes · Status: Disponível · Modalidade: Sistema / Arquitetura + Benchmark · Perfil: Individual · Complexidade: Alta · Regime Ético: Sem CEP (Computacional)

1. Contexto e Problema

Na implementação atual da tese, a lógica de diagnóstico pedagógico está acoplada ao fluxo interno do DOMserver (DOMjudge), e o contrato JSON (lst:json-response) é registrado apenas em caráter ilustrativo, sem API pública versionada. Esse acoplamento impede que ambientes amplamente adotados na graduação (como Moodle + Virtual Programming Lab (VPL) ou CodeRunner) consumam o motor de cenários WOKDEX sem duplicar código. Além disso, o antigo protótipo Moodle/VPL arquivado em cap05-integracao-moodle-vpl-levelup.tex nunca foi formalizado como uma arquitetura desacoplada, versionada e testada sob carga.

2. O que será feito (Objetivos Técnicos e Escopo)

  1. Especificar um contrato OpenAPI/REST formal (evoluindo lst:json-response e wok-problem.json) para submissão de traços de execução e retorno de diagnóstico pedagógico;
  2. Implementar o WOKDEX Engine como microsserviço conteinerizado (Docker, FastAPI/Python, cache em Redis, persistência de auditoria em PostgreSQL);
  3. Desenvolver e testar ao menos dois conectores/adaptadores desacoplados: um conector para DOMjudge e um conector para Moodle VPL (ou CodeRunner / LTI 1.3);
  4. Avaliar latência (p50, p95, p99), throughput, tolerância a falhas e integridade do contrato JSON em testes de carga simulada (Locust ou k6).

3. Perguntas para você refletir

Se você se identifica com as questões abaixo, este tema pode ser uma boa escolha:

  • Quais informações mínimas um ambiente externo (como Moodle VPL ou DOMjudge) precisa enviar para que o motor WOKDEX execute a classificação A–E e a HMD de forma stateless ou auditável?
  • Como garantir resiliência e baixa latência quando uma turma inteira submete código simultaneamente?
  • Que padrões de contrato e versionamento evitam acoplamento rígido entre plugins de LMS em PHP e o motor analítico em Python?

4. Divisão Sugerida (TCC 1 e TCC 2)

  • TCC 1: Levantamento arquitetural (análise do plugin DOMjudge e da PoC Moodle/VPL arquivada), especificação OpenAPI e arquitetura em contêineres (docker-compose).
  • TCC 2: Implementação do microsserviço e dos conectores, testes de integração ponta a ponta e benchmark de desempenho/carga (Locust/k6).

5. Entregáveis e Métricas de Avaliação

6. Pré-requisitos e Tecnologias Sugeridas

  • Base necessária: sólidos conhecimentos de APIs REST, Arquitetura de Software, bancos de dados relacionais e Git.
  • Tecnologias e conceitos envolvidos: Docker/Compose, Python (FastAPI), Redis, PostgreSQL, PHP (ecossistema Moodle/DOMjudge), LTI 1.3, Locust/k6.

7. Origem e Ponto de Partida

  • Origem na pesquisa WOKDEX:
    • apendices/arquivo-editorial/cap05-integracao-moodle-vpl-levelup.tex (PoC anterior com plugin Moodle VPL e middleware de sincronização);
    • apendices/arquivo-editorial/cap04-gamificacao-lms-expandida.tex e apendice-f-configuracao-ampliada.tex (configurações LMS/Canvas/Moodle, PostgreSQL e Redis);
    • cap05-implementacao.tex (lst:json-response e arquitetura do plugin no DOMserver).
  • Consulte também o guia de Metodologia e Ética.

8. Como demonstrar interesse

Antes de agendarmos uma conversa, preparação recomendada:

  1. Por que esse tema chamou sua atenção?
  2. Você tem mais interesse na camada de microsserviço/OpenAPI ou nos conectores Moodle/LTI?
  3. Qual sua disponibilidade semanal estimada para o TCC?
De volta ao topo