Diskussion:Nassi-Shneiderman-Diagramm

aus Wikipedia, der freien Enzyklopädie

Kursiver Text Ebene 2 Überschrift

n Diagrammen aufzeigen konnten. Diesen Satz verstehe ich nicht: Um welchen Berechenbarkeitsbegriff geht es? Und welche Rolle spielen die Bildchen beim Beweis? Zumindest sollte man eine Referenz angeben, wo der interessierte Leser die Details finden kann. MH 19:36, 15. Mär 2004 (CET)

Hm mein Lehrer sagt das diese Diagramme für jedermann -- also auch nicht programmierer -- verständlich sein sollen. Für mich persönlich liest sich das while konstrukt auch besser, aber seiner meionung nach nicht verständlich genug. Bei der folgenden prüfung als Fachinformatiker wäre dieses NS schlicht falsch. DIe frage für mich... Wer hat recht?

Aus meiner Erfahrung heraus, verstehen Laien PAPs besser als Struktogramme. PAPs sind in Diskussion über Algorithmen und Abläufe auch leichter aus dem Stehgreif zu zeichnen. Bei solchen Diskussionen (auch mit Kunden) sind die Gedanken ja zumeist noch unstrukturiert und deshalb helfen PAPs schon sehr. Struktogramme sind allerdings (in der Praxis) so gut wie nutzlos (meine Meinung). --subsonic68 06:24, 25. Apr 2005 (CEST)

Zuweisung

Laut meinen Programmierlehrern erfolgt eine Zuweisung nicht wie im Artikel gemeint per := ("Eine Zuweisung wird durch einen Doppelpunkt, gefolgt von einem Gleichheitszeichen dargestellt und ist von einem Vergleich mit einem Gleichheitszeichen in einer Kontrollstruktur zu unterscheiden.") sondern mit einen Pfeil (<-). Entsprechend wandelt auch SturkED diesen um. Für mich ist diese Art von Zuweißung auch logischer, da Programmiersprachen unabhängig.

Aus diesen Grund habe ich diesen Abschnitt geändert. Kound 15:18, 30. Mai 2006 (GMT+1)

Titel

Sollten wir nicht lieber den Titel "Struktogramm" verwenden? Stern 09:17, 9. Jan 2006 (CET)'

--Ich wär dabei87.167.227.91 14:53, 21. Feb. 2007 (CET)

Ein- und Ausgaben

Soweit ich mich an meinen Programmierunterricht erinnern kann, haben wir die Ein- und Ausgaben nicht mit einem "normalen" entsprechend beschrifteten Anweisungsstrukturblock realisiert, sondern eher à la:

Datei:StruktoIO.gif

Das verletzt z. T. die Konventionen bezüglich der formalen Abmessungen des Diagramms. Deshalb frage ich mich, ob das so überhaupt korrekt ist. mfg --Corny2048 19:16, 5. Okt 2006 (CEST)

Diese Symbole sieht man hin und wieder. Nach DIN sind sie aber nicht vorgesehen - ebenso wie übrigens der Unterprogrammaufruf, der so nicht in der DIN enthalten ist.

Nicht abweisende Schleife

IMHO widersprechen sich der Text in der Abbildung und die Beschreibung. Die Abbildung zeigt eine repeat-until-Schleife, d.h. die Schleife wird abgebrochen, wenn die Bedingung erfüllt ist. Die Beschreibung deutet aber auf eine do-while-Schleife hin, d.h. die Schleife wird abgebrochen, wenn die Bedingung verletzt ist. Was ist denn nun in einem Struktogramm nach DIN richtig? 

 - Korrekt, die ursprüngliche Version ist richtig, ich habe das mal zurückgesetzt...

M.E. bedeutet "Nicht Abweisen" Annehmen. Mein Vorschlag besteht darin, die Negationen im Erläuterungstext in Positivabfragen zu wandeln und dies einheitlich zu formulieren.

Kommt kein Widerspruch mache ich das demnächst. --Ref1fois (Diskussion) 09:51, 2. Feb. 2014 (CET)

Wertender / emotional gefärbter Satz

"Bei der Abbildung objektorientierter Programmkonzepte nach UML finden Nassi-Shneiderman-Diagramme keine Anwendung, da man dort mit erweiterten Programmablaufplänen auszukommen glaubt." - Ist meiner Meinung nach Fehl am Platze. --(nicht signierter Beitrag von 134.34.16.71 (Diskussion) 15:53, 11. Jun. 2008 (UTC))

