Auftrag ist, einen bestehenden Prozess zu ersetzen, weil dieser Prozess eine aktive grafische Benutzeroberfläche erzwingt. Der Ersatz muss komplett im Backend laufen können. Ausserdem sagt mein Chef, dass es weitere bestehende Prozesse gibt, die ähnlich sind und die später auch abgelöst werden sollen.
Erster Schritt ist, den bestehenden Prozess zu verstehen, eine Lotus-Script-Funktion mit fast 300 Zeilen. Schnell ist klar, dass es wesentlich darum geht, über eine Auswahl von Notes-Dokumenten zu iterieren. Die Iteration enthält acht Schritte: Die ersten vier prüfen unterschiedliche Vorbedingungen, die letzten vier werden nur ausgeführt, wenn alle Vorbedingungen erfüllt sind.
Zweiter Schritt ist, einen Plan für die Modellierung des neuen Prozesses zu erstellen. Was getan werden muss ist klar, siehe Schritt Eins. Aber wie soll es geschehen? Ich entscheide mich für Objektorientierung mit Java und gegen prozedurale Programmierung in Lotus Script.
Und nun die Gretchenfrage, die eigentliche Modellierung: Welche Objekte kommen vor und wie arbeiten sie zusammen? Ich könnte vom Notes-Dokument ausgehen, dessen Java-Interface in der API verfügbar ist. Oder stelle ich den Prozess in den Vordergrund? Ich habe mich für den Prozess entschieden. Der Prozess verwandelt Schritt für Schritt ein Notes-Dokument. Die Programmierung der Notes-Dokument-Klasse lasse ich unverändert.
Der Unterschied ist nicht gross. Der Startpunkt des Ablaufs liegt bei meinem Modell im Prozess-Objekt, nicht im Datenobjekt. Das entspricht zwar nicht der “reinen Lehre” der Objektorientierten Modellierung, hat aber Vorteile:
1) Wer den alten Prozess kennt, der findet sich in der neuen Programmierung schnell zurecht.
2) Die Rede- und Denkweisen im Unternehmen orientieren sich am Prozess, nicht an den Datenobjekten. So ist die Verständigung einfacher.
3) Andere neue Prozesse können Teile dieses neuen Prozesses nutzen, und ich muss dazu nicht umdenken.
Apropos “reine Lehre”: Es gibt Leute, die meinen, dass Substantive in einem Modell zu Klassen werden und Verben zu Methoden. Dieser Ansatz ist nur in Grenzen hilfreich, denn “document.createPDF” und “PDFcreator.execute” können gleichbedeutend sein.
Der neu programmierte Prozess folgt dem alt-bekannten Muster Eingabe-Verarbeitung-Ausgabe. Das Prozess-Objekt liest aus einer Datenquelle. Die Verarbeitung ist mit Hilfe des Wrapper-Patterns abgebildet, so dass beliebige Schritte nacheinander durchgeführt werden können. Und auch die Ausgabe ist mit Hilfe des Wrapper-Patterns abgebildet, so dass unterschiedliche Ausgaben in unterschiedliche Datensenken geschrieben werden können.
Der neue Code ist gekapselt und lose gekoppelt. Er tut, was der alte auch tat. Ist aber leichter zu verstehen, die Teile sind wiederverwendbar, und er kommt ohne GUI aus.
Mission erfüllt.