Modulbildung: Strukturierung des Systems auf der Basis von Software-Kategorien

Eine der wichtigsten Aspekte einer guten, das heisst intellektuell beherrschbaren und änderungsfreundlichen, Anwendungsstruktur ist die Aufteilung des Systems auf Softwarekomponenten, die in sich geschlossen und untereinander möglichst lose gekoppelt sind. Eine simple Schichtenbildung, die Aufteilung in logische Paketstrukturen oder Datenkapselung auf Klassenebene sind hierfür zwar notwendig aber bei weitem nicht hinreichend.

Wir brauchen eine Möglichkeit, die vielfältigen technischen und fachlichen Aspekte auf der Basis einfacher Regeln so zu strukturieren, dass das System überschaubar bleibt und die an der Entwicklung beteiligten Entwickler nicht von allen Systemteilen alles wissen müssen. Insbesondere Technikaspekte wie beispielsweise Persistenz oder GUI-Anbindung aber auch Aspekte der Kommunikation mit und die Anbindung von Umsystemen dürfen sich nicht unkontrolliert mit fachlichen Systemteilen mischen.

Ich stütze mich für die folgenden Ausführungen auf die von Johannes Siedersleben in seinem Buch Moderne Software Architektur beschriebenen Software-Kategorien. Diese erlauben es, die Software-Komponenten eines Systems in Wissensgebiete bzw. Themen einzuteilen. Noch wichtiger: sie helfen, die richtigen Software-Komponenten zu finden, da sie das System grob in seine Bestandteile gliedern und damit bei der expliziten Beschreibung der Abhängigkeiten helfen.

Diese Idee deckt sich sehr gut mit den Konzepten des Domain-Driven Design, bei der im Grundsatz die gleiche Idee Pate stand, nämlich der Wunsch nach einer klaren Trennung der fachlichen Domänenaspekte von technischen Belangen, beispielsweise der Datenhaltungsschicht. Allerdings erlauben es die Software-Kategorien in einem übergreifenden Sinne über das eigentliche Domänenmodell hinaus Regeln zu finden, die eine schleichende Durchmischung von orthogonalen Belangen verhindern und bei der Identifizierung der benötigten Komponenten helfen. Software-Kategorien sind die Vorstufe zu Software-Komponenten! Die richtigen Kategorien sind Schubladen, in denen man gefundene Komponenten ablegt. Man schaut sich die Kategorien der Reihe nach an und überlegt, welche Komponenten und welche Schnittstellen man in der jeweiligen Kategorie unterbringen könnte.

Für eine vertiefte Beschreibung der Idee von Softwarekategorien empfehle ich wärmstens Siederslebens Buch; obwohl es bereits 2004 erschienen ist, hat es bezüglich einer sinnvollen, hilfreichen und ordnungsschaffenden Komponentenbildung nichts an Nützlichkeit eingebüsst. Wer Software-Kategorien verstanden hat und als Strukturierungshilfsmittel konsequent nutzt, verbessert die strukturelle Qualität seiner Software! Ich selber strukturiere die von mir entworfenen Systeme seit mehr als 15 Jahren mittels Software-Kategorien. Sie sind für mich zu einem unverzichtbaren Hilfsmittel meiner täglichen Arbeit als Software-Architekt und Entwickler geworden.

0-Software ist im gesamten System vorhanden, sie ist sorgfältig getestet und bietet z.B. grundlegende Abstraktionen wie Strings, Listen, etc. 0-Software darf überall im System verwendet werden. Wir zählen  z.B. Abstraktionen wie String oder das Collection-Framework des .NET Frameworks zu dieser Kategorie. Besonders wichtig sind hier auch Schnittstellen der Kategorie 0, denn sie erlauben die Kommunikation zwischen Softwarekomponenten inkompatibler Schichten.

Als hilfreiche Richtschnur, um zu entscheiden, welche Softwarekomponenten zur Kategorie 0 gezählt werden sollen, offeriert Siedersleben folgenden Ratschlag: Ein Softwarebaustein ist immer dann ein Kandidat für 0-Software, wenn er nur mit geringer Wahrscheinlichkeit ändert und selber ausschliesslich 0-Software verwendet, also keine unerwünschten Abhängigkeiten erzeugt. ([ModerneSoftwareArchitektur], S. 79)

Software-Komponenten, die sich nur mit der eigentlichen Anwendung, also der fachlichen Logik beschäftigen, zählen zur Kategorie A. Die Komponenten dieser Kategorie sind strikte von T-Software abzuschirmen. Kurzgefasst, beschäftigt sich Software der Kategorie-A mit der fachlichen Logik und sonst gar nichts.

Software, die mindestens eine technische API enthält, wird dieser Kategorie zugeordnet; hierzu zählen z.B. die technologieabhängige Transaktionssteuerung, Bibliotheken für die Nutzung von Datenbanken und die Software-Komponenten, die GUI-Widgets einer Bibliothek, z.B. Qt, Swing, HTML etc verwenden. T-Software ist durch die Technik bestimmt und unabhängig von der Anwendung. Das heisst, es findet sich in Software-Komponenten dieser Kategorie keine eigentliche fachliche Logik.

Zwischen unterschiedlichen Repräsentationen von Software-Komponenten muss vermittelt werden; dies kann sowohl innerhalb einer Anwendung als auch im Kontakt zu Umsystemen nötig sein. Auch für die Anbindung an eine Datenhaltungsschicht werden solche Transformationen zwischen Repräsentationen nötig. Software, die diesen Zweck erfüllt, wird der Kategorie R zugerechnet; R steht hierbei für Repräsentation und soll verdeutlichen, dass solche Software-Komponenten sich ausschliesslich um die Transformation zwischen unterschiedlichen Repräsentationen kümmern.

R-Software kennt die zu transformierenden Objekten meist im Detail und benötigt Zugriff auf interne Daten. Hierbei handelt es sich nicht um eine Verletzung der Datenkapselung, denn ein Transformator (Software der Kategorie R) ist als Teil des Laufzeitsystems zu betrachten, und dieses hat schliesslich auch unbeschränkten Zugriff auf sämtliche Attribute eines Objektes, unabhängig von den definierten Sichtbarkeitsregeln. Dieser Punkt ist wichtig, weil wir sonst gezwungen wären, die Datenkapselung auf der Ebene der Schnittstelle einer Komponente mittels entsprechender Get- und Set-Methoden aufzubrechen, um den Zugriff auf interne Daten nur für den Transformator zu ermöglichen, wodurch aber auch andere Objekte, die diese Schnittstelle verwenden, auf die so exponierten internen Daten zugreifen könnten. Genau das wollen wir gerade für A-Komponenten unbedingt vermeiden. Da der Zugriff durch R-Software ausschliesslich der Transformation dient und keine A-Komponenten enthält, kann sie – geeignete Tests vorausgesetzt und von Sabotage abgesehen – keinen Schaden anrichten.

In einem nächsten Beitrag möchte ich zeigen, warum Software-Komponenten wie Blutgruppen sind und, wie diese, nicht beliebig vermischt werden dürfen. Weiter möchte ich näher auf die Frage eingehen, warum ich Software-Komponenten für wichtig halte, wenn es darum geht, die Abhängigkeiten zwischen den einzelnen Elementen in unseren Software-Systemen überschau- und kontrollierbar zu halten.