und was wär netter? finden die anwendung oder nicht? zumindest inhaltlich korrekt sag ich mal... --Heimschützenverein 18:17, 11. Jun. 2008 (CEST)
Halte den Satz auch für unpassend. Wo ist der Beleg, dass man in der UML bewusst auf diesen Diagrammtyp verzichtet hat, da man ohne ihn auskäme? In eine Enzyklopädie gehört das nicht. Vorschlag: "Bei der Abbildung objektorientierter Programmkonzepte nach UML finden Nassi-Shneiderman-Diagramme keine Anwendung. Die UML kennt andere Diagrammtypen, um Abläufe und Dynamik zu beschreiben." -- (nicht signierter Beitrag von 84.143.252.224 (Diskussion) 19:57, 21. Nov. 2008 (UTC))
selbstverständlich haben sich die uml-entwickler ganz bewusst gegen Nassi-Shneiderman-Diagramme entschieden, weil die schließlich fast gleich alt sind... eine unbillige wertung wäre es, wenn ich schreiben würde, dass "die entscheider aufgrund einer psychischen unzulänglichkeit unbewusst die Nassi-Shneiderman-Diagramme nicht verwenden und stattdessen die nachteiligen Programmablaufpläne einsetzen". stört das wort "glaubt"? dann kann man ja "einsetzt" schreiben (und den rest anpassen)... --Heimschützenverein 21:15, 21. Nov. 2008 (CET)
Ich habe den bemängelten Satz entfernt, da er nur wertet und keinen substanziellen Beitrag zum Artikel liefert. --Stefan Birkner 16:31, 23. Nov. 2008 (CET)
gilt das dann auch für den abschnitt "praxisrelevanz"? da steht das nochmal, bloß etwas verdreht (aktivitätsdiagramme -AD- sind erweiterte PAPe, aber PAPe sind keine vereinfachten ADe -- wegen der zeitlichen reihenfolge)... danke... --Heimschützenverein 16:54, 23. Nov. 2008 (CET)
ich hab den Abschnitt dann mal auch gelöscht, da er neben der falschen wertung der bedeutung auch noch ursache und wirkung durcheinander brachte... --Heimschützenverein 09:42, 24. Nov. 2008 (CET)
Und wieder revertiert, die schulische Relevanz ist definitiv gegeben, von POV kann da keine Rede sein. Der Tom 09:55, 24. Nov. 2008 (CET)
quelle? und was hat das mit den aktivitätsdiagrammen zu tun? ich werd dann mal ne 3. meinung einholen... --Heimschützenverein 09:59, 24. Nov. 2008 (CET)
Ich habe jetzt keinen Lehrplan zur Hand, kenne aber die schulische Ausbildung im Gymnasium durch meine Tochter. Und da wurde das sehr wohl trainiert. Zu dem anderen Satz kann ich nix sagen, außer dass der Löschgrund keinesfalls „POV“ sein kann. Der Tom 10:08, 24. Nov. 2008 (CET)
in der einleitung hat POV doch auch als löschgrund gereicht... es ist eben nur die unbelegte und in letzterem fall (erster absatz im abschnitt praxisrelevanz) auch falsche sicht von irgendwelchen leuten... ob man nun die entscheidung des lehrers an irgendeiner schule verallgemeinern kann, wage ich zu bezweifeln... der wesentliche vorteil, dass NSDe sich leicht in quellcode umsetzen lassen, wird gar nicht erwähnt (bei einigen PAPen wünscht man sich das goto zurück), stattdessen sollen NSDe also kindergarten und für professionelle anwendung ungeeignet sein...? dafür hätte ich gern eine eingängige quelle (bitte nich microsoft)... --Heimschützenverein 10:24, 24. Nov. 2008 (CET)
Ich kann Toms Einschätzung aus eigener Erfahrung bestätigen: NSD wurden mir Ende der 80er Jahre im Informatikunterricht in der Schule als vorteilhaft gegenüber PAP angepriesen. Von UML (bzw. deren Vorläufern) war damals keine Rede. Im Informatikstudium (nach der Wende) und in der Softwareentwicklungspraxis kann ich mich kaum erinnern, jemand mit NSD (oder PAP) hantieren gesehen zu haben. In der Sekundarstufe II mögen NSD aber durchaus ihre Berechtigung haben, und sei es nur als graphische Alternative zu Pseudocode. Fazit: Ich finde den Abschnitt in der Form vor der Löschung durch Benutzer:Heimschützenverein völlig OK, bin aber auch mit der aktuellen Form einverstanden. Auf jeden Fall sollte er im Artikel bleiben, schon um den Bezug zu UML herzustellen. Ein siehe auch wäre mir da zu wenig aussagekräftig. Vielleicht sollte man noch herausarbeiten, dass NSD auf einer anderen Abstraktionsebene arbeiten als UML: Sie eignen sich gut zur Darstellung einer Prozedur/eines kleineren Algorithmus, wärend UML m.E. doch eher seine Stärken bei der Modellierung großer, komplexer, modularer Systeme nach OO-Prinzipien ausspielt. Und dann gibt es ja noch Agile Softwareentwicklung (worauf vielleicht auch verwiesen werden sollte), wo all diese abstrakten Entwurfstechniken plötzlich keine große Rolle mehr zu spielen scheinen. Aber ich spreche hier eher als Zeitzeuge denn als Experte und möchte nicht gern den Artikel selbst bearbeiten. --Thüringer ☼ 14:32, 28. Nov. 2008 (CET)

