Artikelformat

Back to the 60ties: Flussdiagramme

In den Zeiten von Lochkarten hat man den Algorithmus eines Programms meist mit einem Flussdiagrammen visualisiert. Erst danach hat man darauf aufbauend das eigentliche Programm „codiert“. Die Darstellungsmethodik wurde sogar in einer DIN-Norm 66001 spezifiziert und hat dann Eingang in viele Berufsausbildungen genommen. Auch heute noch sind Flussdiagramme in vielen Fachbüchern zu finden.

Einfaches Flussdiagramm aus einen Lehrbuch für Handwerker

Beispiel eines Flussdiagramms aus einem Buch für Handwerker.

Ironischerweise sind diese Diagramme in der Informatik seit dem Aufkommen des strukturierten Programmierens praktisch bedeutungslos.

Dennoch: In der Kommunikation mit fachlichen Anwendern oder Entscheidern können wir meist auf ein Grundverständnis von Flussdiagrammen aufbauen. Einige fachliche Projektbeteiligte kommen oft sogar von selbst darauf, Abläufe mit Flussdiagrammen zu visualisieren.

Leider haben dann Nicht-Informatiker dann doch oft Probleme, ihre Gedanken in eine solche abstrakte Darstellung zu überführen.

Seltsamt verschachteltes Flussdiagramm

Mit welchem Programmkonstrukt kann man diese Ablauflogik ausdrücken? Es geht nur mit einem GO-TO. Aus modernen Programmiersprachen ist das GO-TO verschwunden: Es führt nämlich zu schwer zu verstehenden Ablaufstrukturen. Man kann die Abläufe praktisch immer deutlich eleganter ausdrücken.

Meine Erfahrung sagt mir, das der Anwender hier wohl etwas anderes im Sinn hatte. Manche Anwender sollte man mit der Diagrammerstellung also lieber nicht alleine lassen.

Aber auch erfahrene Entwickler verlieren sich oft im Dickicht der Komplexität von Diagrammen. Schauen wir uns ein Beispiel eines ehemaligen Kollegen an:

Ein Ablaufdiagramm das etwas unübersichtlich geraten ist.

Es wirkt sehr komplex. Wie kann man mehr Übersichtlichkeit herstellen?

Tipp 1: Die Hauptrichtung sollte immer von links nach rechts, oben nach unten sein. Nur die Nebenpfade sollten davon abweichen.

Tipp 2: Gerade die Fehlerbehandlung eines Prozesses neigt dazu, den Hauptpfad zu verschleiern. Hier sollte man gnadenlos abstrahieren und die Details der Fehlerbehandlung, wenn überhaupt, in einem gesonderten Diagramm erfassen. Es hilft meist niemanden, alle mögliche Pfade durch ein System wie in einem Labyrinth in einziges Diagramm zu pressen zu wollen.

Tipp 3: Hier werden Entscheidungsrauten benutzt, um Flüsse wieder zusammenzuführen. Das ist im Grunde falsch. Es wäre hier auch gar nicht nötig. In Prozessablaufdiagrammen kann man meiner Erfahrung nach oft auf die Darstellung von expliziten Entscheidungen verzichten. Das Diagramm wird übersichtlicher.
Die Stärke von Diagrammen sind die Darstellung von Beziehungen oder auch Abläufen. Details, unter genau welchen Bedingungen welche Entscheidung getroffen wird, lassen sich in Text meist besser ausdrücken.

Ein so vereinfachtes Diagramm kann man dann leichter verstehen:

Vereinfachtes Ablaufdiagramm

Umgestaltetes Ablaufdiagramm.

Autor: Karsten Meier

Weil ich gerne Probleme löse bin ich Informatiker geworden. Ich berate und Konzeptionieren und entwickle mit fast allem, was einen Prozessor hat.

Hinterlassen Sie eine Antwort