Das Zugpferd steuern

Es gibt einen Rahmen, in dem ich das Pair Programming mit KIs wie ChatGPT sehe. Im ersten Teil dieser Artikelserie [1] habe ich ihn so beschrieben: „Anforderungen verstehen, Lösungsansätze daraus ableiten, daraufhin modularisieren und dann durch geschicktes Prompt Engineering Chat­GPT den nervigen Kleinkram übernehmen lassen: So sehe ich die Softwareentwicklung in nächster Zukunft. Der Mensch fürs Grobe, für den Überblick und als Supervisor, die KI für die nitty gritty details.“

Dass Sie einer KI Hunderte Seiten Anforderungen vorlegen und die daraufhin fehlerfreien Code produziert, ist in nächster Zeit wohl nicht zu erwarten. Das hat weniger mit der Leistungsfähigkeit von ChatGPT zu tun – begrenztes Kontextfenster, schwachbrüstig bei Computation –, sondern mit der Impräzision von Anforderungen und Grenzen der Testabdeckung.

Daraus folgt für mich: ChatGPT ist ein Programming Buddy, den ich nicht missen möchte. Doch es braucht ein Vorgehen, das seinen Fähigkeiten und Grenzen gerecht wird. Das nenne ich Requirements-First Development (RFD) und habe es im vorhergehenden Artikel skizziert. Nachfolgend möchte ich es an einem nichttrivialen Beispiel demonstrieren.

Da meine Frau und ich gerade dabei sind, Spanisch zu lernen, wähle ich als Beispielszenario ein Programm, das helfen soll, Vokabeln zu pauken: eine sogenannte Flashcard-App. Vokabeln mit Karteikarten zu lernen ist effektiver, als sie in einer Liste immer wieder durchzugehen. Den Ansatz des Spaced Repetition Learning [6] habe ich bereits als Schüler im Buch „So lernt man lernen“ von Sebastian Leitner kennengelernt. Natürlich gibt es schon viele Flashcard-Apps online oder fürs Smartphone. Mir gefällt Repetico [7] besonders gut. Doch eine eigene App ist nochmal etwas anderes, oder?

Ich stelle ich mir die App wie im Kasten Anforderungsskizze für eine Flashcard-App skizziert vor. In dem Szenario ist ein bisschen Benutzerschnittstelle dabei, sie kann in einem Terminal-Fenster laufen, es gibt ein bisschen Persistenz und etwas Domänenlogik.

Wie würden Sie jetzt vorgehen? Wie lange würden Sie allein für die Implementation brauchen? Ich meine eine saubere Implementation, keinen Prototyp, also eine, in der es auch Tests gibt und Struktur erkennbar ist. Denn wer weiß … vielleicht soll der Code ja weiterentwickelt werden. Mir schwebt da zum Beispiel für die Zukunft eine Unterstützung beim Lernen durch KI vor, wie ich sie schon in meinem Online-Spanischkurs Spanish Day by Day [8] einsetze.

Wenn ich just for fun diese Anforderungen eins zu eins an ChatGPT gebe, dann ist das Ergebnis schon beeindruckend, finde ich [9]. Das Programm ist aus dem Stand lauffähig und erfüllt die Anforderungen an Spaced Repetition Learning grundsätzlich.

Allerdings hat sich ChatGPT einige Freiheiten genommen beziehungsweise nicht genau hingeschaut:

Mit diesem Code könnte ich jetzt weiterarbeiten. ChatGPT würde ihn für mich refaktorisieren und auch Tests schreiben. Doch mir scheint das erstens umständlicher, als wenn ich gleich strukturierter vorgegangen wäre. Zweitens ist das Ergebnis auch nur so positiv, weil die Anforderungen immer noch überschaubar sind. Für einen Prototyp ist das Ergebnis völlig okay. Insofern bin ich auch froh, es mit den kompletten Anforderungen einmal probiert zu haben. ChatGPT hat mir Informationen beschafft:

Um ChatGPT auf testbare Module ansetzen zu können, muss ich diese identifizieren. Ich muss selbst die Anforderungen analysieren und daraus Modulideen ableiten. Damit folge ich dem Prinzip Separation of Concerns. Das Single ­Responsibility Principle [10] hilft mir, Module zu erkennen: Sie stehen für die großen Entscheidungen des Kunden, die in den Anforderungen stecken.

