Struktogramme oder besser gesagt das Nassi-Shneiderman-Diagramm stellt den Ablauf eines Programms bzw. einer Funktion dar. Ein Struktogramm ist in einer einheitlichen Sprache definiert und lediglich die Funktionen DIV (ganzzahlige Division) und MOD (Modulo-Operation [Divison, mit der anstatt das Ergebnis der Rest der Division ausgegeben wird]) neben den normalen Operatoren „*“ (Multiplikation), „/“ (Division), „+“ (Addition) und „-“ (Subtraktion) erlaubt sind. Funktionen wie Round(), die eine Zahl auf- oder abrunden, gibt es nicht. Ebenso sind andere spezifischen Eigenschaften einer Programmiersprache wie das erhöhen einer Laufvariabel mit der Kurzform „i++; “ nicht erlaubt. Es gibt lediglich die genannten Operationen. Zuweisungen von Variabeln finden mit einem Doppelpunkt und Gleichheitszeichen statt.

Ein einfaches Beispiel für ein Struktogramm wäre ein kleines Programm, das den BMI einer Person errechnet. Die Body Mass Index-Formel lautet Körpergewicht / Körpergroesse ². Der Programmablauf sähe in einem Struktogramm etwa wie folgt aus:

DFA steht für dateifreie Ausgabe und DFE für dateifreie Eingabe. Nachdem ich nun kurz darauf eingegangen bin, was ein Struktogramm ist und wie es in etwa aufgebaut ist, bleibt nun die Frage, ob so ein Struktogramm hilfreich ist. Kurz und einfach: Ja, es ist hilfreich, aber nicht unbedingt ein Muss. Ein guter Entwickler macht sich, bevor er wild in der Entwickl

ungsumgebung seinen Code zusammenhackt, darüber Gedanken, was sein Programm können muss. Hierzu hilft oft schon UML, wobei das Struktogramm sich auf einen kleineren Kontext bezieht. Das Programm bzw. die Funktion BMIberechnen() könnte ein Teil einer Fitness-Softwarelösung sein und während in UML das Gesamtkonzept steht, hilft ein Struktogramm sich gedanklich mit einer einfachen oder komplexen Funktion auseinanderzusetzen.

Natürlich ist ein Struktogramm nicht immer die beste Lösung für alle Aufgaben, denn durch das Erstellen eines Nassi-Shneiderman-Diagramms muss man vorher abwägen, ob sich die Zeit lohnt dafür zu investieren. Bei schwierigen und unübersichtlichen Aufgabenstellungen kann dies aber sehr hilfreich sein! Man vermeidet Flüchtigkeits- und vor allem verherende Logikfehler. Logikfehler können große Ausmaße annehmen, vor allem wenn das Programm scheinbar erst einmal fehlerfrei funktioniert. Natürlich ist ein Struktogramm keine Garantie dafür, einen Logikfehler zu vermeiden, doch das Risiko sinkt, da der Programmierer sich zuvor sich mit dem Programm intensiv – ohne eine Zeile Code zu schreiben – mit folgenden Punkten auseinandergesetzt hat:

• Welche Variablen brauche ich?
• Welche Eingaben müssen vom Benutzer gemacht werden?
• Welche Fehler muss ich abfangen?
• Auf welche Besonderheiten muss ich achten?
• Welche Verschachtelungen von Bedinungsabfragen sind sinnvoll und optimal?
• Benötige ich eine Kopf- oder fussgesteuerte Schleife?
• Welche Variabel muss initialisiert werden?

Meiner Meinung nach unterscheidet dies einen guten Programmierer von den Schlechten. „Trial and Error“ ist nicht mehr die moderne Programmierform. Sich Gedanken machen und dann loslegen spart oftmals Zeit und Nerven.

Bildquelle (erstes Bild oben): © 2008 Bernd Boscolo / pixelio.de