Vorgehen traditionell, imperativ, strukturiert

Vorgehen traditionell, imperativ, strukturiert
Referenten: Alexander Naumann & Jan Sima
Visuelles unterstütztes Programmieren:
Vorgehen traditionell, imperativ, strukturiert
Visuelles Programmieren
Seminar des Grundstudiums, SS 2002
Prof. em. Dr. Hans-Jürgen Hoffmann, FG PÜ

Vorgehen traditionell, imperativ, strukturiert
Inhalt:
1. Flussdiagramme..............................................................................3
1.1 Definition....................................................................................3
1.2 Vorteile .......................................................................................5
1.3 Nachteile.....................................................................................5
2. Nassi-Shneiderman-Struktogramme.................................................5
2.1 Definition....................................................................................5
2.2 Vorteile .......................................................................................6
3. Strukturiertes Programmieren ..........................................................6
3.1 Definition....................................................................................6
3.2 Vorteile .......................................................................................7
3.3 Bezug zu Flussdiagrammen, Struktogrammen...............................7
4. Low Level Code visualisieren .........................................................7
5. Visuelle Programmiersprache für Anfänger....................................10
6. Fazit .............................................................................................12
7. Quellenangaben ............................................................................13
Seite 2 von 13

Vorgehen traditionell, imperativ, strukturiert
1. Flussdiagramme
1.1 Definition
Die Flussdiagramme oder auch Programm-Ablauf-Pläne sind in der DIN 66001
festgehalten. Programme werden folgendermaßen dargestellt:
Befehle, wie Zuweisungen, Funktionsaufrufe (auch rekursiv) werden in eckigen
Kästen gezeichnet. Von jedem Kästchen geht ein Pfeil zu der als nächstes zu
bearbeitenden Anweisung.
Abfragen werden in Rauten dargestellt. Von diesen gehen zwei Pfeile, welche
„true“ und „false“ bezeichnen, zu dem „true“ Block, bzw. „false“ Block.
Andere Konstrukte, wie z.B. eine WHILE-Schleife, müssen mir IF-Abfragen
erstellt werden.
Seite 3 von 13

Vorgehen traditionell, imperativ, strukturiert
Ein kleines Programm würde dann zum Beispiel so aussehen:
Seite 4 von 13

Vorgehen traditionell, imperativ, strukturiert
1.2 Vorteile
Bis zu einem gewissen Rahmen sind Flussdiagramme übersichtlicher als der reine
Code. Es ist weiterhin nicht zwingend erforderlich eine Programmiersprache
zu beherrschen, um einfache Flussdiagramme zu verstehen. Flussdiagramme
können außerdem gut bei verschiedenen Tests des Programms eingesetzt werden,
z.B. Knoten- und Zweigüberdeckungstests.
1.3 Nachteile
Größere Programme werden schnell unübersichtlich. Dazu trägt unter anderem
auch die Tatsache bei, dass Konstrukte, wie FOR- oder WHILE-Schleifen, keine
eigenen Symbole haben, sondern aus IF-Abfragen "gebastelt" werden müssen.
Der Aufbau von Flussdiagrammen erlaubt die Benutzung von GoTo Befehlen,
welche die Struktur des Programms und die Übersichtlichkeit stark eingrenzen
können.
2. Nassi-Shneiderman-Struktogramme
2.1 Definition
In SIGPLAN Notices of the ACM August 1973 stellten Nassi und Shneiderman
eine Weiterentwicklung des Flussdiagramms vor, welche dessen Nachteile beseitigte.
Diese Art von Struktogrammen ist in der DIN 66261 definiert.
Anweisungen: IF-Anweisung: CASE-Anweisung:
Seite 5 von 13

Vorgehen traditionell, imperativ, strukturiert
WHILE-Anweisung: REPEAT-Schleife: FOR-Schleife:
2.2 Vorteile
Die Struktogramme haben selbstverständlich dieselben Vorteile wie auch die
Flußdigramme. Sie werden allerdings oft als etwas einfacher zu lesen empfunden.
Daher verwendet man sie auch als Dokumentation für Funktionen. Der
große Vorteil der Struktogramme ist jedoch, dass durch sie beschriebener Code
automatisch klar gegliedert und strukturiert ist. Das liegt vor allem daran, dass
sie keine GoTos zulassen. Weiterhin haben sich die Entwickler Nassi und
Shneiderman ursprünglich gedacht, dass man bei der Erstellung eines Struktogramms
nur eine DIN A4 Seite verwenden darf, weil dies dann dazu führt,
dass man sein Programm in sinnvolle Module aufteilt. Gerade diese Vorteile,
welche die Struktogramme von den Flussdiagrammen abheben, macht diese Art
der Visualisierung besonders für Anfänger sinnvoll, weil man so automatisch
klar und strukturiert programmieren lernt.
3. Strukturiertes Programmieren
3.1 Definition
Strukturiertes Programmieren bedeutet, dass das Programm eine einfache und
klare Struktur hat. Dazu gehört insbesondere, daß keine GoTo Befehle verwendet
werden und eine sinnvolle Aufteilung des Programms in einzelne Module.
Seite 6 von 13