Ich bevorzuge beim Herangehen an Anforderungen ein Softwarezellendiagramm wie in Bild 7. Es stellt das Softwaresystem in einen Kontext: Anwender benutzen das Softwaresystem, das Softwaresystem benutzt Ressourcen. Indem ich die Kontaktpunkte des Softwaresystems mit der Umwelt aus den Anforderungen herausarbeite, kann ich tiefergehende Fragen dazu stellen, wie die Kommunikation dort genau aussehen soll.

Benutzer in ihren Rollen und alle Ressourcen werden später im Code durch Module repräsentiert. Dazu kommt mindestens ein Modul für die Domäne, den Kern des Softwaresystems. Wenn ich mit dieser Brille an Anforderungen herantrete, wird bereits ein Teil des Entwurfs sichtbar. Das finde ich sehr bequem und geradlinig.

Dass es ein Modul geben sollte, das ein Kartenset lädt/speichert, ist nicht überraschend. Aber in der Umwelt liegen weitere Ressourcen, die ich daran erkenne, dass APIs nötig sind, um Daten zu beschaffen:

Nicht überraschend ist ebenfalls, dass die Benutzerschnittstelle mindestens ein eigenes Modul braucht. Darin stecken so viele Entscheidungen, dafür sind wieder andere APIs nötig, diese Logik muss für Tests anderer ausgeblendet werden können. Aufgefallen ist mir bei der Strukturierung der Softwarezelle jedoch, dass die Anforderungen gar keine konkrete Aussage zur Interaktion mit dem Programm machen. Eine Desktop-Anwendung reicht aus. Aber was für eine? Soll es ein GUI geben, oder reicht eine Ausführung in einem Terminal-Fenster? Ich entscheide mich für die einfachere Variante: das Terminal-Fenster, also eine Konsolenanwendung. Und wie sehen dort die Dialoge aus? Denn Dialoge gibt es nicht nur bei GUI-Anwendungen. Mir schweben zwei Dialoge vor (Bild 8): einer, um eine Lernsitzung zu starten, der andere, um die Lernsitzung durchzuführen. In der Lernsitzung werden die Karten eine nach der anderen vorgelegt und beurteilt.

Im nächsten Schritt muss ich die Dialoge verfeinern: Wie sehen die Interaktionen genau aus? Was zeigt das Programm, was gibt der Benutzer ein, wie und wann triggert er Logik im Programm, damit etwas mit seinen Eingaben passiert? Mich interessieren die Entry Points der App. Bild 9 zeigt, wie ich mir die Konkretisierung der Dialoge vorstelle:

Technisch wird die Umsetzung der Dialoge einfach sein. Dennoch brauche ich Klarheit darüber, wann welche Entry Points getriggert werden. Ich erkenne zwei (Bild 10):

Das ist ein Ergebnis der Analyse – aber sie sagt etwas über eine Modulschnittstelle aus, wie später zu sehen sein wird.

Nicht nur die Benutzerschnittstelle hat Struktur. Die Ressourcen haben auch eine, die ich in der Analyse erkunden kann. Wie sehen zum Beispiel Lernkarteikarten aus, um sie mit einem Spaced-Repetition-Learning-Algorithmus wieder vorzulegen? Die Softwarezelle mit den auf ihrer Grenze und darin platzierten Modulen ist für mich wie eine Schnittstelle. Ich muss alle Berührungspunkte mit der Umwelt und den Kern nacheinander abarbeiten und mir dazu passende Fragen stellen.

Die erste Frage ist die nach dem Zweck: Was wird in dem Modul gekapselt? Die zweite ist die nach den dafür nötigen Datenstrukturen. Kann ich die schon in der Analyse erkennen, weil sie irgendwie in den Anforderungen stecken? Oder ist das eine Sache des Entwurfs?

Für die Kartensätze liegt die Struktur nahe, denke ich. ­Alle Angaben, die für eine Sitzung und den Wiedervorlagealgorithmus wichtig sind, stehen in den Anforderungen. Bild 11 zeigt die Struktur mit ein paar Beispielen.

Der Einfachheit halber habe ich die Struktur als CSV-Text notiert. Eine JSON-Codierung ist aber genauso möglich. Der Vorteil von CSV: Es lässt sich sehr leicht mit Excel herstellen. Der Vorteil von JSON: Es lässt sich leichter als CSV einlesen und speichern.

Die Datenstrukturen für die Zeit und die Wiedervorlagekonfiguration sind noch einfacher.

