Erfahrungen eines alten DV-Hasen:

"Wie ich lernte, Struktogramme zu lieben"

25.07.1980

Es ist sowohl die Sicht des Softwareentwicklers wie auch die des Seminarleiters, die ich bei meinem kurzen Erfahrungsbericht über die Anwendung von Strukturprogrammen einnehme. Um so glaubhafter dürfte es sein, wenn teil versichere: Der Programmablaufplan kann einem Struktogramm das Wasser nicht reichen, von ganz weniger Ausnahmen abgesehen.

Jahrelang entwarf ich meine Programme mit den üblichen Programmablaufplänen, die - wie allgemein bekannt - viele Mängel haben Sie sind unübersichtlich, werden meist erst nach Fertigstellung des Programmes gezeichnet und stimmen sowieso selten mit dem tatsächlichen Programmablauf überein.

Da kamen Struktogramme aus den USA auf den Markt Sie wurden in Seminaren lautstark gepriesen und verhießen ungeahnte Möglichkeiten beim Entwurf von EDV-Programmen Auch ich besuchte eines der ersten Seminare, auf denen die Teilnehmer "Top Down Approach", "Stepwise Refinement", "Case i", "Do While", "Repeat Until" und "Cycle" kennenlernten Sogar die Richtigkeit der Struktogramme wurde "mathematisch bewiesen"

Einige Teilnehmer waren begeistert von der neuen Technik, andere waren erschreckt (nämlich die, die nicht wußten, daß Cycle eine Schleife ist und so alt ist wie die Datenverarbeitung selbst); wiederum andere standen dem Neuen ablehnend gegenüber, weil sie gegen alles Neue eine Abneigung haben.

Ein Jahr nach diesem Seminar erkundigte ich mich bei einigen ehemaligen "Mitschülern" und fragte zusätzlich Programmierer verschiedener Firmen über ihre Fortschritte mit Struktogrammen. Das Ergebnis war dürftig Fast alle programmierten im alten Stil (Ich übrigens auch.)

Das spornte meinen Ehrgeiz an, und von nun an zwang ich mich zur strikten Anwendung von Struktogrammen Beim ersten Programm dauerte der Entwurf des Programmes fünfmal so lange wie vergleichsweise mit dem üblichen Ablaufplan, aber ich hatte es zumindest geschafft Beim zweiten Programm dauerte es nur noch dreimal so lange, und beim dritten Programm war der "break even point" erreicht. Das war mein Einstieg in die Struktogramme.

Wie sieht es heute aus, nachdem ich im Laufe von mehr als vier Jahren Hunderte von Struktogrammen gezeichnet habe? Um es vorweg zu nehmen Ein 500prozentiger Erfolg! Ich kann mir die Struktogramme nicht mehr wegdenken Min Programm, das heute von mir mit Hilfe von Struktogrammen entwickelt wird

- ist doppelt bis dreimal so schnell fertig wie sonst,

- wird zu 70 Prozent a m Schreibtisch entwickelt und getestet

- ist fast vollständig und richtig dokumentiert,

- ist wartungs- und änderungsfreundlich aufgebaut

Hauptanforderungen an ein Programm sind Fehlerfreiheit und Funktionstüchtigkeit. Termintreue und niedrige Kosten werden ebenso vorausgesetzt. Schließlich sollen transparente Programme die Wartungs- und Änderungsfreundlichkeit erhöhen, den Anwender vom Autoren unabhängig machen und eine aussagefähige Dokumentation liefern. Was sind Struktogramme?

Struktogramme sind Planungs- und Dokumentationsmittel, die auf gedrängtem Raum eine Fülle von übersichtlich angeordenten Informationen enthalten. Sie dienen dazu, den logischen Ablauf eines Programmes darzustellen und lösen zum großen Teil die herkömmlichen Ablaufpläne ab. Für ein Programm benötigt man je nach Größe ein bis 50 Struktogramme (und mehr), wobei jedes Struktogramm auf einer Seite (DIN A4) Platz finden muß. Struktogramme werden eingesetzt in der Planungsphase eines EDV-Projektes, besonders aber in der Programmierung, wo sie die Grundlage für das Codieren sind.

