Vorgehen traditionell, imperativ, strukturiert
Vorgehen traditionell, imperativ, strukturiert
Vorgehen traditionell, imperativ, strukturiert
Erfolgreiche ePaper selbst erstellen
Machen Sie aus Ihren PDF Publikationen ein blätterbares Flipbook mit unserer einzigartigen Google optimierten e-Paper Software.
<strong>Vorgehen</strong> <strong>traditionell</strong>, <strong>imperativ</strong>, <strong>strukturiert</strong><br />
Referenten: Alexander Naumann & Jan Sima<br />
Visuelles unterstütztes Programmieren:<br />
<strong>Vorgehen</strong> <strong>traditionell</strong>, <strong>imperativ</strong>, <strong>strukturiert</strong><br />
Visuelles Programmieren<br />
Seminar des Grundstudiums, SS 2002<br />
Prof. em. Dr. Hans-Jürgen Hoffmann, FG PÜ
<strong>Vorgehen</strong> <strong>traditionell</strong>, <strong>imperativ</strong>, <strong>strukturiert</strong><br />
Inhalt:<br />
1. Flussdiagramme..............................................................................3<br />
1.1 Definition....................................................................................3<br />
1.2 Vorteile .......................................................................................5<br />
1.3 Nachteile.....................................................................................5<br />
2. Nassi-Shneiderman-Struktogramme.................................................5<br />
2.1 Definition....................................................................................5<br />
2.2 Vorteile .......................................................................................6<br />
3. Strukturiertes Programmieren ..........................................................6<br />
3.1 Definition....................................................................................6<br />
3.2 Vorteile .......................................................................................7<br />
3.3 Bezug zu Flussdiagrammen, Struktogrammen...............................7<br />
4. Low Level Code visualisieren .........................................................7<br />
5. Visuelle Programmiersprache für Anfänger....................................10<br />
6. Fazit .............................................................................................12<br />
7. Quellenangaben ............................................................................13<br />
Seite 2 von 13
<strong>Vorgehen</strong> <strong>traditionell</strong>, <strong>imperativ</strong>, <strong>strukturiert</strong><br />
1. Flussdiagramme<br />
1.1 Definition<br />
Die Flussdiagramme oder auch Programm-Ablauf-Pläne sind in der DIN 66001<br />
festgehalten. Programme werden folgendermaßen dargestellt:<br />
Befehle, wie Zuweisungen, Funktionsaufrufe (auch rekursiv) werden in eckigen<br />
Kästen gezeichnet. Von jedem Kästchen geht ein Pfeil zu der als nächstes zu<br />
bearbeitenden Anweisung.<br />
Abfragen werden in Rauten dargestellt. Von diesen gehen zwei Pfeile, welche<br />
„true“ und „false“ bezeichnen, zu dem „true“ Block, bzw. „false“ Block.<br />
Andere Konstrukte, wie z.B. eine WHILE-Schleife, müssen mir IF-Abfragen<br />
erstellt werden.<br />
Seite 3 von 13
<strong>Vorgehen</strong> <strong>traditionell</strong>, <strong>imperativ</strong>, <strong>strukturiert</strong><br />
Ein kleines Programm würde dann zum Beispiel so aussehen:<br />
Seite 4 von 13
<strong>Vorgehen</strong> <strong>traditionell</strong>, <strong>imperativ</strong>, <strong>strukturiert</strong><br />
1.2 Vorteile<br />
Bis zu einem gewissen Rahmen sind Flussdiagramme übersichtlicher als der reine<br />
Code. Es ist weiterhin nicht zwingend erforderlich eine Programmiersprache<br />
zu beherrschen, um einfache Flussdiagramme zu verstehen. Flussdiagramme<br />
können außerdem gut bei verschiedenen Tests des Programms eingesetzt werden,<br />
z.B. Knoten- und Zweigüberdeckungstests.<br />
1.3 Nachteile<br />
Größere Programme werden schnell unübersichtlich. Dazu trägt unter anderem<br />
auch die Tatsache bei, dass Konstrukte, wie FOR- oder WHILE-Schleifen, keine<br />
eigenen Symbole haben, sondern aus IF-Abfragen "gebastelt" werden müssen.<br />
Der Aufbau von Flussdiagrammen erlaubt die Benutzung von GoTo Befehlen,<br />
welche die Struktur des Programms und die Übersichtlichkeit stark eingrenzen<br />
können.<br />
2. Nassi-Shneiderman-Struktogramme<br />
2.1 Definition<br />
In SIGPLAN Notices of the ACM August 1973 stellten Nassi und Shneiderman<br />
eine Weiterentwicklung des Flussdiagramms vor, welche dessen Nachteile beseitigte.<br />
Diese Art von Struktogrammen ist in der DIN 66261 definiert.<br />
Anweisungen: IF-Anweisung: CASE-Anweisung:<br />
Seite 5 von 13
<strong>Vorgehen</strong> <strong>traditionell</strong>, <strong>imperativ</strong>, <strong>strukturiert</strong><br />
WHILE-Anweisung: REPEAT-Schleife: FOR-Schleife:<br />
2.2 Vorteile<br />
Die Struktogramme haben selbstverständlich dieselben Vorteile wie auch die<br />
Flußdigramme. Sie werden allerdings oft als etwas einfacher zu lesen empfunden.<br />
Daher verwendet man sie auch als Dokumentation für Funktionen. Der<br />
große Vorteil der Struktogramme ist jedoch, dass durch sie beschriebener Code<br />
automatisch klar gegliedert und <strong>strukturiert</strong> ist. Das liegt vor allem daran, dass<br />
sie keine GoTos zulassen. Weiterhin haben sich die Entwickler Nassi und<br />
Shneiderman ursprünglich gedacht, dass man bei der Erstellung eines Struktogramms<br />
nur eine DIN A4 Seite verwenden darf, weil dies dann dazu führt,<br />
dass man sein Programm in sinnvolle Module aufteilt. Gerade diese Vorteile,<br />
welche die Struktogramme von den Flussdiagrammen abheben, macht diese Art<br />
der Visualisierung besonders für Anfänger sinnvoll, weil man so automatisch<br />
klar und <strong>strukturiert</strong> programmieren lernt.<br />
3. Strukturiertes Programmieren<br />
3.1 Definition<br />
Strukturiertes Programmieren bedeutet, dass das Programm eine einfache und<br />
klare Struktur hat. Dazu gehört insbesondere, daß keine GoTo Befehle verwendet<br />
werden und eine sinnvolle Aufteilung des Programms in einzelne Module.<br />
Seite 6 von 13
<strong>Vorgehen</strong> <strong>traditionell</strong>, <strong>imperativ</strong>, <strong>strukturiert</strong><br />
3.2 Vorteile<br />
Die Strukturierte Programmierung ist heutzutage unerlässlich. Auf Grund großer<br />
Softwareprojekte und vielen daran beschäftigten Programmierern muss jeder in<br />
der Lage sein Funktionen schnell zu verstehen, damit man ohne großen Aufwand<br />
Fehler finden und Module erweitern oder entfernen kann.<br />
3.3 Bezug zu Flussdiagrammen, Struktogrammen<br />
Die Struktur eines Programms wirkt sich selbstverständlich auf die visuelle Darstellung<br />
desselben aus. Einer der Gründe des Erfolgs der Nassi-Shneiderman<br />
Struktogramme ist der enge Zusammenhang zum Strukturierten Programmieren.<br />
In Struktogrammen formulierter Code ist zugleich immer auch <strong>strukturiert</strong>.<br />
Auch Flussdiagramme werden sehr schnell unübersichtlich und damit sinnlos,<br />
wenn der zugrunde gelegte Code schlecht bzw. nicht <strong>strukturiert</strong> geschrieben ist.<br />
4. Low Level Code visualisieren<br />
Im Bereich der Maschinensprachen, also Sprachen wie zum Beispiel 8086er Assembler<br />
oder MIPS, sind Kontrollflussdiagramme meistens eher die Ausnahme<br />
als die Regel. Sie sind meistens zu umständlich, liefern nicht das gewünschte<br />
Ergebnis oder sind erst gar nicht anwendbar. Als weitere Erschwernis kommt<br />
noch die Strukturweise vom Code hinzu, der in diesen Level meistens auf Geschwindigkeit<br />
und nicht auf lesbare Struktur ausgelegt ist.<br />
Flussdiagramm zu benutzen hilft nicht viel, da sie zu schnell unübersichtlich<br />
werden. Wie jeder sicherlich weiß, wächst bei einem Assemblerprogramm die<br />
Codemenge rasant an. Somit entsteht Code, der leicht aus mehreren hundert Zeilen<br />
besteht und ein Diagramm, das auf diesem Code basiert, weitet sich über<br />
Seite 7 von 13
<strong>Vorgehen</strong> <strong>traditionell</strong>, <strong>imperativ</strong>, <strong>strukturiert</strong><br />
mehrere Bildschirmseiten aus. Ein weiteres Problem ist die geringe Aussagekraft<br />
eines Befehls und das man viele Befehle für ein relativ kleines und leichtes<br />
Konstrukt benötigt.<br />
Ein Diagramm, wie das von Nassi-Shneiderman, kann erst gar nicht benutzt<br />
werden, da die Möglichkeit von 1:n-Verbindungen fehlt. Das bedeutet, dass man<br />
an eine Codestelle nicht von mehreren Orten aus<br />
springen kann. Dieses Problem wurde schon mit<br />
den GoTo-Befehlen angesprochen.<br />
Ein weiterer Ansatz, der sich „Asmflow“ nennt,<br />
hilft nur bei kurzen Codeabschnitten.<br />
„AsmFlow“ ist in der Hinsicht hilfreich, dass es<br />
eine einfache Navigation durch den Code bietet<br />
und den Kontext zu jedem Sprungziel anzeigt.<br />
Nachteil dieser Methode ist aber, dass die Instruktionen<br />
linear angezeigt werden, also nicht<br />
wie das Programm eigentlich zur Laufzeit reagiert, sondern wie es geschrieben<br />
worden ist. Somit ist die Codeverfolgung nur über kürzere Codeabschnitte sinnvoll,<br />
da es bei umfangreicherem Code sehr schnell unübersichtlich wird.<br />
Es gibt dann eine wichtige Entwicklung und zwar den Code in so genannte ‚Basic<br />
Blocks’ einzuteilen, d.h. unabhängige Abschnitte die keine Sprungbefehle<br />
und keine Sprungmarken enthält.<br />
Seite 8 von 13
<strong>Vorgehen</strong> <strong>traditionell</strong>, <strong>imperativ</strong>, <strong>strukturiert</strong><br />
Diese Idee ist auf den ersten Blick nicht so schlecht. Zum Beispiel lässt sich somit<br />
der Code viel übersichtlicher darstellen als bei<br />
„AsmFlow“. Aber auch hier gibt es Nachteile, die Blöcke<br />
müssen linear verlaufen, sind schwierig zu kommentieren<br />
und meistens nicht sehr verständlich.<br />
Um dies zu vermeiden, hat man sich gedacht, den Code in ’Sinnblöcke’ zu unterteilen.<br />
Bei dieser Methode wird der Code in<br />
grobe logische Einheiten unterteilt die möglichst<br />
selbsterklärend sind. Man kann sich nun auf einen<br />
Abschnitt konzentrieren und den Rest abstrakter<br />
lassen.<br />
Seite 9 von 13
<strong>Vorgehen</strong> <strong>traditionell</strong>, <strong>imperativ</strong>, <strong>strukturiert</strong><br />
5. Visuelle Programmiersprache für Anfänger<br />
Das Ziel einer visuellen Programmiersprache soll sein, dem Laien, der noch wenig<br />
praktische Programmiererfahrungen hat, beim umsetzen seiner Ideen in Code<br />
zu unterstützen. Meistens basiert diese visuelle Sprache auf einem sehr hohen<br />
Level, soll aber Standardsprachen, wie zum Beispiel C oder Pascal, unterstützen.<br />
Das Hauptproblem, welches Anfänger beim Programmieren haben, ist ihre<br />
mangelnde Umsetzungsfähigkeit. Meistens lernen sie nur die Sprachsemantik<br />
aus ihren Lehrbüchern, aber nichts über Strukturdesign. Ein weiteres Hindernis<br />
sind auch die wenigen Sprachkonstrukte, die viele heutige moderne Programmiersprachen<br />
haben.<br />
Lasst mich dies alles nun an einem Beispiel erläutern:<br />
(1) int summe, counter;<br />
(2) counter = 0; summe = 0;<br />
(3) do{<br />
(4) summe = summe + 1;<br />
(5) counter = counter + 1;<br />
(6) } while( counter
<strong>Vorgehen</strong> <strong>traditionell</strong>, <strong>imperativ</strong>, <strong>strukturiert</strong><br />
In der Programmiersprache ‚QBasic’ war so was zum Beispiel nicht nötig. Dort<br />
wurden Variablen automatisch deklariert und mit dem Defaultwert 0 oder leere<br />
Zeichenkette gefüllt. Sinnvoll war diese Funktion meiner Meinung nach aber<br />
nicht, sie hat zu vielen Programmierfehler und schlechten Angewohnheiten geführt.<br />
Eine Visuelle Programmiersprache sollte nun flexibel und ausdrucksstark sein<br />
um das Vokabular des Anfängers ausdrücken zu können. Durch Bilder bzw. I-<br />
cons kann sie die Sprachkomponenten, Datenstrukturen und benötigte Variablen<br />
ausdrücken und z.B. durch Verbindungslinien Verknüpfungen untereinander<br />
anzeigen, was mit Text nur schwer darzustellen ist. Allgemein werten Menschen<br />
Bilder effizienter als Texte aus. Somit ist dies natürlich die bessere Darstellungsweise.<br />
Ein weiterer Vorteil einer solchen visuellen Sprache ist die, dass<br />
man diese „Icons“ und Verbindungen jederzeit editieren, also verschieben und<br />
ändern kann. Des Weiteren kann man das Programm beim Laufen beobachten,<br />
die Generierung der Ausgaben sehen und bei eventuell auftretenden Fehlern erkennen,<br />
wo und wann sie aufgetaucht sind.<br />
Es gab auch einen Ansatz in der man für Variablen<br />
Farben genommen hat. Diese Idee hatte aber Probleme<br />
mit vielen Variablen, da der Mensch nur eine<br />
bestimmte geringe Anzahl an Farben schnell unterscheiden<br />
kann. Lösungen wie die Farben mit Texturen<br />
zu unterlegen, Text reinzusetzen oder unterschiedliche<br />
Formen benutzen haben aber nicht die<br />
gewünschte Wirkung und zerstören eventuell die<br />
eigentliche Idee.<br />
Trotzdem ist diese Idee für Anfänger<br />
als Einführung gut geeignet. Durch das<br />
Seite 11 von 13
<strong>Vorgehen</strong> <strong>traditionell</strong>, <strong>imperativ</strong>, <strong>strukturiert</strong><br />
Fehlen jeglichen Textes hat man auch daran gedacht, damit das Programmieren<br />
auch Kleinkindern beizubringen.<br />
Eine andere Möglichkeit besteht darin, den Code wie Puzzleteile zu handhaben.<br />
Jetzt braucht der ‚Programmierer’ nur noch die einzelnen Teile zu einem Puzzleähnlichen<br />
Gebilde zusammenzufügen und dann einige Eigenschaften der Puzzleteile<br />
fest zu legen.<br />
6. Fazit<br />
Als erfahrener Programmierer wird man bei überschaubaren Projekten wohl<br />
kaum auf Visualisierungen zurückgreifen müssen. Allerdings können besonders<br />
die Struktogramme gut als Dokumentation für Dritte verwendet werden. Der<br />
enge Zusammenhang zwischen den Struktogrammen und dem Strukturiertem<br />
Programmieren machen diese besonders für Laien, welche Programmieren lernen,<br />
sehr sinnvoll, weil man gezwungenermaßen von Anfang an lernt „sauber“<br />
zu programmieren.<br />
Seite 12 von 13
<strong>Vorgehen</strong> <strong>traditionell</strong>, <strong>imperativ</strong>, <strong>strukturiert</strong><br />
7. Quellenangaben<br />
• E.W. Dijkstra: Go To statement considered harmful; Letter to the Editor,<br />
Comm. ACM, März 1968, 147 – 148<br />
• C. Boehm, G.Jacopini: Flow diagram, Turing machines and languages<br />
with only two formation rules; Comm. ACM, Mai 1966, 366-371<br />
• I. Nassi, B. Shneiderman: Flowchart techniques for structured programming;<br />
ACM Sigplan Notices, August 1973, 12 – 26<br />
• DIN 66001 & DIN 66261<br />
• M.A.E. Beaumont et al.: Visualising complex control flow; Proc. IEEE<br />
Symp. Visual Languages, 1998, 244 – 251<br />
• E.P. Glinert, C.D. Smith: PC-Tiles – A visual programming environment<br />
for personal computers based on the BLOX methodology; Rensselaer<br />
Polytechnic Inst., Report #86-21, 1986<br />
• E.P. Glinert, S.L. Tanimoto: PICT, an interactive graphical programming<br />
environment; IEEE Computer, Nov. 1984, 7 – 25<br />
• S.K. Chang: Principles of visual programming systems; Prentice Hall,<br />
1990: Kap. 6, J.G. Bonar, B.W. Liffick: A visual programming language<br />
for novices; 326 – 366<br />
• NN (GSK GmbH): Struktogrammeditor “MyFriend”;<br />
http://www.myfriend.de/editor.html<br />
Seite 13 von 13