Bei der vorhergehenden Diskussion erscheint es mir, als ob in diesem Artikel Sachen eingefügt werden sollen, die sich allgemein auf Diagramme beziehen. Da dies der Artikel zu Nassi-Shneiderman-Diagrammen ist, scheint mir eine Erwähnung von UML und anderen Diagrammarten, die mit NSD nichts zu tun haben, fehl am Platz. Dazu sollte eher ein Artikel zu Diagrammen im Softwareentwurf erstellt werden. --Stefan Birkner 23:47, 29. Nov. 2008 (CET)

ja, hast wohl recht, aber bis dahin kann man es ja als gedächtnisstütze stehen lassel... son bisschen querverweise und vergleiche... --Heimschützenverein 14:16, 2. Dez. 2008 (CET)
Das ist in Ordnung. Doch der nächste, der hier noch mehr schreiben will, sollte bitte den oben vorgeschlagenen Artikel erstellen. --Stefan Birkner 18:45, 2. Dez. 2008 (CET)

Formatvorlage, Struktogrammblatt als Zeichenhilfe

Ich habe vor einiger Zeit eine Zeichenvorlage (Papiertemplate) fuer das manuelle Zeichnen von Struktogrammen erstellt. Die Historie dazu ist in Weblink gelöscht dargestellt; Bei Interesse kann das gerne in die Weblinks aufgenommen werden. Danke (Der vorstehende, nicht signierte Beitrag – siehe dazu Hilfe:Signatur – stammt von TrebroN (Diskussion • Beiträge) 16:00, 2. Dez. 2008 (CET))

Linkinfo hierzu beim Autor abholen. Der Tom 16:14, 2. Dez. 2008 (CET)

struktogramm.dot und Standards

Ich habe mir die Struktogramm.dot mal angesehen, auch wenn ich normalerweise nicht mit Word sondern mit LaTeX arbeite. Diese Vorlage hält sich überhaupt nicht an die Standards! Bestimmte Zellen werden grau eingefärbt, da hab ich mich durch VB-Spaghetticode geschlagen um das Grau schließlich zu einem Weiß zu machen. Aber auch Fallunterscheidungen:

Anstatt der normalen Form sieht es so aus:

Falls

bed1 -> block

bed2 -> block

bed3 -> block


sonst -> block

Irgendwo kann das nicht sein (ganz zu schweigen von einer für ungeübte Word-Anwender schierigen Installation, und einer Validierung der Makros). Deshab bin ich dafür, diese Struktogramm.dot, die auch noch behauptet, sich an die Nassi-Shneiderman-Standards zu halten, herauszunehmen.

Aufruf

Ist der Aufruf nicht ein unbedingtes GOTO? --DSGalaktos 09:11, 21. Mär. 2011 (CET)

mehr n GOSUB, weil ja am ende der aufgerufenen routine ein rücksprung an den dem aufruf folgenden befehl kommt... :-) --Heimschützenzentrum (?) 09:55, 21. Mär. 2011 (CET)

"Kontrollstrukturen"