Was sind die Hauptmerkmale der Strukturierung?

In der Architekturphase der Programmierung wird mit den Struktogrammen der logische Aufbau und Ablauf des Programmes am Schreibtisch entworfen. Entscheidend ist hierbei wohl, daß der Denkansatz, wie ein Problem zu lösen sei, ganz anders gelagert ist als beim Programmablaufplan. Man geht nicht linear an ein Problem heran, sondern analysiert dessen logische Funktionen, teilt diese dann schrittweise über mehrere Stufen in weitere Unterfunktionen, bis das Problem letztlich in kleine Strukturblöcke zerfällt, die sich leicht codieren lassen. Ein Programm besteht damit nun aus mehreren logischen Verarbeitungsblöcken, deren Ablauffolge durch Steuerblöcke geregelt wird.

Vorteile der Struktogramme

- Bereits beim Zeichnen der Struktogramme erkennt man Fehlerquellen.

- Durch logische Gliederung wird auch ein umfangreiches Programm übersichtlich.

- Fernwirkungen bei späteren Programmänderungen lassen sich vermeiden.

- Das Programm ist stufenweise aufgebaut; auf der ersten Seite der Struktogramm-Dokumentation findet man den logischen Gesamtablauf des Programmes, auf den folgenden Seiten die Details des Ablaufes.

- Der logische Programmablauf ist bereits am Schreibtisch austestbar.

- Es lassen sich mehr verbale Erläuterungen im Struktogramm unterbringen.

- Mehrfach verwendbare Unterprogramme lassen sich frühzeitig erkennen.

Wo liegen die Probleme bei der Anwendung von Struktogrammen?

Die Schwierigkeit für den Programmierer besteht lediglich darin, logische Funktionen zu erkennen, diese Funktionen in Verarbeitungs- und Steuerblöcke zu teilen und eine sinnvolle Gliederungstiefe zu finden. "Struktofanatiker" schwelgen im Top-Down-Approach, gliedern bis zum Exzeß, plädieren für ein Programmieren ohne GO TO, stellen Gesetze auf, nach denen nur richtig oder nur falsch programmiert werden kann.

Struktogramme sind aber keine Wissenschaft; sie gestatten GO TO und werden selten falsch gezeichnet. Man kann höchstens von "weniger gut", "weniger geeignet", "umständlich" oder "unklar" sprechen. In manchen Fällen sind Ablaufpläne sogar übersichtlicher als Struktogramme und diesen dann vorzuziehen.

* Volker Elstermann aus 6374 Steinbach ist seit 1967 als Programmierer, Systemanalytiker und Berater in der kommerziellen IDV tätig. Seine Ausbildertätigkeit liegt schwerpunktmäßig auf dem Gebiet rationeller und methodischer Vorgehensweisen bei der Softwareentwicklung.

Wie findet man den Weg zu Struktogrammen?

- Die EDV-Leitung muß von den Vorteil von der Struktogramme überzeugt werden.

- Dem Programmierer muß in der Lernphase genügend Zeit gewährt werden.

- Das Training sollte möglichst frei von Theorie sein und sich mehr auf praktische Übungen konzentrieren.

- Die Individuelle Gestaltung der Struktogramme soll hervorgehoben werden. Struktoprogramme dürfen kein Selbstzweck sein.

- Im Unterricht sollen nicht vom Lehrer vorbereitete Probleme gelöst werden (die gehen nämlich immer auf), sondern die Probleme des Lernenden.

- In der Praxis mit einfachen Problemen beginnen.

- Eiserner Wille und Durchhaltevermögen.

- Der Anfänger soll sich vom erfahrenen Praktiker überzeugen lassen, daß dar Verzicht auf Struktogramme ein Fehler in seiner beruflichen Entwicklung bedeutet.