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.
14 Kommentare:
Ich gebe dir vollkommen recht, Ralf. Mich hat bis jetzt noch kein Diagrammtyp so richtig zufrieden gestellt.
Wenn ich deinen Artikel richtig interpretiere, hast du auch noch keine konkrete Idee für eine Verbesserung, oder?
@Rainer: Doch, ich hab ne Idee für eine Verbesserung ;-) Siehe das PS zu meinem Posting.
Event-based Components sind für mich "the way to go". Mit dem Artikel begründe ich sozusagen das Gefühl, das ich vorher schon hatte. Mit der Archaeologie hab ich ein Bild gefunden, das für mich ausdrückt, was falsch ist mit dem Fokus auf Klassendiagrammen.
Die vielen Abhängigkeits/Strukturdiagramme sind nur wieder ein Symptom eines write-only Programmierens. Code soll geschrieben werden und nicht gelesen.
Das Gegenteil ist aber der Fall. Er wird vor allem gelesen. Und dabei helfen Abhängigkeitsdiagramme viel, viel weniger als man glaubt.
Wie gesagt: Funktionalität, also den Kern von Software, kann man aus ihnen nicht ablesen.
Jaja, das Kleingedruckte - hab ich glatt übersehen. :-)
Hallo Ralf, ich teile Deine Beobachtungen, komme aber zu einem anderen Schluss, wenn es um Prozessorientierte Diagramme geht (Klassen-, Status-, Komponenten-, ... ,Deploymentdiagramm)
Ich finde UML Diagramme besonders nützlich in der Analyse- und Planungphase. Die meisten der Diagramme die hier entstehen sollten nach der Implementierung weggeworfen werden! Die Diagramme die dann übrig bleiben sollten nicht mehr als 7 Elemente haben. Schon sind Sie bei der Kommunikation _unterstützend_ hilfreich. Es ist dann wichtig den richtigen Ausschnitt für das Diagramm zu finden und sich auf das wesentliche zu konzentrieren - also nicht das komplette System abzubilden.
UML bekommt ihren schlechten Ruf, weil sie oft schlecht gemacht wird.
@Robert: Klassen- oder Komponentendiagramme sind prozessorientiert? Kannst du mal sagen, inwiefern? Wo steckt da der Prozess?
Ich hab auch nix gegen UML per se. Wie gesagt: auch Strukturen wollen visualisiert sein.
Wogegen ich mich allerdings wende, das ist der Vorrang, der ihnen gewährt wird. Und dass die allermeisten mit ihnen aufhören.
Greife in deine Softwarekiste und zeige mir das Projekt, bei dem ich mir schnell einen Überblick über die Funktionalität mit Prozessbeschreibungen verschaffen kann.
Nein, Klassendiagramm oder Code zählen da nicht. Die beschreiben entweder nur Struktur oder den Prozess in ungeeignet detailiierter und geschachtelter Weise.
Früher, ganz früher, als Software noch einfach war, da hat Code gereicht, um Prozesse zu beschreiben. Der war klein und übersichtlich. Greif dir ein Buch mit dem Titel "Algorithmen und Datenstrukturen". Ein Quicksort o.ä. kann man durch Betrachtung von Code begreifen. Warum? Weil der keine Abhängigkeiten hat und nicht viele Zeilen umfasst.
Aber alles danach, das größer ist, nein, das lässt sich nur schwer durch Betrachtung von Code begreifen. Deshalb wird soviel Geld verbrannt durch Analyse von Code.
Diagramme, die helfen, gibt es dann auch nicht. Denn die schmeißen die Leute ja weg, kaum, dass sie sie codiert haben.
Ergo: Der heutige Ansatz ist fundamental falsch. Objektorientierung - es steckt im Namen - fokussiert auf Struktur/Beziehungen, nicht auf Funktionalität. Deshalb ist Software schwerer als nötig zu verstehen.
Hallo Ralf,
interessanter Artikel, well done!
Ich habe mich in der Vergangenheit öfter an der Tatsache gestört, dass man versucht hatte, die Funktion eines Systems nur mittels Klassendiagramm zu dokumentieren, welches ja de facto nur die Struktur und Beziehungen von Klassen zueinander darstellt. Was ist denn z.B. mit dem guten alten Kommunikationsdiagramm? Hier werden die Interaktionen eines Systems grafisch dargestellt, das ist für mich das wesentliche bei der Entwicklung objektorientierter Software.
Endlich publiziert es mal jemand.
Wenn ich firmen sehe die Zwangswase alles in Klassenmodelle packen und die wichtigen information im Rauschen der unnötigen Diagramme untergehen und mir dennoch keiner sagen kann wie ich in diesem Framework einfach ein Datensatz / Entität, GUI Element zustande kommt, läuft es mir kalt den Rücken runter.
Wenn einzelne Komponenten autark sind und gut gekapselt laufen, spielt sowieso nur noch der zusammenhang, das da zwischen eine rolle.
Leider blickt man bei solchen Aussagen nur zu oft in ungläubig blickene Gesichter..
@Ralf: "Klassen- oder Komponentendiagramme sind prozessorientiert?" - nein natürlich nicht, da habe ich wohl den Gedanken beim Schreiben verloren.
@Ralf:
Dein Post zusammengefasst:
Aktivitätsdiagramme sind der Ausgang des Softwareentwicklers aus seiner selbst verschuldeten Verschleierung.
Super Artikel - volle Zustimmung meinerseits!
Ich komme aus der Ecke der Regelungstechnik und da waren schon vor Jahren (10+) visuelle Tools das Mittel der Wahl und sind es, soweit ich das überblicken kann, auch noch heute.
Siehe: Simulink (http://www.mathworks.de/products/simulink/) und LabView (http://www.ni.com/labview/d/).
Ich bin gespannt, was da noch so kommt. Solange werde ich mich mal wieder der Softwarearchaeologie widmen (Seufz!).
Hi,
erstmal vielen Dank an Ralf für den Artikel.
Mir fällt leider immer wieder auf, das diverse Autoren von UML- u. anderen Diagrammen VERGESSEN niederzuschreiben: Warum u. wieso sie ihre Lösung so entworfen haben. Diese Leute vergessen ganz banal den Kontext zu dokumentieren. Wenn ich mir dann später die Sachen anschaue u. hinterfrage, dann weiß entweder keiner mehr warum (weil Jahre her) oder erklären mir "Das ist doch ganz einfach ...". Klar u. das ganz einfach weiß später keiner mehr. Mann, Mann, ... mit welchen Basisproblemen wir im Jahr 2010 noch täglich kämpfen müssen.
I came across this post and figured out that your words indeed had loads of sense which i didn't think about before. Sorry, I am commenting in English, I feel more at ease.
I wonder if you have heard about the IDEF0 which was developed by the US army. It is within me the best available type which can be used for any kind of representations.
@Emini: Thx for pointing me at IDEF0. Need to check that out and relate it to EBC.
Kommentar veröffentlichen