Die falsche Übersetzung Kontrollstrukturen für control structures ist wohl nicht auszurotten. To control bedeutet hier steuern, weil die Abläufe gesteuert und nicht kontrolliert werden! Das Deutsche verwendet hier offensichtlich mehrere verschiedene Wörter (steuern, regeln, kontrollieren), die präziser sind als das Englische control. Programmable Controller sind Ablaufsteuerungen in der Industrie. Ob das jetzt hilft? (nicht signierter Beitrag von 84.128.85.149 (Diskussion) 20:05, 1. Feb. 2014 (CET))

Kontrollstruktur scheint der übliche Begriff zu sein, auch wenn er n misnomer sein mag... --Heimschützenzentrum (?) 23:27, 1. Feb. 2014 (CET)

4.1 Beispiel

Da fehlt im Struktorgramm der Block "Eingabe/Zeile einlesen", das im Pascal-Code mit "readln"genannt ist.--Mideal (Diskussion) 13:57, 20. Aug. 2015 (CEST)

stimmt... ich hab's mal gefixt... --Heimschützenzentrum (?) 20:32, 21. Aug. 2015 (CEST)

DIN 66261 / tatsächlicher Wortlaut

über die tatsächlichen Begriffe gemäß DIN 66261 besteht scheinbar Uneinigkeit (einerseits Online-Quellen, andererseits eine nicht onliae verfügbare Quelle von 1985 in schweizerischer(?) Sprache...)... von der Formatierung ganz abgesehen... die Sichtung wichtiger Änderuagen verzögernder edit war: [1], [2]... ich werde die Begriffe einmal vorläufig einpflegen... --Heimschützenzentrum (?) 10:13, 2. Jun. 2016 (CEST)

Weblink

"NSD-Editor - quelloffener Editor in Borland Delphi; kann Nassi–Shneiderman-Diagramme aus Quellcode in C und Pascal generieren." ... stimmt so nicht: Umgekehrt wird ein Schuh d'raus: "... kann aus Nassi–Shneiderman-Diagrammen Quellcode in C und Pascal generieren." Aber toll, dass der Quellcode dabei ist! -- 94.221.188.117 03:40, 18. Jun. 2017 (CEST)

Endlosschleife, Sonderfall Begin=End=true

imho ist eine Endlosschleife ein Zustand eines Programms, in dem es scheinbar (und tatsächlich) hängenbleibt! Das entsprechende Struktogramm wird eher für eine Zählschleife mit einer vorgegebenen Anzahl von Wiederholungen verwendet. Leider findet man den Begriff der Endlosschleife in einigen Veröffentlichungen wieder, was aber die Sinnhaftigkeit des Begriffs nicht verbessert. Ich schlage vor, dieses NSD umzubenennen in "Schleife mit vorgegebener Anzahl von Wiederholungen" oder eben schlicht "Zählschleife! E.K. (nicht signierter Beitrag von 2001:16B8:50F5:F000:C519:28C2:41E3:E693 (Diskussion) 18:38, 3. Jun. 2020 (CEST))

Weblinks entfernt

structorizer.fisch.lu wurde zusammen mit einem anderen Softwarelink aus dem Artikel entfernt, wogengen sich der namenlose Autor, oder jemand der behauptet es zu sein, auf VM beschwert hat. Offenbar kein Vandalismus, sondern Dissens über Artikelinhalte. Ich stelle es deshalb hier zur Diskussion. Gruss, –MBq Disk 14:31, 5. Mai 2022 (CEST)

