Software als System VII - Logische Strukturierung

Swolons mit ihrer Funktionalität und ihren Zuständen lassen sich in zwei Arten einteilen: logische und physische Swolons.

Logische Swolons haben keine bzw. nicht notwendig eine Entsprechung "in der Codewelt". Sie sind lediglich Hilfskonstrukte zur Gliederung einer Software. Ich nenne sie mal Module, weil der Begriff nur relativ wenig besetzt ist. Jede Software kann dann als Hierarchie von Modulen beschrieben werden. Jedes Modul kann aus beliebig vielen Submodulen bestehen. Dasselbe Submodul kann in mehreren Modulen enthalten sein.

Jedes Modul hat eine möglichst klare Aufgabe und entsteht im Prozess einer schrittweisen Dekomposition oder Verfeinerung. Das Wurzelmodul ist die zu entwickelnde Lösung; sie wird in Funktions- oder Verantwortlichkeitsbereiche zerlegt. Diese Module werden dann wiederum in kleinere Funktions- oder Verantwortlichkeitsbereiche zerlegt und so weiter...

Diese Art der Zerlegung eines Systems in immer kleinere Bestandteile ist im Laufe der letzten Jahre leider in Verruf geraten, nicht agil genug zu sein. Dieser grundsätzlichen Kritik kann ich jedoch nicht folgen. Agilität ergibt sich nicht einfach aus dem Verzicht auf eine hierarchische Strukturierung/Planung von Software. Sie ist vielmehr eine Frage des Umgangs mit ihr. Und das ist eine Frage des Entwicklungsprozesses - den ich an dieser Stelle jedoch zunächst ausklammern möchte.

Unabhängig vom Prozess halte ich es für unabdingbar, auch ein Softwaresystem (wie jedes andere komplexe System) sauber in logische Bestandteile zu zerlegen. Die Zerlegungstiefe soll dabei problemangemessen sein. Ziel ist es, schrittweise zu Funktionseinheiten zu kommen, deren Aufgabe klar und überschaubar ist, die einen abschätzbaren Implementationsaufwand haben.

Dabei ist ganz wichtig zu beachten, dass Module eben keine Klassen sind. Module sind logische Swolons, Klassen physische. Die logische Dekomposition findet also losgelöst von einer konkreten Implementierung und Entwicklungsplattform statt. Leitmotiv sollte dabei lediglich sein, Kompliziertes in Einfacheres zu zerlegen. Da Software immer eine Funktion hat, sind Module für mich daher immer zuerst Funktionsträger. Sie stehen für eine möglichst klar umrissene Dienstleistung. Sie sind verantwortlich für ihre Erbringung. Diese Dienstleistung kann natürlich mal mehr funktionsorientiert und mal mehr zustandsorientiert sein.

Jede Ebene im Modulbaum kann auch als Abstraktionsebene angesehen werden. Die Dienstleistung der Module in einer Ebene sollten dann in Bezug auf diese Ebene möglichst klar umrissen sein. Konjunktionen wie "und" und "oder" sollten in Funktionsbeschreibungen nicht vorkommen. Die Summe der Funktionen aller Submodule entspricht dann wieder der Gesamtfunktionalität ihres Moduls.

In Bezug auf seine Submodule ist die Dienstleistung eines Moduls jedoch eher grob und unscharf. Die Submodule präzisieren sie. Ein Beispiel:

Auf der obersten Abstraktionsebene geht es nur um einen online Shop. Die Ebene darunter präzisiert: zu einem online Shop gehören Produkte, Bestellungen dieser Produkte und die Wahrung der Sicherheit des Bestellvorgangs. Und was genau bedeutet "Wahrung der Sicherheit"? Das präzisiert die darunterliegende Abstraktionsebene. Laut ihr gehören eine Benutzerverwaltung und die Authentifizierung bzw. Autorisierung von Benutzern dazu.

Die Modularisierung einer Software ist sozusagen eine sich schrittweise in das Problem hineingrabende Bestandsaufnahme der Verantwortungsbereiche oder "Abteilungen", die nötig sind, um am Ende einen Nutzen für den Anwender herzustellen. Software kann in diesem Sinn auch als Unternehmen oder Fabrik - software as a factory - angesehen werden: Ihre Produkte sind Dienstleistungen für den Anwender. Der wünscht sich z.B. die Aufnahme eines Artikels in den Warenkorb und die Software erfüllt ihm diesen Wunsch. Oder der Anwender "bestellt" die Umsetzung einer Verkaufszahlenliste in eine Grafik und die Software produziert diese Grafik.

Geleistet werden solches Services von, hergestellt werden solche Produkte durch das Zusammenspiel vieler Swolons mit sehr unterschiedlichen Verantwortlichkeiten und auf unterschiedlichen Abstraktionsebenen. Blätter des vorstehenden Modulbaumes können daher auch als Aufgabenbereiche zu einem "Unternehmen" zusammengesetzt werden:

Eine Modulhierarchie kann insofern auch als Orga-Diagramm angesehen werden. Und die Knoten darin sind Rollen. Damit bewegt sich die logische Strukturierung in der Nähe von OORAM - Object Oriented Role Analysis Method -, verzichtet aber auf die Bindung an ein Implementationsdetail wie Objekte. Während Modularisierung geht also eher und allgemeiner um eine Swolon Rollenanalyse.

Module sind auf allen Ebenen der Modulhierarchie gleich. Es sind Swolons mit den grundsätzlich gleichen allgemeinen Eigenschaften. Auf höheren Ebene sind die Module nur sozusagen größer, weil sie noch Submodule enthalten.

Wann sollten Sie mit der logischen Dekomposition aufhören? Wenn es Ihnen in den Fingern kribbelt und Sie mit der Implementation eines Moduls beginnen wollen. D.h. wenn Sie meinen, Sie würden die Dienstleistung eines Moduls hinlänglich gut überblicken und keine weitere Zerlegung in Submodule benötigen. Implementiert, d.h. in Code gegossen, werden also die Blätter des Modulbaumes. Die Tiefe, in der diese Blätter unter der Wurzel hängen, kann von Ast zu Ast natürlich verschieden sein.