Wenn die Entry Points das API der Benutzerschnittstelle sind, wie sehen dann die APIs der Ressourcenadapter aus? Das ist keine Sache der Anforderungsanalyse. Sie richten sich nach dem Bedarf, den das Innere der App hat. Dass die Ressourcen gebraucht werden, ist klar. Wie genau sie gebraucht werden, ist nicht klar. Das stellt sich erst im Entwurf heraus, der das Innenleben modelliert.

Das API der Benutzerschnittstelle hingegen befriedigt den Bedarf der Benutzer. Was diese wollen, beschreiben die Anforderungen. Deshalb sind die dortigen Entry Points ein Ergebnis der Anforderungsanalyse.

Selbstverständlich gehört zur Anforderungsanalyse auch eine Betrachtung dessen, was wo passieren soll. Wenn schon Module identifiziert werden können, dann kann ich mir auch eine Idee davon machen, was sie tun sollen. Das ist für die Adapter auf der Peripherie der Softwarezelle trivial:

Für diese Anwendung ist das alles einfach nachvollziehbar, denke ich. Interessanter ist die Domäne, das heißt der Lernalgorithmus. Der steckt im Kern der Softwarezelle. Worum geht es dabei?

Nach diesem genaueren Blick auf die Anforderungen fühle ich mich bereit für die nächste Phase, den Entwurf.

Im Entwurf geht es darum, die Lösung zu modellieren. Sie wird nicht codiert, sondern nur durch ihre Bausteine deklarativ beschrieben. Der Entwurf beantwortet die Fragen:

Ausführlich habe ich den Entwurf in meinem Buch „Softwareentwurf mit Flow-Design“ [11] beschrieben. Hier kann ich darauf nur mit Skizzen und Beispielen eingehen. Da die Zielsprache TypeScript ist, können Module nicht nur Klassen sein, sondern auch .ts-Dateien. Für beide lassen sich Interfaces definieren, das heißt Unterschiede machen zwischen Öffentlichem und Privatem (Gekapseltem).

Beziehungen sind vor allem Nutzungsbeziehungen: Welcher Baustein benutzt welchen anderen als Dienstleister? Anders ausgedrückt: Welche Abhängigkeitsverhältnisse existieren zwischen den Bausteinen? Hier muss ich aufpassen, damit der Code sauber bleibt. ChatGPT traue ich nur begrenzt ein Bewusstsein in dieser Hinsicht zu. Das Integration Operation Segregation Principle (IOSP) [12] und die IODA-Architektur [13] beziehungsweise die darauf basierende Sleepy-Hollow-Architektur wird es nicht ohne weitere Anleitung berücksichtigen.

Aber was leistet ChatGPT eigentlich in Bezug auf den Entwurf? Kann ich die KI fragen, welche Module die Anwendung haben sollte? Ich habe das mal versucht [14] und finde das Ergebnis nicht schlecht (Bild 14). Hier hat ChatGPT sogar erkannt, dass es eine Konfiguration gibt. Was allerdings fehlt: ein Modul für die Systemzeit. Unbedarft sollte ich also eine solche Frage nicht stellen. Mindestens sollte ich den Prompt mit einigen allgemeinen Hinweisen zur Modularisierung spicken. Allerdings finde ich die Modularisierung jedoch nicht so aufwendig. Ich habe nicht den Eindruck, Zeit verschwendet zu haben. Letztlich bin ich als Entwickler für die Software verantwortlich; da steht es mir gut zu Gesicht, dass ich mich mit den Anforderungen solide auseinandersetze.

Für diese Anforderungen sind die Module also im Wesentlichen bekannt. Die Arbeitspferde sind identifiziert. Worauf es im Entwurf ankommt, ist die Definition ihrer Schnittstellen. Was muss ich tun, um sie zu bestimmen?

Im Flow-Design [11] schaue ich mir eine Funktion an und überlege, wie sich ihre Arbeitsweise als Datenfluss realisieren lassen könnte. Nach der Anforderungsanalyse sind mir nur die Entry Points als Funktionen bekannt; sie zu finden ist das Ziel der entwicklerorientierten Anforderungsanalyse, die ich Slicing nenne. Formalisiert sehen die Entry Points zum Beispiel in TypeScript so aus:

Sie gehören nach der IODA-Architektur [13] zum Prozessor-Modul, das die Leistungen des Body der Sleepy Hollow Architecture [13] definiert. Das Prozessor-Modul integriert sowohl die Module der Domäne wie auch den Ressourcenadapter (Bild 15).

Wie komme ich nun zu einem Datenfluss-Transformationsprozess für die Entry Points, der den Input von der Benutzerschnittstelle umwandelt in einen Output für sie – plus Änderungen des Anwendungszustands in der Datenbank, dem gewählten Kartensatz?