Meines Erachtens wäre es logisch, unter Weblinks keinen Anbieter zu nennen. Das ist der gegenwärtige Zustand, der mir völlig korrekt erscheint.--Mautpreller (Diskussion) 14:35, 5. Mai 2022 (CEST)
Die beiden deutschen Anbieter halte ich für weiterführend. --Ralf Roletschek (Diskussion) 14:36, 5. Mai 2022 (CEST)
Warum? Für eine Auswahl muss es nachvollziehbare Kriterien geben, gerade bei privaten Anbietern, sonst beschwören wir uns selber Ärger herauf.--Mautpreller (Diskussion) 15:53, 5. Mai 2022 (CEST)
Mein Name ist Johannes Kässinger und ich bin der Inhaber der Seite sbide.de. Im Rahmen meiner Bachelorarbeit hatte ich nach bestehenden Systemen zum Anfertigen und Ausführen von Struktogrammen gesucht. Hier gab es quasi nichts brauchbares. Der structorizer.fisch.lu war 2010 noch einem Zustand, in dem man Diagramme zwar zeichnen, aber nicht ausführen konnte. Ich habe dann versucht ein web-basiertes eigenes System zu bauen, welches dann auch in den Unterricht eingebunden werden kann und nun auch wird. Alle Übungen der Vorlesung können damit umgesetzt werden. 2020 hatte ich hier bereits eine Diskussion bezüglich meiner Seite wonach sie wieder aufgeführt wurde, nachdem ich noch Anpassungen vorgenommen hatte. (hier) Damals waren aber auch sehr viele, teils nicht mehr aktive Seiten verlinkt und es gibt meines Wissens nach wie vor keine weiteren, die den Funktionsumfang von sbide.de und schon gar nicht den aktuellen Stand des structorizer.fisch.lu abbilden. structorizer.com war ein Berufsschulprojekt, dass ich am "originalen" Structorizer orientierte, jedoch keinerlei Funktion (außer das Zeichnen) aufwies. diese Seite wird demnächst jedoch abgeschaltet bzw. umgeleitet. Ich halte ich für absolut richtig, darauf zu achten, dass hier nicht jede Wald-und-Wiesen-Seite verlinkt wird. Jedoch haben beide anfangs genannten Seiten ihre Daseinsberechtigung und tragen in der Lehre aktiv dazu bei, dass Struktogramme weiterhin verwendet werden. Meine Seite ist zB auch auf dem Tablet ausführbar und bietet neben der reinen Zeichnung auch die Möglichkeit der Ausführung, Beobachtung der Variablenzustände, Code Generierung und deren Zusammenhang, ebenso der structorizer.fish.lu in der aktuellen Version. Beide sind kostenlos und sind für und auch in der Lehre entwickelt und weiterentwickelt worden. Ich kann Ihnen nur von meiner Seite berichten, diese wird regelmäßig genutzt und ist in einer Vorlesung eingebunden. Wenn es weitere Programme mit gleicher Funktionalität gibt, sollten die auch gelistet werden, aber mir sind keine bekannt. Ich würde einfach bitte, dass die beiden Programme sbide.de (web-basiert) und structorizer.fisch.lu (Java) wieder aufgenommen werden würden und damit ihrem Beitrag dazu leisten, dass Struktogramme weiterhin genutzt werden und Menschen Spaß daran haben. Denn diese Rückmeldung herhalte ich seit der Erstellung 2014 immer wieder. Der Ersteller von structorizer.fisch.lu ist derjenige, der sich auch beschwert hatte, das kann ich verifizieren. Wir stehen in Kontakt und wollen das Thema NSD gemeinsam lebendig halten. Ich danke allen für Ihre Arbeit, Wikipedia sauber zu halten. Auch schön wäre, wenn die beiden Programme dann gesetzt wären und solange sie angeboten werden, damit in 2 Jahren nicht eine neue Diskussion entsteht. Vielen Dank! --Johannes1306 (Diskussion) 21:29, 5. Mai 2022 (CEST)
Es sind weiterführende Infos, wenn man dem Leser mitteilt, mit welchen Hilfsmitteln er Diagramme zeichnen kann. Dabei sind die Links zu bevorzugen, die deutschsprachig sind. Es ist nichts gegen private Anbieter zusagen, da es offenbar nur private Anbieter gibt.--Ralf Roletschek (Diskussion) 23:11, 5. Mai 2022 (CEST)
Wenn überhaupt, dann nur deutschsprachige Links. Aber eigentlich wollen wir hier in der Enzyklopädie das NSD erkären, nicht privaten Anbietern dabei helfen, ihre Programme bekannter zu machen und zu verbreiten. Dafür ist hier der falsche Ort. Egal, ob kostenlos oder nicht. Von daher bin ich eigentlich prinzipiell gegen derartige Links. Wer will definieren, welcher Anbieter wichtig ist und welcher weniger? --Der Tom 08:11, 6. Mai 2022 (CEST)
Wenn es nur eine Handvoll Anbieter gibt, braucht man keine Auswahl. Es ist auch völlig unerheblich, ob die verlinkten Seiten privat sind oder von einer Firma angeboten werden. --Ralf Roletschek (Diskussion) 12:11, 6. Mai 2022 (CEST)
Das mag hier stimmen. Es geht aber um den generellen Umgang mit derartigen Weblinks, nicht nur zu diesem Thema. --Der Tom 12:15, 6. Mai 2022 (CEST)
@Tom: Generell hast Du Recht. Allerdings unterscheidet WP:WEB nicht zwischen privat und nicht-privat, sondern zwischen kommerziell und nicht-kommerziell. Die Regelseite verbietet ausserdem die kommerziellen Seiten nicht pauschal, sondern hebt auf ihre Informationsqualität ab: „ „Vermeide Websites, bei denen der kommerzielle Charakter im Vordergrund steht.“ Es müssen hochwertige Infos sein, die im Artikel selbst keinen Platz mehr haben. Shops haben in der Regel solche Infos nicht. Andererseits sind Links zu einschlägiger Software zulässig, wenn anzunehmen ist, dass sie lernenden Lesern weiterhelfen. Gerade Lehrbeispiele und Ausbildungsanwendungen haben wir im Informatikbereich sehr oft verlinkt, zB bei Verschlüsselungs- oder Kompressionsalgorithmen. Links zu Downloadseiten sind auch häufig, bei Linux-Distributionen, , IDEs usw.. Ich würde meinen, dass wir die hier diskutierten Links nach diesen Kriterien als Einzelfallentscheidung akzeptieren können. –MBq Disk 14:04, 6. Mai 2022 (CEST)
In diesem Konsens habe ich kein Problem damit, aber nur, wenn sie deutschsprachig sind. --Der Tom 14:06, 6. Mai 2022 (CEST)
Deutschsprachig finde ich kein Argument.--Mautpreller (Diskussion) 19:27, 6. Mai 2022 (CEST)

