Wider die Softwarearchaeologie

Auf der prio.conference habe ich mal die Event-Based Components Dru Sellers vorgestellt, einem der Entwickler des MassTransit Busses. Das war ein sehr interessantes Gespräch in vielerlei Hinsicht.

Zu einem Aspekt daraus bin ich dann auch gleich heute zurückgekehrt: der Archaeologie der Software.

Frage: Was ist der Unterschied zwischen dem Steinkreis von Stonehenge und einem Klassendiagramm?

Meine Antwort: Es gibt keinen Unterschied.
Naja, außer dem offensichtlichen

Sowohl der Steinkreis wie das Klassendiagramm sind archaeologische Artefakte. Das heißt für mich hier, sie sind Menschengemachtes mit einem Zweck, den es zu entschlüsseln gilt. Er lässt sich nicht einfach ablesen, sondern muss durch langwieriges Studium rekonstruiert werden. Stonehenge wie Klassendiagramm zeigen nicht an, wie sie funktionieren.

Für Stonehenge mögen Sie mir da auch zustimmen. Beim Klassendiagramm jedoch schütteln Sie sehr wahrscheinlich den Kopf. Dennoch: Ich meine es genau so. Ein Klassendiagramm zeigt nicht, wie eine Software funktioniert. Die Prozesse, für die es steht, sind aus ihm nicht abzulesen.

Ist das nun ein Mangel des Klassendiagramms? Sicher nicht. Sein Zweck ist allein die Darstellung von Struktur, es beschreibt Beziehungen zwischen Funktionseinheiten.

Meine Kritik richtet sich daher nicht an das Klassendiagramm, sondern an die, die es zum Symbol für die rechte Softwareentwicklung gemacht haben.

Unter den Diagrammarten ist es wohl die heute am wohl häufigsten verwendete – aber sie sagt am wenigsten über Software aus. Oder anders: Ein Klassendiagramm kümmert sich nicht um das Wesentliche von Software und doch hält die Branche es hoch als Symbol für zeitgemäße Softwareentwicklung à la Objektorientierung.

Denn was ist das Wesentliche an Software? Seine Funktion, die Verarbeitung von Eingaben zu Ausgaben, EVA. Laufende Software ist ein Prozess, der knetet und transformiert Daten in vielen Schritten.

Wäre es da nicht naheliegend, dass es die vornehmste Aufgabe eines Softwareentwicklers sei, diese Schritte klar sichtbar zu machen, für jedermann nachvollziehbar?

Aber nein, die Softwareentwicklung tut alles, um die Funktionsweise von Software zu verschleiern. Einem Klassendiagramm können Sie nicht ansehen, wie die Prozesse ablaufen, für die es steht. Ebenso sind Paket- und Komponentendiagramme archaeologische Artefakte, die man lange studieren muss, um irgendetwas über die Funktionsweise einer Software herauszubekommen.

Das ist wieder kein Mangel an den Diagrammen, denn sie wollen Funktionsweise auch nicht repräsentieren. Wieder gehören sie aber zu den meist verwendeten Diagrammarten.

Was aber mit den Sequenzdiagrammen? Stehen die denn nicht für Funktionsweise?

Sicher, Sequenzdiagramme beschreiben Funktionsweise. Doch sie tun das in immer noch schwer verständlicher Weise. Das Problem ist die Schachtelung. Sequenzdiagramme visualisieren Callstacks.

Wenn eines aber schwer für Menschen zu verstehen ist, dann ist es Schachtelung. Wie man es dreht oder wendet, wir kommen damit nur schwer zurecht. Simples Beispiel: Beobachten Sie sich beim nächsten Gespräch mit Freunden oder Kollegen. Sie beginnen ein Thema, dann wirft jemand ein anderes Thema auf, ohne dass das erste abgeschlossen wäre… was nun? Sie werden entweder dafür sorgen, dass das erste Thema beendet wird, bevor Sie mit dem zweiten weitermachen. Oder Sie werden das zweite aufgreifen – und am Ende das erste nicht zuende führen.

Die dritte Alternative – Sie behandeln das zweite Thema als Einschub und kehren am Ende zurück zum ersten Thema – werden Sie nur sehr selten realisieren. Denn dafür braucht es ein gutes Gedächtnis und einigen Willen. Von einem weiteren Einschub während der Behandlung des zweiten Themas ganz zu schweigen.

Schachtelungen sind schwer zu verstehen. So ist das nun mal.

f(g(h(x)));

ist schwerer zu verstehen als