Das ist kreative Entwurfsarbeit. Das ist meine Domäne als Mensch. Oder? Vielleicht kann ChatGPT aber auch dabei unterstützen? Auf Nachfrage liefert ChatGPT tatsächlich ein sehr brauchbares Ergebnis (Bild 16). Dafür war allerdings ein bisschen mehr Aufwand nötig; zero-shot prompting war mir zu riskant [15]. Stattdessen habe ich ChatGPT über mehrere Prompts hinweg zuerst die Anforderungen gegeben und die Module genannt, die ich gefunden habe, dann habe ich die Entry Points beschrieben und schließlich habe ich mir einen Datenfluss für die Start-Funktion gewünscht [16]:

Um ChatGPT nicht auf falsche Gedanken zu bringen, habe ich den Begriff Datenfluss jedoch vermieden und einfach nur von Schritten gesprochen. Ich habe mich des Prompt Stacking [17] bedient: Das war für mich einfacher, weil ich nicht alles in einen Prompt stecken musste. Das war für ChatGPT einfacher, weil dadurch sein Kontext langsam wachsen konnte. Wie beim Chain-of-Thought Prompting [18, 19] hilft eine solche Aufteilung nach meiner Erfahrung, größere Zusammenhänge für ChatGPT verdaubar zu machen, auch wenn keine Zwischenergebnisse produziert werden (das wäre Prompt Chaining gewesen [20]).

Integriert bilden die von ChatGPT vorgeschlagenen Schritte den Datenfluss in Bild 17. Das hätte ich kaum besser entworfen. Alle Funktionseinheiten passen zusammen.

Nur eine kleine Ungereimtheit fällt auf: Meine Definition des Start-Entry-Point enthält ein Flag (useDueCards) für die Auswahl der Karten für die Sitzung: Sollen es die fälligen (true) oder die neuen (false) sein? Wer hat hier nicht aufgepasst? Das war ich. Dass man sich bei Sitzungsstart aus einem Kartensatz die eine oder andere Untermenge wünscht, taucht zwar in meiner Anforderungsanalyse auf (Bild 9), doch davon steht nichts im Anforderungstext. Also kann ChatGPT es nicht wissen und nicht bei der Signaturdefinition der Schritte berücksichtigen. Ein klassischer Fall von fehlender Information. Für ChatGPT war das ein unknown unknown.

Doch das Problem ist ja klein. Ich muss mich nur entscheiden, ob ich diese Information dem Provider für Kartensätze mitgebe (loadCardSet), damit der gleich die gewünschte Untermenge liefert. Oder ob die Information besser an die Domäne übergeben werden sollte (selectInitialCard).

Eine Übergabe an den Provider scheint mir nur sinnvoll, wenn die Menge der Karten in einem Satz sehr groß ist, sodass eine Filterung möglichst nah am Persistenzmedium stattfinden sollte (zum Beispiel mit einer SQL-Abfrage). Das ist jedoch nicht der Fall, selbst dann nicht, wenn es sich um 10 000 oder mehr Karten handeln sollte. Für mehr Flexibilität geht deshalb diese Information an die Domäne.

Die Funktionseinheiten passen also zusammen. Sie stellen komplementäre Bausteine dar, die in einem Fluss verdrahtet zusammen die Leistung von startSession erbringen. Chat­GPT kennt schon die Modulzugehörigkeit. Damit sind deren Interfaces für dieses erste Inkrement fast definiert. Es fehlen nur noch die Details für die In-Memory Datenstrukturen.

Danach gefragt [21] liefert ChatGPT die Antwort in Bild 18. Auch das passt für mich weitgehend:

Für einen ersten Durchstich ohne Benutzerschnittstelle liegen alle Funktionen und Module vor. Soll ich zur Implementation voranschreiten? Im Sinne inkremenellen Vorgehens wäre das normal. An dieser Stelle entscheide ich mich jedoch dagegen, weil ich für das Medium Artikelserie lieber die Phasen abschließen möchte.

Aus Gründen der Darstellung wähle ich also den Wasserfall. Deshalb weiter mit dem Datenfluss für den zweiten Entry Point. Dazu führe ich am besten den Chat fort, der mir schon die ersten Funktionen geliefert hat [21]. Ich frage nun nach den Schritten für den zweiten Entry Point (Bild 19). Dieses Mal bin ich etwas spezifischer, indem ich die Signatur des Entry Points angebe und nochmal seine Funktion skizziere.

