Unvergessen: Nassi-Shneiderman-Diagramm

Entwicklerlegende Robert „Uncle Bob“ Martin nennt in seinem Buch The Clean Coder diverse Grundkonzepte, die ein professioneller Entwickler kennen sollte. Eines aus der Liste fiel mir besonders auf, da ich genau wusste, dass es Teil des Studium war und ich dennoch keine Idee hatte, was es denn ist: Das Nassi-Shneiderman-Diagramm. Es handelt sich dabei um einen Programmablaufplan, der beispielsweise so aussehen kann:

Nassi-Shneiderman-Diagramm
Nassi-Shneiderman-Diagramm

 

Leider deckt dieses kleine Beispiel auch schon so ziemlich das gesamte Konzept ab. Auch die Wikipedia bescheinigt diesem Diagrammtyp nur eine geringe Praxisrelevanz. Das überrascht mich wenig, lässt sich das selbe doch in jeder Programmiersprache über Assembler schneller und verständlicher ausdrücken.

Ein Nassi-Shneiderman-Diagramm ist aufwendig, von kaum erkennbarem Nutzen, wird von niemandem gebraucht und ist schlicht ein Relikt aus früheren Zeiten. Warum es also kennen? Weil man das gleiche auch von der FDP sagen kann. Auch wenn man es sich heute kaum mehr vorstellen kann, irgendwann haben die Leute so etwas mal als sinnvoll und wichtig angesehen.

Um diesen kleinen Teil Informatikergeschichte zu wahren, bietet sich eine Assoziationstechnik an. Der Name drängt das Bild „Nasser Schneider-Mann“ geradezu auf. Man stelle sich daher einen nassen Mann vor, der mit einer Schere den Schnittlinien des Diagramms folgt und so die einzelnen Elemente ausschneidet.

Nasser-Schneider-Mann-Diagramm
Nasser-Schneider-Mann-Diagramm

Ich habe selber mal zu Stift und Schere gegriffen und werde sich nie mehr vergessen, was es mit den Diagrammen komischen Namens auf sich hat. Laut Onkel Bob ein Schritt in Richtung Professionalität. Aber da bin ich nach dieser Aktion doch eher skeptisch…