Nachdem ich die Diskussion gelesen und alle drei Seiten angeklickt habe, scheint es mir vertretbar, diese beiden Weblinks aufzunehmen:

  • sbide.de – Javascript-basierter Struktogrammeditor mit C-Code-Generierung und Simulator zur Visualisierung des Programmablaufs
  • Structorizer - Open-source Struktogramm-Editor für Windows/Linux/Mac.

Der dritte wird a) demnächst abgeschaltet und b) bezieht sich selbst auf die ersten beiden ("Das Original", klickts mal an). Ist also offensichtlich ungeeignet. Mir ist nicht ersichtlich, warum die Sprache, die hier eh allenfalls eine ganz marginale Rolle spielt, hier ein Kriterium sein sollte.--Mautpreller (Diskussion) 19:53, 6. Mai 2022 (CEST)

Noch gestern war die Seite erreichbar und ich fand das Angebot als das Beste der drei. Die Sprache spielt schon eine Rolle, wir sind die deutschsprachige Wikipedia, nicht die englische. Wenn die Sprache keine Rolle spielt, sollte http://pseint.sourceforge.net/?page=descargas.php mit gelistet werden. --Ralf Roletschek (Diskussion) 20:21, 6. Mai 2022 (CEST)
Hallo Rolf, die andere Seite war/ist vom Umfang sehr sehr limitiert. War auch nicht fertig/vollständig. Das Angebot sieht auf den ersten Eindruck nur so aus. Hier besteht das meiste aus der Projektverwaltung. Der Rest ist nicht ausgereift, weder in der Gestaltung noch in der Funktion. Der Autor wollte es deshalb auch abschalten bzw. umleiten. Bei der Sprache stimme ich generell zu, aber für einen erweiterten Umfang gibt es nichts vergleichbares und die Sprache spielt bei beiden Programmen keine Rolle. Auch structorizer.fisch.lu arbeitet mit Symbolen. Ich befürworte Mautprellers Vorschlag. --Johannes1306 (Diskussion) 21:17, 6. Mai 2022 (CEST)
Die Diskussion steht hier nun. Wie läuft das dann weiter? Ich unterstütze deinen Vorschlag. Muss da nochmal abgestimmt werden? Wer kann die beiden Links einfügen? --2A02:8070:7BA:EE00:D22:3D76:2FF5:6859 14:59, 13. Mai 2022 (CEST)
Nochmal die Frage: Wie wird nun weiter verfahren? --Johannes1306 (Diskussion) 10:36, 20. Mai 2022 (CEST)
Mautprellers Vorschlag vom 6.5. ist wohl Konsens. Ich setze ihn im Artikel ein. –MBq Disk 12:39, 20. Mai 2022 (CEST)

Weitere Diagramm-Editoren

--Wikida (Diskussion) 22:45, 24. Mai 2022 (CEST)

Abgerufen von „https://de.wikiup.org/index.php?title=Diskussion:Nassi-Shneiderman-Diagramm&oldid=223146516“