Artur Södler Software-Qualität

Modularisierung und Schnittstellen

"Durch die Modularität von komplexen Systemen lässt sich deren Verständlichkeit für den Menschen erhöhen." [Quelle: wikipedia]

Das mag richtig erscheinen, doch genau andersherum wird ein Schuh daraus. Menschen denken bereits modular, deshalb begreifen sie genauso strukturierte Systeme leichter.

Machen wir einen Ausflug zum Marketing: Werner Kröber-Riel beschreibt in seinem Standardwerk "Konsumentenverhalten" auf 176 Seiten ausführlichst, wie Menschen Informationen verarbeiten. Die Essenz: Mehr als fünf oder sechs "Dinge" kann der Mensch nicht gleichzeitig überblicken. Besteht eine Programm-Suite aus mehr als 5-6 Programmen, oder ein Hauptmenü aus mehr als 5-6 Untermenüs, oder ein Untermenü aus mehr als 5-6 Punkten, oder ein Dialog aus mehr als 5-6 [...], dann haben wir es erheblich schwerer, den Überblick zu behalten.

Folglich sind die Programm-Quelltexte optimal in 5-6 Unterverzeichnissen mit bis zu 5-6 Quelltexten organisiert, darin vielleicht maximal je 5-6 Klassen mit 5-6 Methoden, diese enthalten höchstens 5-6 Blöcke zu je 5-6 Anweisungen usw. Nehmen Sie es nicht ganz so ernst — dennoch: die Richtung stimmt.

Hier ein paar weitere Tipps:

•		Universalbausteine Es ist wichtig, über den Tellerrand zu blicken. Module, die auf den speziellen Einsatzzweck abgestimmt sind, sind selten wiederverwendbar. Eine Datumseingabe, die Säkularjahre nicht kennt, kann beim Grundbuchamt nicht verwendet werden, denn es gibt Dokumente von 1900 und früher. Dann kann neben dem gregorianischen Kalender auch der julianische berücksichtigt werden, oder auch der römische. Der buddhistische?. Nehmen Sie als Regel: Soweit Sie glauben, dass es jemals für Ihre Zwecke nötig ist, und ein bißchen mehr. Denn der Aufwand der Korrektur im Nachhinein ist immer größer, als es von vornherein zu gut zu machen.
•		Schnittstellen sichtbar machen. Die FiBu holt den Kontoauszug per HBCI im MT940-Format. Dieser wird weiterverarbeitet und in Buchungen umgesetzt. Wenn Sie den Zwischenschritt, die MT940-Datei, zur Verfügung stellen, kann ein gewiefter Anwender schnell feststellen, warum seit Dezember 2013 die Umlaute falsch übernommen werden: Die Sparkasse hat die Kodierung von ISO-8859-1 auf UTF-8 umgestellt, und dabei das "byte order mark" vergessen. Und wenn Sie vergessen haben, mit einem byte order mark umgehen zu können, kann der Anwender schnell Abhilfe schaffen, bis Sie das nachgerüstet haben.
•		Entwicklungsdokumentation nutzen. Beim Design einer Software entstehen viele Dokumente. Die meisten davon schimmeln schon während der Entwicklung vor sich hin. Sobald man feststellt, dass Kurskorrekturen notwendig sind, fließen diese nur noch in den Quellcode ein, die Entwurfs-Dokumente werden selten angepasst. Nehmen Sie sie ruhig mit in die Quellcode-Verwaltung, oder bewusst in den Quellcode. Mancherorts wird sogar die Dokumentation mit Werkzeugen aus den Quellcodes der Software generiert. Entwickeln Sie die Entwicklungsdokumentation fort zur Anwenderdokumentation. Egal wie — aber nutzen Sie die eigene Dokumentation!
•		Schittstellen sind schlank. Überlegen Sie sorgfältig. Welche Parameter sind so selbstverständlich und weitgreifend, dass sie besser in thread-globalen Daten aufgehoben sind? Welche Parameter sind für Spezialfälle, die selten gebraucht werden? Welche Parameter können vereinfacht werden (z.B. Typ "Auswahl" statt "Text")? Dokumentieren Sie bei allen Zeigern auf dynamische Daten, wer wann den Speicherplatz reserviert und wieder freigibt. Anlegen und Freigeben einer Ressource sollen immer auf der gleichen Seite einer Schnittstelle stattfinden.
•		Module prüfen die Parameter an den Schnittstellen. Schlechte Qualität: Fehlerhafte Daten führen zum Absturz. Mittlere Qualität: Fehlerhafte Daten führen zu fehlerhaften Ergebnissen. Gute Qualität: Fehlerhafte Daten werden frühzeitig erkannt, dadurch wird Fehler-Diagnose wesentlich erleichtert. Fanatiker prüfen zusätzlich die Ergebnisse, gute Programmierer geben sich meist damit zufrieden, wenn sie beweisen können, dass die Ergebnisse richtig sein müssen.
•		intelligente Protokolle Noch einen Schritt weiter: Protokollieren aller Schnittstellendaten. Dadurch lässt sich auch im Nachhinein stets herausfinden, in welchem Modul welches Problem aufgetreten ist. Damit die Datenflut beherrschbar bleibt, können die wichtigsten Daten beim Schreiben und auch beim Auslesen des Protokolls gefiltert werden. Beispiel: Ein Protokoll von Speicheranforderungen und ‑freigaben, das automatisch die freigegebenen Speicherblöcke wieder aus dem Protokoll löscht. Übrig bleibt alles, was nicht freigegeben wurde.
•		Kontext-Information Wenn jedes wichtige Modul Kontextinformationen hinterlässt, kann man diese für Protokolle und für Fehlerinformationen verwenden. Das funktioniert top-down, genau umgekehrt wie das Anreichern der Fehlerinformationen mit den Informationen über die Auswirkungen.
•		Designfehler gründlich korrigieren Wenn Sie feststellen, dass eine Modul-Schnittstelle nicht optimal ausgelegt ist — handeln Sie frühzeitig und durchgreifend. Werfen Sie Altlasten so schnell wie möglich über Bord. Entwerfen Sie bewußt Methoden, sicherzustellen, dass alle betroffenen Module angepasst werden. Falls Software auch modular ausgeliefert wird: Entwerfen Sie Methoden für ein Rollout der Änderungen. Denn sobald Software-Entwickler die Folgen von Korrekturen fürchten müssen, wird nicht mehr korrigiert.