Exemplo Prático da Metodologia PDCL
Para compreender plenamente o potencial da metodologia PDCL, é essencial observar como ela se comporta em um cenário real. Vamos considerar um exemplo simples, porém representativo: uma aplicação responsável por monitorar temperatura e emitir alertas quando determinados limites são ultrapassados — algo extremamente comum em sistemas embarcados e IoT.
O processo se inicia com a construção do arquivo REQUIREMENTS.md, que funciona como a especificação central do sistema. Diferente de um documento tradicional, ele é pensado para ser interpretado tanto por humanos quanto por IA, e pode ser iterativamente refinado.
Um exemplo inicial poderia ser descrito da seguinte forma:
# Sistema de Monitoramento de Temperatura
## Requisitos Funcionais
- O sistema deve ler a temperatura a cada 1 segundo.
- O sistema deve registrar a temperatura no log.
- O sistema deve emitir um alerta quando a temperatura ultrapassar 50°C.
## Requisitos Não Funcionais
- O tempo de resposta para alerta deve ser inferior a 100 ms.
- O log deve conter timestamp, função e descrição clara do evento.
Nesse ponto, já é possível interagir com a IA para melhorar esse conteúdo, pedindo, por exemplo, maior precisão, inclusão de cenários de erro ou padronização da linguagem. Esse refinamento contínuo aproxima esse artefato de um modelo de requisitos executável, algo que tradicionalmente exigiria ferramentas mais complexas como UML ou DSLs específicas .
Na etapa seguinte (Do), solicitamos à IA a geração do código com base nesses requisitos. Um exemplo em C para um microcontrolador poderia ser:
#include <stdio.h>
#include <time.h>
float read_temperature() {
// Mock de leitura
return 55.0;
}
void log_event(const char* level, const char* file, const char* func, int line, const char* message) {
time_t now = time(NULL);
printf("%ld | %s | %s | %d | %s | %s\n",
now, file, func, line, level, message);
}
int main() {
while (1) {
float temp = read_temperature();
log_event("INFO", __FILE__, __func__, __LINE__, "Leitura de temperatura realizada");
if (temp > 50.0) {
log_event("ALERT", __FILE__, __func__, __LINE__, "Temperatura acima do limite!");
}
sleep(1);
}
}
Observe que o código já nasce instrumentado com logs estruturados, o que é fundamental para a próxima etapa. Esse detalhe é crucial: no PDCL, não existe código “sem observabilidade”.
Ao executar a aplicação, obtemos logs como:
1712920000 | main.c | main | 18 | INFO | Leitura de temperatura realizada
1712920000 | main.c | main | 21 | ALERT | Temperatura acima do limite!
Agora entramos na etapa mais característica da metodologia: Check Logs.
Aqui, a IA recebe três elementos:
- O conteúdo do REQUIREMENTS.md
- O código atual
- Os logs gerados durante a execução
A partir disso, ela realiza uma análise comparativa. Por exemplo, ela pode identificar:
- O sistema está gerando logs corretamente? ✔️
- O alerta está sendo emitido? ✔️
- Existe validação de erro na leitura de temperatura? ❌
- O tempo de resposta está sendo medido? ❌
Esse tipo de análise vai muito além de testes tradicionais. A IA está efetivamente fazendo uma verificação semântica do comportamento do sistema, algo que se aproxima de técnicas de validação formal, porém com maior flexibilidade.
Com base nisso, ela pode propor melhorias, como:
- Adicionar medição de tempo entre leitura e alerta
- Incluir tratamento de erro na função de leitura
- Refinar o log para incluir o valor da temperatura
O código evoluído poderia ser:
void log_event_with_value(const char* level, const char* file, const char* func, int line, const char* message, float value) {
time_t now = time(NULL);
printf("%ld | %s | %s | %d | %s | %s | %.2f\n",
now, file, func, line, level, message, value);
}
E o log passaria a refletir melhor o estado do sistema:
1712920001 | main.c | main | 18 | INFO | Leitura de temperatura | 55.00
1712920001 | main.c | main | 21 | ALERT | Temperatura acima do limite | 55.00
Esse processo se repete continuamente. A cada execução, novos logs são gerados, analisados e utilizados como base para refinamento. O sistema evolui não apenas com base em testes explícitos, mas através de um ciclo de observação e correção guiado por IA.
Do ponto de vista de engenharia, isso se aproxima fortemente de um sistema de controle adaptativo. A diferença é que, em vez de ajustar parâmetros físicos, estamos ajustando lógica de software. A “planta” é o código, o “sensor” são os logs e o “controlador” é a IA.
É importante destacar um ponto crítico: a qualidade do sistema passa a depender diretamente da qualidade dos logs. Logs pobres, ambíguos ou inconsistentes limitam drasticamente a capacidade da IA de tomar decisões corretas. Nesse sentido, o PDCL exige uma disciplina rigorosa na definição de observabilidade, algo que tradicionalmente é negligenciado em muitos projetos.
Esse exemplo, embora simples, demonstra o poder da abordagem. Em sistemas mais complexos — como firmware com FreeRTOS, aplicações distribuídas ou sistemas com múltiplos sensores — o ganho se torna ainda mais expressivo, pois a IA consegue correlacionar eventos, identificar padrões e sugerir melhorias que seriam difíceis de detectar manualmente.