Hauptgedanke

Eine fachliche Ontologie lässt sich durch eine Kartierung ergänzen: das Konzept Rechnung, verknüpft mit den Klassen, Funktionen, Events und API-Operationen, die an seiner Implementierung mitwirken. Diese Zuordnungen definieren das Konzept nicht; sie sagen, wo es implementiert ist.

Diese Unterscheidung macht Fragen möglich, die keine der beiden Schichten allein beantworten kann. Ändert man das Konzept Rechnung, welche Teile des Codes sind dann möglicherweise betroffen? Verschwindet eine fachliche Funktion, welche Regel ist dann womöglich nicht mehr implementiert? Stellt eine neue API-Operation ein bestehendes Konzept bereit oder bringt sie einen neuen Begriff zum Vorschein? Ist eine umbenannte Klasse ein Refactoring oder eine echte Änderung der Domäne?

Die Kartierung lässt sich im Zuge der Änderungen pflegen, aber jede Zuordnung muss ihren Beleg behalten: die Dateien, Symbole und beobachteten Änderungen, auf denen sie beruht.

Warum das wichtig ist

Die Auswirkungsanalyse hängt nicht mehr vom Gedächtnis der Person ab, die den Code kennt. Und indem man den Beleg verlangt, trennt man zwei Dinge, die ein LLM leicht verwechselt: eine nachgewiesene Entsprechung und eine bloß abgeleitete Beziehung.

Nuancen und Grenzen

Eine von einem LLM abgeleitete Entsprechung sieht genauso aus wie eine nachgewiesene. Ohne angehängten Beleg sammelt die Kartierung plausible Verknüpfungen an, die niemand mehr von den echten unterscheiden kann.

Auch die Kartierung altert: Die Entsprechungen müssen überprüft werden, in einem Rhythmus, den noch nichts festlegt.

Offene Fragen

• Wie oft muss man die Entsprechungen zwischen Konzepten und Code überprüfen, damit sie verlässlich bleiben?