Geringschätzung Struktogramme?
0 
Felix Riesterer
0 
Rolf B
0 encoder
0 
Der Martin
0
Geringschätzung Struktogramme?
Auf der angegebenen Seite werden Struktogramme als kaum noch erforderlich dargestellt. In meiner berufl. Praxis nutze ich seit den 90-ern intensiv Struktogramme, spätenstens, als ich ein Unterprogramm umstellen musste, das auf ca. 150 Zeilen Quellcode mit 60! GOTO - Anweisungen gespickt war.
Als Negativbeispiel ein PAP, der an kritischer Stelle einfach auf ein Wunder verweist - im Struktogramm nicht möglich.
Speziell für die Arbeit im SAP - Umfeld habe ich mir ein Programm erstellt, das vereinfachte Struktogramme aus bestehenden Quelltexten erstellen kann - eine unschätzbare Hilfe für mich. Oft musste ich fremde Quellen bearbeiten, deren Code unübersichtlich ist. Als Beispiel ein so erstelltes Struktogramm. Nur über dieses Struktogramm konnte ich z.B. erkennen, dass die türkis markierten Quelltexte doppelt vorhanden sind, und das beseitigen.
Wo speziell in JavaScript spezielle struktogrammähnliche Werkzeuge bereits integriert sind, ist mir nicht bekannt.
Deshalb würde ich die Abwertung des Struktogramms in SELFHTML eher vermeiden.
Nebenbei sind Struktogramme auch ein sehr gutes Hilfsmittel in der Kommunikation mit Kunden. Wenn diese einer Struktogramm - Logik zustimmen, bekomme ich später kein "das habe ich mir aber anders vorgestellt..." zu hören.[
f0-920b-9c6b003e9157.svg "Struktogramm")](/images/1e4aa158-7e87-11f0-920b-9c6b003e9157.svg)
-
Lieber StrucFan,
wie soll ich Deinen Rant ernst nehmen, wenn jemand in seinem PAP klar ersichtlich Unsinn gemacht hat und Du dieses zum Anlass nimmst, für Struktogramme anstelle eines Programmablaufplans zu werben?
Es hat ganz bestimmt sehr viel Sinn, wenn man für große Projekte prinzipielle Programmverläufe visualisiert, zum Beispiel in einem Struktogramm oder einem Programmablaufplan. Je komplexer das Projekt, desto wichtiger ist es, die Übersicht zu behalten und genau dann kommen solche Visualisierungen ins Spiel. Aber für den Hobbybastler, der für seine Seite ein kleines JavaScript schreiben möchte, um irgendeine kleine Spielerei damit umzusetzen, sind sie Overkill.
Es hat sich mittlerweile bewährt und herumgesprochen, dass man in modernen Hochsprachen mit gut strukturiertem Code und sprechenden Funktions-, Objekt- und Variablennamen eine ähnlich gute Übersichtlichkeit erreichen kann, wie es Visualisierungen vermögen. Daher ist bei solcherart geschriebenem Code ein Struktogramm tatsächlich vernachlässigbar.
Du schreibst von SAP und JavaScript. Keine Ahnung, ob man da mit angemessenem Coding-Stil auch ohne Struktogramm zurecht kommen kann. Wie in Deinem Bild erkennbar, scheint der von Dir vorgefundene Code aber Kraut und Rüben zu sein. Klar, dass da ein Struktogramm unerlässlich ist - mir leuchtet nur nicht ein, warum darin dann aber (z.B. SQL-)Code steht, anstelle klarer beschreibender Sprache wie hier im Wiki.
Dein Beispiel entkräftet in meinen Augen jedenfalls nicht die Einschätzung auf der von Dir verlinkten Seite.
Liebe Grüße
Felix Riesterer
-
Hallo Felix, der unsinnige PAP soll nur als Demonstration dienen, dass der hier offensichtlich höher bewertete PAP eine ganze Reihe Mängel beinhalten kan, die in einem Struktogramm nicht auftreten können. Übertreibung macht anschaulich ...
Der Auszug aus einem generierten Struktogramm zeigt Fehler, wie das hier angesprochene doppelte Coding, generell ist das Coding aber durchaus sinnvoll. Es gibt oft mehr als nur einen Geradeausweg in der Logik. Das Struct - Beispiel habe ich nur gewählt, weil ich es bereits hatte. Ob nun in Abap oder Javascript, der Inhalt ist dabei egal.
Wenn wir nur von ein paar Zeilen Javascript für einen Hobby - Bastler ausgehen, ist ein Struktogramm overkill, da hast Du Recht.
Ich nutze SELFHTML aber auch gelegentlich zum Nachschlagen in der professionellen Webseiten - Gestaltung. Mir geht es deshalb auch um Coding, das mehrere tausend Zeilen lang sein kann, dann kann eine klare Struktur vorab eine riesige Hilfe sein. Sprechende Namen von Variablen und Funktionen helfen da nicht mehr viel weiter.
-
-
Hallo StrucFan,
niemand verbietet Dir, Struktogramme einzusetzen.
Und wir werten sie auch nicht ab. Wir stellen lediglich – so wie die Wikipedia – fest, dass sie out sind. Das ist keine Wertung, sondern eine Zustandsbeschreibung. Nassi-Shneiderman-Struktogramme (NSS) stammen aus den 70ern. Und heute programmiert man komplett anders. Standardwerke wie "The Art of Computer Programming" von Knuth zeigen Beispielcode, bei dem es einem heute die Zehnägel aufrollt.
Ich habe 1988 das Abschlussprojekt meiner damaligen Ausbildung per NSS dokumentiert. Ich hätte auch PAPs malen können, aber die NS Bildchen ließen sich - wie Du selbst gemerkt hast, ganz gut automatisch generieren und dafür ein Tool zu schnitzen war eine nette Fingerübung. Und es war auch eine Erziehungsmaßnahme: wenn das Tool über dem Code abrauchte, war er nicht gut genug strukturiert 🤣
Tatsächlich ist das nachträgliche Dokumentieren per NSS aber nicht der Zweck dieser Bildchen, sondern sie sollen Dich beim Top-Down Entwurf bei strukturierter Programmierung unterstützen. Aber wer verwendet dieses Paradigma heute noch – in Reinform, meine ich.
Aber seit damals habe ich keinen einzigen Nassi mehr geshneidert, sondern habe OOP gelernt und festgestellt, dass ein OO-Programm mit Klassen und vielen Methodenaufrufen sich einer NS Darstellung entzieht. Bzw. das Diagramm keinen Mehrwert bietet, weil Methoden typischerweise so kurz sind, dass die Logik offensichlich ist.
Bereits bei prozeduraler Programmierung ist NS nicht mehr sehr nützlich, weil die Musik nicht in den Prozeduren selbst spielt, sondern in ihrer Kombination und den Datenflüssen.
Deine Argumente pro NS sind eigentlich Beweise für ihre Obsoletheit: Du hast sie zur Dokumentation von verknotetem Legacy-Code verwendet.
Tatsächlich habe ich schon lange mehr keine Code-Dokumentation auf Anweisungsebene mehr gesehen. Das ist sinnlos. Gut kommentierter Code spricht für sich selbst. Dokumentieren muss man, warum bestimmter Code etwas tut und wie die vielen kleinen Bausteine interagieren. Und dafür bietet NS keinen Vorteil.
Bei einem Event-orientierten JavaScript-Programm sind sie dann vollkommen nutzlos. Ich kann NSS oder PAPs der einzelnen Eventhandler zeichnen. Über die Funktionsweise des Gesamtkunstwerks sagt das Null Komma Garnichts aus. Leider.
Rolf
--
sumpsi - posui - obstruxi -
Ein Struktogramm wächst in die Breite, das heißt irgendwann wird es chaotisch. Was siehst du da als Vorteil zum Ablaufplan? Den kann man doch auch sinnvoll ordnen und wenn es zu eng wird, führt man die Pfeile eben wo hin wo Platz ist.
Wie in der Praxis überhaupt solche Diagramme erstellt werden, ist ja eine ganz andere Sache. Zeit hat man eh keine, und selbst wenn man es mal macht ist es nach der nächsten Änderung wieder ungültig. Dann hat man ein irreführendes Diagramm, was schlimmer ist gar kein Diagramm.
Als Negativbeispiel ein PAP, der an kritischer Stelle einfach auf ein Wunder verweist - im Struktogramm nicht möglich.
Wie verhindert ein Struktogramm dass jemand irgendwo ein Wunder erwäht?
-
Hallo,
Ein Struktogramm wächst in die Breite, das heißt irgendwann wird es chaotisch. Was siehst du da als Vorteil zum Ablaufplan? Den kann man doch auch sinnvoll ordnen und wenn es zu eng wird, führt man die Pfeile eben wo hin wo Platz ist.
oder man tut das, was man bei der Softwareentwicklung sowieso gern tut: Man modularisiert. In diesem Fall: Man nimmt Code aus dem linearen Fluss heraus und steckt ihn in eine Funktion.
Das visualisiert man dann im Struktogramm oder Flowchart dadurch, dass die Funktion nur noch als ein Block dargestellt wird, und der Ablauf innerhalb der Funktion dann in einem untergeordneten Diagramm.
Wie in der Praxis überhaupt solche Diagramme erstellt werden, ist ja eine ganz andere Sache. Zeit hat man eh keine, und selbst wenn man es mal macht ist es nach der nächsten Änderung wieder ungültig. Dann hat man ein irreführendes Diagramm, was schlimmer ist gar kein Diagramm.
Das führt uns wieder zu Rolfs Standpunkt: Sauber geschriebener und strukturierter Code dokumentiert sich zum großen Teil selbst.
Einen schönen Tag noch
Martin--
Manchmal kann man gar nicht so viel fühlen, wie man denkt.
Und manchmal fühlt man so viel, dass man gar nicht denken kann. -
Hallo encoder, zum Thema Struktogramm - Breite: siehe vorigen Kommentar.
Ich habe in der Praxis genügend mangelhaften Code gesehen, eben weil die Entwichler sich NICHT vorab genügend Gedanken darüber gamacht, haben, wie sie ihren Code strukturieren - teilweise mit riesigen Folgeaufwänden.
Dass ein Struktogramm veralten kann, ist normal, dann ist das Coding aber -hoffentlich- bereits einigermaßen sauber strukturiert. Das Problem der Veralterung betrifft den PAP aber ebenso.
Ein Struktogramm hat aber immer genau EINEN Eingang und EINEN Ausgang. Einen Pfeil ins Nirwana gibt es da nicht. Im PAP ist es auch kein Hindernis, die Blöcke mit sinnfreien Pfeilen zu verknüpfen... Wenn das NSD als veraltet anzusehen ist, dann der PAP erst recht.
-