Vorgehen traditionell, imperativ, strukturiert
3.2 Vorteile
Die Strukturierte Programmierung ist heutzutage unerlässlich. Auf Grund großer
Softwareprojekte und vielen daran beschäftigten Programmierern muss jeder in
der Lage sein Funktionen schnell zu verstehen, damit man ohne großen Aufwand
Fehler finden und Module erweitern oder entfernen kann.
3.3 Bezug zu Flussdiagrammen, Struktogrammen
Die Struktur eines Programms wirkt sich selbstverständlich auf die visuelle Darstellung
desselben aus. Einer der Gründe des Erfolgs der Nassi-Shneiderman
Struktogramme ist der enge Zusammenhang zum Strukturierten Programmieren.
In Struktogrammen formulierter Code ist zugleich immer auch strukturiert.
Auch Flussdiagramme werden sehr schnell unübersichtlich und damit sinnlos,
wenn der zugrunde gelegte Code schlecht bzw. nicht strukturiert geschrieben ist.
4. Low Level Code visualisieren
Im Bereich der Maschinensprachen, also Sprachen wie zum Beispiel 8086er Assembler
oder MIPS, sind Kontrollflussdiagramme meistens eher die Ausnahme
als die Regel. Sie sind meistens zu umständlich, liefern nicht das gewünschte
Ergebnis oder sind erst gar nicht anwendbar. Als weitere Erschwernis kommt
noch die Strukturweise vom Code hinzu, der in diesen Level meistens auf Geschwindigkeit
und nicht auf lesbare Struktur ausgelegt ist.
Flussdiagramm zu benutzen hilft nicht viel, da sie zu schnell unübersichtlich
werden. Wie jeder sicherlich weiß, wächst bei einem Assemblerprogramm die
Codemenge rasant an. Somit entsteht Code, der leicht aus mehreren hundert Zeilen
besteht und ein Diagramm, das auf diesem Code basiert, weitet sich über
Seite 7 von 13

Vorgehen traditionell, imperativ, strukturiert
mehrere Bildschirmseiten aus. Ein weiteres Problem ist die geringe Aussagekraft
eines Befehls und das man viele Befehle für ein relativ kleines und leichtes
Konstrukt benötigt.
Ein Diagramm, wie das von Nassi-Shneiderman, kann erst gar nicht benutzt
werden, da die Möglichkeit von 1:n-Verbindungen fehlt. Das bedeutet, dass man
an eine Codestelle nicht von mehreren Orten aus
springen kann. Dieses Problem wurde schon mit
den GoTo-Befehlen angesprochen.
Ein weiterer Ansatz, der sich „Asmflow“ nennt,
hilft nur bei kurzen Codeabschnitten.
„AsmFlow“ ist in der Hinsicht hilfreich, dass es
eine einfache Navigation durch den Code bietet
und den Kontext zu jedem Sprungziel anzeigt.
Nachteil dieser Methode ist aber, dass die Instruktionen
linear angezeigt werden, also nicht
wie das Programm eigentlich zur Laufzeit reagiert, sondern wie es geschrieben
worden ist. Somit ist die Codeverfolgung nur über kürzere Codeabschnitte sinnvoll,
da es bei umfangreicherem Code sehr schnell unübersichtlich wird.
Es gibt dann eine wichtige Entwicklung und zwar den Code in so genannte ‚Basic
Blocks’ einzuteilen, d.h. unabhängige Abschnitte die keine Sprungbefehle
und keine Sprungmarken enthält.
Seite 8 von 13

Vorgehen traditionell, imperativ, strukturiert
Diese Idee ist auf den ersten Blick nicht so schlecht. Zum Beispiel lässt sich somit
der Code viel übersichtlicher darstellen als bei
„AsmFlow“. Aber auch hier gibt es Nachteile, die Blöcke
müssen linear verlaufen, sind schwierig zu kommentieren
und meistens nicht sehr verständlich.
Um dies zu vermeiden, hat man sich gedacht, den Code in ’Sinnblöcke’ zu unterteilen.
Bei dieser Methode wird der Code in
grobe logische Einheiten unterteilt die möglichst
selbsterklärend sind. Man kann sich nun auf einen
Abschnitt konzentrieren und den Rest abstrakter
lassen.
Seite 9 von 13