h(x).g().f();

oder

var rh = h(x);
var rg = g(rh);
f(rg);

Und so sind Sequenzdiagramme ebenfalls schwer zu verstehen. Sie zeigen zwar das Wesentliche einer Software, doch sie helfen nur suboptimal beim Verständnis, weil sie immer noch dem von-Neumann-Modell von Software folgen.

Vier der hauptsächlich verwendeten Diagramme der Softwareentwicklung verschleiern damit, worum es eigentlich geht. Undv om Code wir gar nicht erst reden. Aus dem Funktionsweise ablesen zu wollen, ist ein mühseliges Unterfangen, wie jeder bezeugen kann, der schonmal an Brownfieldcode arbeiten musste.

Das ist es noch einfacher, ein Sequenzdiagramm zu lesen. Nicht umsonst wurden die auch entwickelt, nämlich als Analyseinstrumente und nicht als Entwurfswerkzeuge.

Und das bedeutet?

Die Softwareentwicklung leidet unter selbstverschuldeter Verschleierung. Mit jedem Diagramm, das nicht die Funktionsweise leicht verständlich offenbart, mit jeder Zeile Code, die einschachtelt, macht sie es Softwareentwicklern schwer, das Wesentliche von Code zu verstehen. Sie erzwingt wieder und wieder, Softwarearchaeologie zu betreiben. Wohl dem, der dann noch mit den “Altvorderen” sprechen kann, die ein Artefakt hinterlassen haben.

Hochgepriesene visuelle und nicht visuelle formale Sprachen helfen also nicht, die Prozesse, die als Problemlösungen erdacht und dann in ihnen codiert wurden, anschließend aus ihnen abzulesen.

Das kann nicht anders beschrieben werden als Vernichtung von Information. Dadurch entsteht ungeheurer betriebswirtschaftlicher und am Ende auch volkswirtschaftlicher Schaden. Um den in Zukunft zu vermeiden, müssen wir den Fokus ändern.

Software ist fundamental dynamisch. Sie tut etwas. Das ist ihr ganzer Zweck. Sie ist kein Regal oder Bild, sondern eine Maschine. Dafür braucht sie Input, Daten. Aber noch wichtiger ist, wie diese Daten verarbeitet werden. Verständliche Beschreibungen von Funktionsweisen haben deshalb für mich Vorrang vor Datenbeschreibungen.

Am Ende müssen beide sein, doch die Funktionalität ist wichtiger, weil sie der Zweck von Software ist. Daten gibt es durchaus auch ohne Software. Funktionalität nicht. Dafür wird sie entwickelt.

Und wie sollte die geforderte Beschreibung von Funktionalität aussehen?

Sie sollte visuell sein und Schachtelung nur zum Zwecke der Abstraktion verwenden.

• Eine visuelle Beschreibung ist leichter zu überschauen als eine textuelle derselben Funktionalität – außer in trivialen Fällen.
• Und Abstraktion ist nötig, um Kompliziertes überhaupt überschaubar zu machen. Es kann dann auf verschiedenen Abstraktionsebenen dargestellt werden.

Eine visuelle Sprache, die die Funktionsweise einer Software auf verschiedenen Abstraktionsebenen darstellen kann, sollte das Hauptwerkzeug des Softwareentwicklers sein.

Nur so vermeiden wir teure Softwarearchaeologie. Davon bin ich fest überzeugt, auch wenn damit zwei Jahrzehnte Objektorientierung als Verirrung dastehen mögen. Denn die de facto Objektorientierung hat nie den Prozess im Fokus gehabt, sondern immer die Struktur.

Dass es die auch geben muss, ist unzweifelhaft. Aber die Objektorientierung hat sie auf ein Podest gehoben und angebetet. Jedes Domänenobjektmodell legt dafür lebendiges Zeugnis ab.

Die Zukunft der Software liegt daher aus meiner Sicht nicht in der Objektorientierung, sondern einzig in der Prozessorientierung. Ohne Fokus auf den Prozess und seine einfache Implementierung wie verständliche Darstellung auf verschiedenen Ebenen – von kleinen Funktionen bis zu großen Services –, kommen wir nicht aus dem Brownfieldmatsch heraus.

PS: Es gibt natürlich Hoffnung. Aktivitätsdiagramme, Datenflussdiagramme oder BPMN sind Mittel, um Prozesse darzustellen. Wir müssen ihnen nur den gebührenden Platz im Zentrum der Softwareentwicklung einräumen. Und natürlich gehören auch Event-based Components dorthin.