13 thoughts to “Unvergessen: Nassi-Shneiderman-Diagramm”

  1. Hallo, ich setze Nassi Shneiderman-Diagramme seit Jahren erfolgreich in der Softwareentwicklung ein, um zu vermitteln, was gecoded werden soll. Alternativen wie Flussdiagramme oder irgendwas aus dem UML-Baukasten haben sich als weniger nützlich erwiesen.

    1. Richtige Programme? Also richtig komplexe Programme? So ein Diagramm würde ich gern mal sehen.

      Wie gesagt, als Alternativen sehe ich weniger andere Diagrammtypen als vielmehr richtigen Code, der das selbe ebenso verständlich ausdrückt. Wer unbedingt abstrahieren will kann ja zu irgend einem Pseudocode greifen.

    2. Das würde ich auch gerne mal sehen. Schon bei drei Bedingungen ineinander wird es total unübersichtlich oder ich habe nicht verstanden worum es geht …

  2. In der Tat nutze ich die Diagramme für „richtig komplexe“ Systeme. Natürlich nicht ein einziges, sondern eine Vielzahl davon. Wann immer ein Diagramm zu komplex würde, ist das das Signal, eine weitere Modularisierung/ Zerlegung vorzunehmen. Immer wenn ich eine Logik nicht mehr verständlich darstellen kann, ist dies ein klares Signal, dass ich mein Design ändern muss. Das Ergebnis ist eine Vielzahl von kleinen, separat testbaren Upros/ Methoden/ Objekten/ Units, die von einer großen Projektgruppe rasch realisiert werden können.
    Ein zweiter kritischer Punkt (bei allen Arten von formalisierten Designs) ist der „angemessene“ Abstraktionsgrad, der auch abhängig vom Erfahrungsstand der Projektmitarbeiter gewählt werden sollte.
    Grüße!

  3. Wer Nassi-Shneiderman-Diagram Relikt und unnütz nennt, hat wenig Ahnung von dessen Bedeutung. In der guten alten Zeit pflegte man in Schleifen zu programmieren. Das Ergebnis war nur erträglich, weil Computer wirklich nur wenig zuwege brachten. Später nannte man es Spagetti-Programmierung. Das Nassi-Shneiderman-Diagram war ein Kennzeichen der strukturierten Programmierung. Damit war das Ende der Ära der per Definitionem nicht prüfbarer Programme eingeläutet.

    Was ist das Besondere daran? Es hat einen Eingang zur Umwelt, und einen definierten Übergang zur selben. Dazwischen läuft alles nur vorwärts. Dadurch wird jedes Modul prüfbar, und man kann es durch beliebig andere ersetzen, die aus den gleichen Ausgangsdaten die gleichen Ausgangsdaten in definierter prüfbarer Prozedur erzeugen. Die gleiche Idee hatten einst die Schöpfer des heutigen (Festnetz)Telefonsystems so um 1920. Zwischen Schnittstelle zu Schnittstelle kann jede Technik eingesetzt werden, sofern diese die erforderlichen Parameter einhält. Daher konnten die späteren Generationen dieses System beliebig ausweiten und ständig modernisieren.

    Die ach so schlauen IT-Leute haben in den 1980er Jahren mit CIM (computer integrated manufacturing) Systeme geschaffen, die nicht nur die Wirtschaft Milliarden gekostet haben, sondern einen verheerenden Schaden für das Ansehen der Technik angerichtet. Die hatten nicht verstanden, was sauber definierte Schnittstellen bedeuten. Das Gegenteil von Spagetti.

    Dem Festnetztelefonsystem kann hinsichtlich seiner Berechenbarkeit derzeit kein ähnliches System das Wasser reichen. Es ist ein Relikt aus alten Zeiten. Aber sicher und verlässlich. Keine Funklöcher, die man als Ausrede benutzen kann.

    Wofür kann man das Nassi-Shneiderman-Diagram benutzen? Ich habe damit zum Beispiel ein genormte Prozeduren zur Auswahl bzw. zum Prüfen der richtigen Auswahl eines Dialogfeldes , eines Eingabemittels u.ä. entwickelt. Eine exotische Anwendung war die Überprüfung der Alarmprozedur eines Kernkraftwerkes. Ich konnte nicht nur die Fehler aufdecken, sondern auch noch das Alter des Autors der Prozedur vorhersagen. Er musste einer sein, der noch die Change hatte, Spagetti zu programmieren. Stimmt!

    Wer genug Zeit hat, sich mit billigen Reimen diese zu vertreiben, sollte etwas davon nehmen, sich zu erkundigen, was der Herr Shneiderman noch so entwickelt hat. Direkte Manipulation z.B. Ach ja, wieder ein alter Zopf.

    1. Niemand hat hier die geschichtliche Bedeutung in Frage gestellt (danke für die Ausführungen), es geht nur um die heutige Relevanz. Und die erschien mir, Wikipedia und den meisten anderen Leuten die ich kenne nicht mehr wirklich gegeben. Aber du bist jetzt schon der zweite, der das Gegenteil behauptet, somit scheint es ja doch noch seine Anwendungsgebiete zu haben. Gut zu wissen.

      Was du übrigens billige Reime nennst ist eine simple aber wirkungsvolle Assoziationstechnik. Man erzeugt Bilder zu Begriffen, die die Bedeutung unterstreichen. Diese kann man sich besser merken. Wie wohl die meisten Leute habe ich nach dem Informatikstudium schnell vergessen, was Nassi-Shneiderman-Diagramme sind. Seit diesem Artikel nicht mehr. Insofern war das sicher alles andere als vergeudete Zeit.

  4. Erstelle ein Struktogramm welches zwei Zahlen einliest und in den Variablen z1 und z2 speichert. Speichere die Summe in der Variablen summe und den Quotienen in quotient. Anschließen soll die Summe und der Quotienten am Bildschirm augegeben werden.
    Ich verstehe das nicht , Kannt ihr mich helfen

  5. Es ist überaus Schade dass ein Nassi-Shneiderman-Diagramm nicht mehr gelehrt wird. Einmal verstanden, ist es ein unersetzliches Hilfsmittel. Persönlich nutze es seit über 25 Jahren erfolgreich in kleinen und auch komplexeren Systemen. Wie hier auch schon erwähnt, ist es sinnvoll (auch ohne Nassi-Schneiderman-Diagrammen) komplexe Zusammenhänge in kleinere Einheiten zu zerlegen. Denn: Din A1 Ablaufpläne liest eh keiner. Insbesonders das Umsetzen in einen Programmcode ist wesentlich einfacher als in anderen Ablaufplänen und Flussdiagrammen.

  6. wäre es nicht toll gewesen, wenn man einen editor gehabt hätte, der existierenden Sourcecode einliest, ihn in nassi darstellt, man den spaghetti-code ordnet und wieder abspeichern könnte? sozusagen in Nassi programmieren und nicht nur dokumentieren?
    Ja sowas gab es , wurde ’ne zeit lang von siemens vertrieben, war natürlich scheißteuer und hat sich so nicht weiter verbreitet
    wird heute noch vertrieben:
    http://www.easycode.de/produkte/easycode-cc/struktogramme.html

Kommentare sind geschlossen.