Ideia principal

A coerência entre o código de um software e o seu modelo de domínio costuma ficar implícita. Uma ontologia mantida em relação ao código permite torná-la observável com algumas medidas: a cobertura da ontologia, ou seja, a parcela dos conceitos de negócio identificados no código que têm uma representação na ontologia; a rastreabilidade, ou seja, o número de conceitos ligados à sua implementação por referências verificáveis; o número de incoerências confirmadas e não resolvidas, que dá uma ideia da deriva; e a proporção de invariantes associados a testes executáveis, que mede a solidez da rede de segurança.

Nenhuma dessas medidas é um indicador de qualidade absoluto. Todas dependem de uma mesma capacidade: distinguir um conceito de negócio de verdade de uma classe, de uma tabela ou de um pacote que é só um detalhe técnico.

Por que isso importa

Essas medidas oferecem uma alternativa à contagem de linhas de código numa época em que os agentes produzem muitas delas: acompanhar a coerência conceitual de um software ao longo das suas evoluções, e não o seu volume.

Nuances e limites

Se a triagem entre conceito e ruído técnico for ruim, cada indicador mede ruído com precisão. Os números valem o que vale essa triagem, e ela é feita em parte por um LLM.

Questões em aberto

• Um indicador de cobertura da ontologia resiste ao reflexo de otimizá-lo por ele mesmo, acrescentando ao modelo conceitos que não são conceitos?