Das Ergebnis kann sich wieder sehen lassen, finde ich. Die Schritte hören sich sinnig an. Bild 20 zeigt den daraus abgeleiteten Datenfluss. Es passt alles zusammen.

Allerdings – und jetzt bin ich froh, dass ich nicht schon zur Implementation fortgeschritten bin – irgendetwas ist doch nicht ganz so, wie es sein sollte. Ein genauerer Blick ist nötig.

Was bisher auch fehlt, ist Funktionalität auf Datenstrukturen. Die Configuration und das CardSet sind für mich Kandidaten, die Logik enthalten dürfen. Sie als Datenstrukturen dumm zu halten würde einer Primitive Obsession [22] Vorschub leisten.

Zum Entwurf gehört auch, die Logik klug auf Verhaltens- beziehungsweise Datenmodule zu verteilen. Datenmodule (Datenstrukturen) sind Daten, können als abstrakte Datentypen aber auch etwas Logik [23] enthalten. Verhaltensmodule haben gegebenenfalls Daten, sind jedoch vor allem Container für Logik. Ich denke, damit bin ich an einem Punkt im Entwurf, wo ich meine Erkenntnisse aus der Analyse und ChatGPTs Vorschläge konsolidieren sollte. Ich will es selbst unternehmen, die finalen Modulschnittstellen zu definieren.

Welche Module gibt es, was sollen sie leisten?

Die Zusammenarbeit dieser Module sieht für mich nach der IODA-Architektur wie in Bild 21 aus. Entscheidend für die Testbarkeit ist, dass keine Abhängigkeiten zwischen den Arbeitspferden der Ebene Operation existieren [12]. Der Prozessor integriert diese nur noch zu übersichtlichen Prozessen in Form von Datenflüssen.

Mit dieser Übersicht fühle ich mich gut aufgestellt, um die Schnittstellen selbst in Code zu gießen. Sie sollen meine späteren Ausgangspunkte für ChatGPTs Codierungsdienste sein. Dass ich ChatGPT ein TypeScript-Projekt mit den Dateien für die Module und den Schnittstellendefinitionen generieren lasse, sehe ich nicht. Dafür gibt es doch noch hier und da Dinge, die ich geradeziehen muss. ChatGPT die zu erklären ist umständlicher, als es selbst zu machen. Und dieser Teil der Codierung ist auch nicht aufwendig. Vielmehr sehe ich ihn als Gelegenheit zur Reflexion; damit bekomme ich einen soliden Stand für die nächste Phase.

Bild 22 wirft ein paar Schlaglichter auf die Implementation der Schnittstellen. Ich habe dafür in WebStorm ein Type­Script-Projekt für die Deno Runtime aufgesetzt. Die meisten Verhaltensmodule haben ein Interface als Schnittstellendefinition. Nur Processor und Session weichen davon ab. Beide müssen in Tests nicht durch Surrogate ersetzt werden.

Nach dem Bisherigen war es geradlinig, die Schnittstellen zu codieren. Nur bei einem Modul bin ich vom Entwurf abgewichen. Ich denke, hier hat sich ausgezahlt, dass ich nochmal darüber nachdenken konnte. Die Session sieht nun durchaus anders als die erste Idee aus (Bild 23).

Analyse und Entwurf sind damit abgeschlossen. Die Implementierung kann beginnen. Für ChatGPT werden die Interfaces und Klassenrümpfe eine solide Grundlage sein, um die Methoden eine nach der anderen zu codieren und mit Tests zu versehen. Für jede einzelne werde ich gezielt Anforderungen formulieren.

Ich denke, der Aufwand bisher war sehr überschaubar. ChatGPT hat im Konzeptionellen sogar mehr unterstützen können, als ich zunächst gedacht hatte. Doch es ist mir auch noch mal klar geworden, dass mein Beitrag als Mensch nicht überflüssig wird. ChatGPT will an die Hand genommen werden. Es braucht Augenmaß. Und es braucht auch ein Gespür für den Trade-off zwischen manueller und beauftragter Arbeit: ChatGPT könnte vielleicht sogar mehr – doch dafür müsste ich die Prompts sehr ausführlich formulieren und in einem Dialog noch nachlegen. Da ist es in vielen Fällen schneller, das Ergebnis selbst zu finden. Im nächsten Teil der Artikelserie kann ChatGPT aber endlich zeigen, aus welchem Holz es als Codierer geschnitzt ist. Ich bin gespannt, wie es mit meiner Vorarbeit zurechtkommt.