Vorgehen traditionell, imperativ, strukturiert
5. Visuelle Programmiersprache für Anfänger
Das Ziel einer visuellen Programmiersprache soll sein, dem Laien, der noch wenig
praktische Programmiererfahrungen hat, beim umsetzen seiner Ideen in Code
zu unterstützen. Meistens basiert diese visuelle Sprache auf einem sehr hohen
Level, soll aber Standardsprachen, wie zum Beispiel C oder Pascal, unterstützen.
Das Hauptproblem, welches Anfänger beim Programmieren haben, ist ihre
mangelnde Umsetzungsfähigkeit. Meistens lernen sie nur die Sprachsemantik
aus ihren Lehrbüchern, aber nichts über Strukturdesign. Ein weiteres Hindernis
sind auch die wenigen Sprachkonstrukte, die viele heutige moderne Programmiersprachen
haben.
Lasst mich dies alles nun an einem Beispiel erläutern:
(1) int summe, counter;
(2) counter = 0; summe = 0;
(3) do{
(4) summe = summe + 1;
(5) counter = counter + 1;
(6) } while( counter

Vorgehen traditionell, imperativ, strukturiert
In der Programmiersprache ‚QBasic’ war so was zum Beispiel nicht nötig. Dort
wurden Variablen automatisch deklariert und mit dem Defaultwert 0 oder leere
Zeichenkette gefüllt. Sinnvoll war diese Funktion meiner Meinung nach aber
nicht, sie hat zu vielen Programmierfehler und schlechten Angewohnheiten geführt.
Eine Visuelle Programmiersprache sollte nun flexibel und ausdrucksstark sein
um das Vokabular des Anfängers ausdrücken zu können. Durch Bilder bzw. I-
cons kann sie die Sprachkomponenten, Datenstrukturen und benötigte Variablen
ausdrücken und z.B. durch Verbindungslinien Verknüpfungen untereinander
anzeigen, was mit Text nur schwer darzustellen ist. Allgemein werten Menschen
Bilder effizienter als Texte aus. Somit ist dies natürlich die bessere Darstellungsweise.
Ein weiterer Vorteil einer solchen visuellen Sprache ist die, dass
man diese „Icons“ und Verbindungen jederzeit editieren, also verschieben und
ändern kann. Des Weiteren kann man das Programm beim Laufen beobachten,
die Generierung der Ausgaben sehen und bei eventuell auftretenden Fehlern erkennen,
wo und wann sie aufgetaucht sind.
Es gab auch einen Ansatz in der man für Variablen
Farben genommen hat. Diese Idee hatte aber Probleme
mit vielen Variablen, da der Mensch nur eine
bestimmte geringe Anzahl an Farben schnell unterscheiden
kann. Lösungen wie die Farben mit Texturen
zu unterlegen, Text reinzusetzen oder unterschiedliche
Formen benutzen haben aber nicht die
gewünschte Wirkung und zerstören eventuell die
eigentliche Idee.
Trotzdem ist diese Idee für Anfänger
als Einführung gut geeignet. Durch das
Seite 11 von 13

Vorgehen traditionell, imperativ, strukturiert
Fehlen jeglichen Textes hat man auch daran gedacht, damit das Programmieren
auch Kleinkindern beizubringen.
Eine andere Möglichkeit besteht darin, den Code wie Puzzleteile zu handhaben.
Jetzt braucht der ‚Programmierer’ nur noch die einzelnen Teile zu einem Puzzleähnlichen
Gebilde zusammenzufügen und dann einige Eigenschaften der Puzzleteile
fest zu legen.
6. Fazit
Als erfahrener Programmierer wird man bei überschaubaren Projekten wohl
kaum auf Visualisierungen zurückgreifen müssen. Allerdings können besonders
die Struktogramme gut als Dokumentation für Dritte verwendet werden. Der
enge Zusammenhang zwischen den Struktogrammen und dem Strukturiertem
Programmieren machen diese besonders für Laien, welche Programmieren lernen,
sehr sinnvoll, weil man gezwungenermaßen von Anfang an lernt „sauber“
zu programmieren.
Seite 12 von 13

Vorgehen traditionell, imperativ, strukturiert
7. Quellenangaben
• E.W. Dijkstra: Go To statement considered harmful; Letter to the Editor,
Comm. ACM, März 1968, 147 – 148
• C. Boehm, G.Jacopini: Flow diagram, Turing machines and languages
with only two formation rules; Comm. ACM, Mai 1966, 366-371
• I. Nassi, B. Shneiderman: Flowchart techniques for structured programming;
ACM Sigplan Notices, August 1973, 12 – 26
• DIN 66001 & DIN 66261
• M.A.E. Beaumont et al.: Visualising complex control flow; Proc. IEEE
Symp. Visual Languages, 1998, 244 – 251
• E.P. Glinert, C.D. Smith: PC-Tiles – A visual programming environment
for personal computers based on the BLOX methodology; Rensselaer
Polytechnic Inst., Report #86-21, 1986
• E.P. Glinert, S.L. Tanimoto: PICT, an interactive graphical programming
environment; IEEE Computer, Nov. 1984, 7 – 25
• S.K. Chang: Principles of visual programming systems; Prentice Hall,
1990: Kap. 6, J.G. Bonar, B.W. Liffick: A visual programming language
for novices; 326 – 366
• NN (GSK GmbH): Struktogrammeditor “MyFriend”;
http://www.myfriend.de/editor.html
Seite 13 von 13