Diskussion:Programmablaufplan/Archiv/1
Shapes/Grafiken
Die Grafiken sind auf jeden fall super! Kompliment!
- Sind Visio-Shapes eigentlich © Microsoft Corp. ?!?
- Wieso Visio-Shapes? Das sind einfache geometrische Formen, die es schon lange vor Visio oder DIN 66001 gab. Niemand hat ein Urheberrecht auf solche trivialen Formen, nicht mal Microsoft. --subsonic68 03:04, 2. Mai 2005 (CEST)
Es gibt auch noch eine etwas neuere variane (sagtzumindest mein Leher gerade) von Zaehlergesteueren schleifen. Ascii:
______________ / bedingng \ ---------------- | v _______________ | block | --------------- | v _______________ | | | | ---------------
-- An wen auch immer - der oder die diese feinen Grafiken als Beispiel reingestellt haben - womit wurden die erstellt ? FYI ich mein die schön Bunten (und schattierten) im Beitrag ;) -- fizzefazze 09:04, 21. Juli 2005 (CEST)
- Archivierung dieses Abschnittes wurde gewünscht von: arilou (Diskussion) 12:14, 25. Sep. 2012 (CEST)
Link
-- Wie schaut es aus, diesen Link noch mit reinzunehmen?, dort gibt es die DIN 66001 1983 : http://www.cabeweb.de/html/din.htm -- Gruß Niels
- Wozu? Sehe keinen Zusammenhang zum Artikel. --Cepheiden 16:28, 5. Jul. 2007 (CEST)
- Zitat: "Die Symbole für Programmablaufpläne sind in der DIN 66001 genormt" - Wo ist da kein Zusammenhang?, zudem wenn auch auf die ältere DIN Norm von 1966 ein Link existiert, und auch im Text immer wieder die Norm von 1983 angesprochen wird. Ich persönlich denke, dass dem interessiertem Leser auch dann die "neuere" Norm zum Vergleich nicht unansprechend ist. Ich fragte mich als erstes - was ist denn da anders ,-) Gruß Niels
- Die Seite beschäftigt sich mit allerlei Normen. Wenn dann sollten der entsprechende Sublink genutzt werden [1]. Wäre unsinnig wenn der Nutzer nochmals alles lesen müsste. Allerdings beinhaltet die Seite kaum neue Informationen. Wie du schon sagtest ist nur die DIN 66001 (1983) neu. Die kann ruhig rein, dann müsste aber der Link auf die alte DIN raus. --Cepheiden 11:10, 6. Jul. 2007 (CEST)
- Aufgrund des Kästchens auf der rechten Seite bin ich als Leser geneigt anzunehmen, dass sich die Seite auch auf die DIN 66001 bezieht. Ich verändere nichts am Dokument, deswegen hab ich ja diese Frage gestellt. Mit dem Sublink geb ich dir Recht. Gruß Niels
- Warum ämderst du nichts? Dafür ist die Wikipedia doch da, getrost dem Motto Sei mutig! --Cepheiden 14:25, 6. Jul. 2007 (CEST)
- Ich habe auf verschiedenen Seiten einmal Diskussionsstränge betreffend Änderungen verfolgt. Jedoch wurde der Umgangston zu unschön und die Diskussion nicht mehr sachlich. Deswegen vermeide ich Änderungen und weise lieber auf etwas hin, da ich mich aus solch einer Art und Weise im Umgang miteinander fern halten möchte. Aber ich habe den Link jetzt ersetzt, bei diesem Artikel scheint es ja netter vorzugehen ;-) Gruß Niels
- Der Link stellt nur leider die DIN-Norm nicht korrekt dar. "Daten" gehören nicht zum PAP und haben auch nichts mit der Ein-/Ausgabe zu tun, sondern stellen vorhandere Daten dar. --Ihoecken 01:14, 21. Sep. 2007 (CEST)
- Archivierung dieses Abschnittes wurde gewünscht von: arilou (Diskussion) 12:16, 25. Sep. 2012 (CEST)
Pfeile
Folgenden Kommentar habe ich aus dem Artikel entfernt: bitte ändern! die pfeile kommen nicht nach jedem baustein! Wann kommen Sie denn jetzt genau? --Thornard, Diskussion, 00:57, 21. Apr 2006 (CEST)
- Sie kommen nur dann, wenn man von der Standardrichtung (von links nach recht, bzw. oben nach unten) abweicht. --Ihoecken 01:12, 21. Sep. 2007 (CEST)
- Sie können immer da sein, man darf auf sie verzichten, wenn man bei einer "Standard-Richtung" bleibt. Es ist kein Fehler, wenn sie immer da sind. --arilou (Diskussion) 08:56, 13. Mär. 2012 (CET)
- Archivierung dieses Abschnittes wurde gewünscht von: arilou (Diskussion) 12:17, 25. Sep. 2012 (CEST)
Beispiel eines Flussdiagramms
Könnte bitte jemand der Aufgabe annehmen, das Beispiel zu erklären. Anonsten ist der PAP-Graph nett anzusachauen, Laien können aber damit nicht soviel anfangen. gruß --Cepheiden 16:11, 15. Mai 2006 (CEST)
Die Beispielerklärung enthält einen kleinen Fehler. Es wird behauptet das dieses Struktogramm die 101 ausgeben würde was jedoch falsch ist. Die Variable "i" wird erst ausgegeben und dann hochgezählt. Nach dem Vergleich (<=100) würde die Bedingung nicht mehr erfüllt sein und 101 somit nicht ausgegeben werden. Gruß Comotio
- Ja stimmt. Habe die Änderungen von 80.139.24.214 (Diskussion • Beiträge • SBL-Log • Sperr-Logbuch • globale Beiträge • Whois • GeoIP • RBLs) rückgängig gemacht -- @xqt 08:47, 19. Dez. 2007 (CET)
- Archivierung dieses Abschnittes wurde gewünscht von: arilou (Diskussion) 12:18, 25. Sep. 2012 (CEST)
Control Flow Graph
Irgendwie fehlt mir mehr Information über Control Flow Graphen (CFG), wie ich sie aus der Analyse von Computerprogrammen kenne (Compiler, Decompiler). Dazu gehören auch graphentheoretische Definitionen (Strukturen) und Algorithmen, die in diesem Zusammenhang von Bedeutung sind.
Da ich noch ganz unerfahren mit der Wikipedia bin, möchte ich selbst (noch) keine solchen Erweiterungen einführen. Gehören denn spezielle Algorithmen überhaupt in die Wikipedia?
Hinzu kommt, daß mir jegliche formale Theorie ein Greuel ist, ich kann daher höchstens angeben, was mir an konkreten Punkten fehlt, weniger was dort stehen könnte. (nicht signierter Beitrag von DoDi (Diskussion | Beiträge) )
- Hi, ja der Steuerungsablaufplan fehlt noch in der Wikipedia, es ist aber schon eine präzisierung des Programmablaufplans, bei der es auch um Optimierungsmöglichkeiten für die Hardware usw. geht. Von daher würde ich einen neuen Artikel (möglichst mit deutschem Lemma) besser finden. gru0 --Cepheiden 14:28, 16. Jul 2006 (CEST)
- Archivierung dieses Abschnittes wurde gewünscht von: arilou (Diskussion) 12:19, 25. Sep. 2012 (CEST)
Unklarheit: Elemente - "Symbole nach 6.1.4"
Im Abschnitt Elemente ist ein Bezug für mich unklar: Im 1. Absatz, 2. Satz steht dort:
Auch die Schleife sollte nicht mit Verzweigungen, sondern mit den Symbolen nach 6.1.4 dargestellt werden.
Die Symbole nach 6.1.4 sind jedoch nirgends im Artikel angegeben. Die Annahme, dass es sich um einen Zahlendreher handelt (6.4.1 statt 6.1.4) ergibt m.E. auch keinnen Sinn, denn mit dem Start/Stop-Symbol 6.4.1 wird wohl keine Schleife dargestellt, oder??
Worauf bezieht sich die überhaupt die Nummerierung der Symbole? Auf die DIN 66001??
Kann mir jemand verraten, was das Schleifensymbol ist? Vielen Dank --ata. --194.97.211.204 19:22, 22. Jul 2006 (CEST)
- Die Antwort findest du z.B. hier: http://schulen.freiepresse.de/gymnasiumolbernhau/informatik/algorithmen.htm#struktogramm
- Archivierung dieses Abschnittes wurde gewünscht von: arilou (Diskussion) 12:19, 25. Sep. 2012 (CEST)
Programm zum Erstellen von Programmablaufplänen
Womit erstellt man diese Dinger? Jonathan Hornung 18:20, 13. Okt 2005 (CEST)
Ich empfehle Open Office Draw. Draw besitzt (fast) alle Symbole, die in DIN 66001 definiert werden. Zu erhalten unter [2]. Wichtig: Draw ist erst ab Version 2.0 Beta enthalten.
Powerpoint eignet sich auch sehr gut um Programmablaufpläne zu erstellen mittels der Autoformen (Ansicht-> Symbolleisten->Zeichnen)--Rbe 16:40, 28. Dez 2005 (CET)
- "empfehlen, eignen..." ja, aber womit sind diese Diagramme gezeichnet? Nivram 21:56, 18. Dez. 2006 (CET)
- Klick drauf und du wirst sehen, dass die Bilder von Benutzer:Daniel stammen. Frag ihn doch mal direkt auf seiner Diskussionsseite. --jpp ?! 11:28, 19. Dez. 2006 (CET)
- Hab ich ja gemacht, nur halt auf seiner Wikimedia-Seite [3]. (Da liegt ja das Bild auch.) Aber jetzt, wo ich weiß, dass er noch eine Diskussionsseite hat... Nivram 22:51, 20. Dez. 2006 (CET)
Das geht mit MS Visio recht gut. Da sind bereits Vorlagen (Shapes) mit dabei. --Darok
- Archivierung dieses Abschnittes wurde gewünscht von: arilou (Diskussion) 12:20, 25. Sep. 2012 (CEST)
hallo
das nützt alles nichts für schüler
- Was würde deiner Meinung nach Schülern nützen und wofür? --Cepheiden 10:59, 4. Jan. 2007 (CET)
- Archivierung dieses Abschnittes wurde gewünscht von: arilou (Diskussion) 12:20, 25. Sep. 2012 (CEST)
Beispiel - falsche Beschreibung?
Entweder verstehe ich da was falsch, oder die Beschreibung stimmt nicht.
>> Die nebenstehende Abbildung zeigt eine einfache Zählschleife von 1 bis 101.
Bedeutet doch, dass folgendes ausgegeben wird:
>> 1, 2, 3, ..., 99, 100, 101
Ich habe die abgebildete Grafik mal in ein kleines C++-Progrämmchen gegossen;
include <iostream>
using namespace std;
int main() {
int i=1;
while(i<=100)
{
cout << i << "\n";
if (i==39)
i=61;
else
i++;
}
return 0;
}
Damit erhalte ich jedoch keine "normale" (kontinuierliche) Zählschleife, sondern folgende Ausgabe:
>> 1, 2, 3, ..., 38, 39, 61, 62, 63, ... 98, 99, 100
Oder muss eine Zählschleife nicht kontinuierlich Zahl für Zahl ausgeben, sondern gilt auch dann noch als Zählschleife, wenn sie Outputs wie das "meinige" liefert? Fragend --213.3.9.26 13:16, 4. Jul. 2007 (CEST)
- Was soll es denn sonst sein? Es findet lediglich Ein Sprung von 39 auf 61 statt. nb - versuchs mal mit der repeat-Schleife, dann wird auch die 101 ausgegeben. -- @xqt 13:51, 4. Jul. 2007 (CEST)
- Ich weiss nicht, was es sonst sein soll, deshalb frag' ich ja :-)
- Aus wikipedia: "Im Allgemeinen wird durch Zählen die Anzahl einer (endlichen) Menge von Objekten festgestellt, indem man, angefangen mit 1, nacheinander jedem Objekt die nächste natürliche Zahl zuordnet, bis keine Objekte mehr übrig bleiben (mittels einer Bijektion)."
- Scheint hier ja eben genau nicht zuzutreffen. Demzufolge handelt es sich bei dem hier vorgestellten Ding wohl um eine Zählschleife mit Sprung und nicht um eine reine Zählschleife. Oder werden Gebilde wie hier dargestellt in der Programmierszene allgemein unter dem Begriff "Zälschleife" zusammengefasst? Ich kenne mich damit nämlich, wie man unschwer erkennen kann, nicht sonderlich aus... naja wahrscheinlich stimmt's schon so wie's dasteht und der "normale" Leser wird wegen solch einem Detail nicht dermassen durcheinander gebracht wie ich... =) --213.3.9.26 15:26, 4. Jul. 2007 (CEST)
- Wo ist das Problem? Du zählst von 1 bis 39, dann von 61 bis 101. Ich darf auch zwei Hände zum zählen benutzen. -- @xqt 17:27, 4. Jul. 2007 (CEST)
- Das Problem liegt zwischen der 39 und der 61. Denn 61 ist nicht die nächste Zahl nach 39 und somit handelt es sich dabei laut obiger Definition von Zählen nicht wirklich um Zählen, sondern um... naja, irgendwas anderes eben. Und weil das hier vorgestellte Programm eben genau das tut, von 39 direkt auf 61 zu springen, bin ich wegen dem Begriff "Zählschleife" (gedanklich) auf die Fresse gefallen. Ein Detail, man kann aus Mücken Elefanten machen und umgekehrt. Da ich scheinbar als einziger (gedanklich) darübergestolpert bin und sich andere (scheinbar) solche Gedanken über Details gar nicht erst machen, kann die Sache ruhig wieder vergessen werden. :-) Grüsse --213.3.9.26 17:55, 4. Jul. 2007 (CEST)
- Wichtiger fände ich, dass als Abbruchbedingung mal >= benutzt wird, denn wenn nach dem ersten durchlaufen i=2 ist, wird schon abgebrochen.....und dann muss dazu auch noch die Beschreibung geändert werden. Denn die Ausgabe ist momentan nur "1", danach wird schon abgebrochen. Lukas (lsut aufm gmx.de) (nicht signierter Beitrag von 92.196.92.60 (Diskussion | Beiträge) 15:33, 30. Okt. 2009 (CET))
- Hä? Quatsch. Dat is kein Abbruchbedingung, min Jung', sondern eine while... --arilou (Diskussion) 10:16, 7. Mär. 2012 (CET)
- Wichtiger fände ich, dass als Abbruchbedingung mal >= benutzt wird, denn wenn nach dem ersten durchlaufen i=2 ist, wird schon abgebrochen.....und dann muss dazu auch noch die Beschreibung geändert werden. Denn die Ausgabe ist momentan nur "1", danach wird schon abgebrochen. Lukas (lsut aufm gmx.de) (nicht signierter Beitrag von 92.196.92.60 (Diskussion | Beiträge) 15:33, 30. Okt. 2009 (CET))
- Das Problem liegt zwischen der 39 und der 61. Denn 61 ist nicht die nächste Zahl nach 39 und somit handelt es sich dabei laut obiger Definition von Zählen nicht wirklich um Zählen, sondern um... naja, irgendwas anderes eben. Und weil das hier vorgestellte Programm eben genau das tut, von 39 direkt auf 61 zu springen, bin ich wegen dem Begriff "Zählschleife" (gedanklich) auf die Fresse gefallen. Ein Detail, man kann aus Mücken Elefanten machen und umgekehrt. Da ich scheinbar als einziger (gedanklich) darübergestolpert bin und sich andere (scheinbar) solche Gedanken über Details gar nicht erst machen, kann die Sache ruhig wieder vergessen werden. :-) Grüsse --213.3.9.26 17:55, 4. Jul. 2007 (CEST)
- Wo ist das Problem? Du zählst von 1 bis 39, dann von 61 bis 101. Ich darf auch zwei Hände zum zählen benutzen. -- @xqt 17:27, 4. Jul. 2007 (CEST)
- Archivierung dieses Abschnittes wurde gewünscht von: arilou (Diskussion) 12:21, 25. Sep. 2012 (CEST)
Schleife falsch dargestellt
Soweit ich die DIN-Norm verstehe werden Schleifen mit den Schleifenbegrenzern dargestellt (s.o.). Die Darstellung mit MOIN Fetter Text Schleifen (z.B. FOR-Schleifen). Das Beispiel bricht aber hier bewußt aus, so daß die ispiel entspricht also nicht der DIN-Norm und ist darüber hinaus noch ein schlechter Programmierstil! --Ihoecken 01:08, 21. Sep. 2007 (CEST)
- Archivierung dieses Abschnittes wurde gewünscht von: arilou (Diskussion) 12:21, 25. Sep. 2012 (CEST)
Allgemeines
Gilten die Dinger wirklich "nur" für Computerprogramme? Ich habe solche Ablaufpläne schon in Wartungsplänen gesehen, die die Vorgehensweise bei Fehler bzw. die Fehlerbehebung erklärten. Kann mich aber auch verguckt haben. Mit freundlichem Gruß Dominik -- dom 15:34, 17. Apr 2005 (CEST)
- Man kann damit im Prinzip jede Art von Ablauf beschreiben. Das mit den Wartungsplänen wird schon stimmen. Schritte zur Fehlersuche an Geräten kann man so auch notieren. --subsonic68 06:29, 25. Apr 2005 (CEST)
- Ich denke der Begriff Programmablaufplan ist hier nicht gut gewählt. In Zusammenhang mit den Sieben Werkzeugen der Qualität wäre sicherlich besser den Begriff Prüfablaufplan zu wählen, anstatt Programmablaufplan. Im allgemeinen versteht man darunter tatsächlich den Ablauf eines Programms und nicht die Abfolge von Prüfschritten in einer Fertigung!
- Mit freundlichen Grüßen Frank Paliege.
- (nur damit der Link anwesend ist:) Siehe Sieben Werkzeuge der Qualität
- Prüfen ist ein Ablauf von Tätigkeiten/Handgriffen und Vergleichen. Auch das ist ein Programm. Ergo: "Prüfen" ist eine Untermenge von "Programm" (im Sinne eines Ablaufplans). Daher sehe ich keinen Grund, hießigen Artikel umzubenennen.
- Vorschlag: Im Artikel Sieben Werkzeuge der Qualität kann als 5. Punkt ja statt
- Programmablaufplan (PAP, engl. flowchart)
- stehen:
- Prüfablaufplan in Form eines Programmablaufplans (PAP, engl. flowchart)
- Da wäre imo nichts dagegen einzuwenden. Also, meinerseits: WP:Sei mutig!
- --arilou (Diskussion) 12:13, 25. Sep. 2012 (CEST)
- Archivierung dieses Abschnittes wurde gewünscht von: arilou (Diskussion) 16:58, 18. Sep. 2020 (CEST)
Nur für imperative Programmierung geeignet
Man sollte anmerken dass diese Diagramme nur für imperative Sprachen sinn ergeben. Programme für funktionale Sprachen lassen sich nur sehr schwer daraus übersetzen. Kleines Beispiel: Das Beispiel eines Flussdiagramms sieht - in Haskell implementiert - so aus:
(putStr . foldr (\x y -> (show x)++y) []) ([1..39]++[61..100])
oder
putStr (foldr showConcat [] ([1..39]++[61..100])) where showConcat x y = (show x)++y
Wie man sieht, würde da ein Diagramm der folgenden Art mehr Sinn ergeben:
wobei (| wäre rückgabe)
Aber da kann man sich ja eigentlich gleich das Haskell anschauen.
(Oder man macht es halt mit einer richtigen Diagramm-Software statt mit TeX-Math. ;)
-- 212.100.48.54 07:13, 18. Jan 2006 (CET)
- Archivierung dieses Abschnittes wurde gewünscht von: arilou (Diskussion) 16:58, 18. Sep. 2020 (CEST)
Abgrenzung Datenflussplan/Programmablaufplan
Der Artikel ist ein bisschen mager, wenn es um Datenflüsse geht, da könnten noch ein paar Symbole kurz erläutert werden (insbesondere Schriftstück/Plattenspeicher/manuelle Eingabe etc.).
- Im PAP werden keine Datenflüsse verzeichnet, sondern nur Kontrollflüsse. Daten siehe Artikel Datenflussdiagramm. --arilou (Diskussion) 10:13, 7. Mär. 2012 (CET)
- Anonymus meint vermutlich die Spezialsymbole statt Parallelogramm für Tastatur, Bildschirm, „Plattenspeicher“. Während Parallelogramm für eine allgemeine E/A steht, meine diese eine näher spezifizierte E/A. Ist zwar seit Jahrzehnten nicht mehr im Gebrauch, sollte aber im Interesse der historischen Wahrheit ggf. erwähnt werden; wäre dann auch nicht Datenflussdiagramm, sondern PAP („schreibe auf Plattenspeicher“). Ich gucke nach Details. --PerfektesChaos (D) 13:13, 7. Mär. 2012 (CET)
- Archivierung dieses Abschnittes wurde gewünscht von: arilou (Diskussion) 16:58, 18. Sep. 2020 (CEST)
Din 66 001 ist hier falsch wiedergegeben
Manuelle Verarbeitung einschließlich Ein-Ausgabe ist ein Trapez, das auf der kleineneren Seite steht und kein Parallelogramm (Din 66001 6.1.2)
Das Parallelogramm stellt allgemeine Daten dar (nicht Ein-Ausgabe) und diese kommen bei einem PAP nicht vor sondern nur bei Datenflußplan, Programmnetz, Datennetz und Datenhierarchie (Din 66001 6.2.1)
Schleifen werden nicht mit der Raute sondern mit Schleifenkopf und Schleifenfuss, die als Rechteck, mit abgeschrägten Ecken oben (Kopf) bzw. unten (Fuß) dargestellt werden (Din 66001 6.1.4). Bei Kopfschleifen bleibt der Fuß frei, bei Fußschleifen der Kopf. Kopfschleifen sind dabei standardmäßig "Solange" und Fußschleife "Bis"-Schleifen.
Aus einer Zählschleife darf man außerdem laut Dinnorm nicht herausspringen, anstatt zum Kopf muss zum Fuß gesprungen werden!
Verbindungen werden standardmäßig nicht mit Pfeil dargestellt sondern nur dann, wenn von der Standardablaufrichtung (von links nach rechts, bzw. von oben nach unten) abgewichen wird (Anmerkung zu Din 6.3.1) --Ihoecken 00:17, 21. Sep. 2007 (CEST)
- Ähm, das steht jetzt hier seit über 4 Jahren ohne Auswirkung auf den Artikel? Oder eine Antwort? Hat jemand einen Link auf eine aktuelle DIN 66001, ob Benutzer:Ihoecken 's Einwand berechtigt ist?
- Soweit ich das in kurzer Recherche mitgekriegt hab', ist seine Kritik teilweise berechtigt, teilweise wohl nicht... --arilou (Diskussion) 11:40, 7. Mär. 2012 (CET)
- Ich habe mindestens eine Ausgabe von September 1977, allerdings leider nicht gescannt und auch tief verbuddelt. 1983 könnte ich auch haben, wüsste aber nicht wo ich danach suchen soll.
- Ich kann mich nur erinnern, dass die Veränderungen 1977→1983 minimal gewesen waren. Warum E/A herausgefallen sein soll, wäre von historischem Interesse.
- Zu den Kritikpunkten im Einzelnen:
- „Schleifen werden nicht mit der Raute“ – das ist eine zulässige Vereinfachung, aber keine zwingende Notwendigkeit und kein Verbot der allgemeinen Konstruktion mit dem auf der Spitze stehenden Quadrat.
- „Aus einer Zählschleife darf“ – das trifft zu, wenn man die vereinfachte und standardisierte Schleife wie vor verwendet. Sie lehnte sich an die DO in FORTRAN an. In einem allgemeinen Algorithmus darf man das beliebig handhaben.
- „standardmäßig nicht mit Pfeil dargestellt“ – das war eine zulässige Vereinfachung; zur fraglichen Zeit wurden die Pläne mit weichem Bleistift auf kariertem Papier gezeichnet. Um sich manuelle Arbeit zu ersparen, darf man die Pfeile weglassen, wie angegeben. Man darf sie aber trotzdem zeichnen. Richtig ist, dass die Standard-Leserichtungen zu bevorzugen waren.
- „Parallelogramm stellt allgemeine Daten dar (nicht Ein-Ausgabe) und diese kommen bei einem PAP nicht vor“ – das ist bedingt falsch. Richtig ist, dass hier nicht auf Details des Datenflusses ankommt, welche Information genau auf welchem Weg wohin gelangt. Aber für das aktuelle Programm ist wichtig, dass ein E/A-Vorgang in diesem Moment stattfindet, und man dürfte auch sagen ob über Tastatur, Bildschirm, Drucker (wir sind um 1980) und auch global beschreiben, welche Inhalte in etwa. Da hatte es scheinbar 1983 eine Änderung gegeben. Nicht beschreiben kann und darf man in einem PAP, wohin und in welchem Format die Daten fließen sollen und was mit ihnen geschehen möge.
- „Manuelle Verarbeitung einschließlich Ein-Ausgabe ist ein Trapez“ – das mag die Änderung gewesen sein, die 1983 stattfand. Wir erwähnen das Trapez (das zumindest 1977 der „Manuelle Eingriff“ war) nicht, wie auch einige andere Symbole. Es könnte sein, dass dies 1983 zu einem Trapez-Symbol zusammengelegt worden war; ich werde mich bei Gelegenheit darum kümmern.
- Zusammengefasst muss man feststellen, dass abgesehen von der geschichtlichen Wahrheit (der die WP natürlich verpflichtet ist) die präzise Gestaltung eines PAP im 21. Jahrhundert nicht mehr die Bedeutung hat, die für Programmierer um 1985 zentral gewesen war. Ob Trapez oder Parallelogramm macht einen PAP von 1979 nicht falsch, und als schematische Darstellung für Laien oder Unterrichtszwecke oder für nicht in Software umgesetzte Arbeitsabläufe ist es herzlich egal.
- VG --PerfektesChaos (D) 13:47, 7. Mär. 2012 (CET)
- DIN 66001
- Ich habe im Moment nur meine alten ASCII-Dateien, nach denen ich rekonstruieren kann, dass ich die Version 1977 in einem bestimmten Ordner habe, weil das Inhaltsverzeichnis in ASCII ist. Der Ordner liegt einige Dutzend Kilometer entfernt; in einigen Wochen werde ich bei schönem Wetter dort vorbeiradeln und das Normblatt holen.
- Ich werde gelegentlich Lesezugriff auf die Versionen 1985 und die ISO 5807 haben und auf Änderungen abgleichen.
- Wie haben ein Weblink auf die DIN-Version 1966; auf den ersten Blick scheint es mir hinsichtlich der Symbole keine gravierenden Unterschiede zu den späteren Ausgaben zu geben; zumindest soweit der momentane Artikel betroffen ist. Das 1966 auf Seite 6 angekündigte Zeichen für Parallelverarbeitung war 1977 Bestandteil geworden (in vier Varianten). Erläuterungstext und Beispiele mögen sich leicht geändert haben.
- Die als Weblink verfügbare Ausgabe 1966 nennt unter 4.3: „kann auf das nächstfolgende Sinnbild eine Pfeilspitze gerichtet sein, insbesondere bei Abweichungen von den Vorzugsrichtungen“. Man darf die Pfeilspitzen weglassen; man muss es aber nicht. Da sie von Hand gezeichnet wurden, war man im internen Gebrauch für die Erleichterung dankbar; für anschauliche Präsentationen gegenüber Laien hat man eher alle Pfeilspitzen eingemalt. Dabei blieb es wohl auch in den späteren Ausgaben.
- Nebenbei gibt es auch eine ungenormte Vorzugsrichtung für Ja/Nein-Verzweigungen in entsprechenden Kulturkreisen: „Ja“ geht nach unten, „Nein“ nach links oder rechts – Kopfnicken und Kopfschütteln. So auch umseitig im Artikel dargestellt; en:Flowchart.
- Irgendwo gab es Differenzen, ob die Verzweigung ein auf der Spitze stehendes Quadrat sein müsse oder als Raute plattgedrückt werden dürfe; in die Raute passte der Text besser hinein und sie nahm nicht so viel vertikalen Platz weg.
- DIN 66001
- GOTO :dinner --PerfektesChaos 19:10, 12. Mär. 2012 (CET)
Herzlichen Dank PerfektesChaos, dass sich hier jetzt (nach 4 Jahren) einiges tut ;-) --arilou (Diskussion) 09:05, 13. Mär. 2012 (CET)
- Ich habe jetzt die Ausgabe September 1977 vor der Nase. Die offenen Kritikpunkte sind insoweit haltlos:
- Das Parallelogramm mit gerader Seite nach unten stellt allgemein eine Ein-Ausgabe-Anweisung dar (Position 4.2; ob es sich um Ein- oder Ausgabe handelt und ob um maschinelle oder manuelle Operation, „soll aus der Beschriftung des Sinnbildes hervorgehen“).
- Symmetrisches Trapez, das auf der kürzeren Seite steht: Manuelle Verarbeitung irgendwelcher Art (Position 4.1.4; Führen handschriftlicher Listen, Wechseln von Speichermedien, Formularwechsel, Bedienereingriff)
- Mit der Ein- und Ausgabe (Parallelogramm) von Dateninhalten hat das nichts zu tun.
- Die allgemeinen Schleifen werden sehr wohl mit dem auf der Spitze stehenden Parallelogramm („Raute“) dargestellt. Damit lassen sich beliebige Abläufe bilden.
- Die beschriebenen Schleifenbegrenzungen mit abgeschrägten Ecken gehören zu fest gefügten und näher spezifizierten Standardstrukturen, etwa die genannten „Zählschleifen“. Ein weiterer Sonderfall sind die angemeierten „Kopfschleifen“, das meint DO WHILE und DO UNTIL (Fußschleife) und ist so in die Begrenzer einzutragen. Frei (wie behauptet) bleiben die Sinnbilder dabei allerdings nicht, sondern sind durch gleiche Bezeichner („Label“) einander eindeutig zuzuordnen.
- Die weiter unten genannten switch lassen sich übrigens auch damit bilden, indem senkrecht nach unten der Vielfach-Zweig herabgeführt und dann in Leserichtung nach rechts beliebig oft aufgefächert wird.
- Im Übrigen lässt sich für die Zwecke des Artikels das Weblink von 1966 ganz gut anwenden.
- Die Version 1983 habe ich nicht in Reichweite; ich bin mir jedoch recht sicher, dass sie die Gebräuche der zwanzig Jahre zuvor nicht fundamental umgeworfen hatte, zumindest nicht so als ungültig erklärt hat.
- Grüße --PerfektesChaos 14:23, 20. Sep. 2012 (CEST)
- Archivierung dieses Abschnittes wurde gewünscht von: arilou (Diskussion) 16:58, 18. Sep. 2020 (CEST)
Programmablaufpläne für Unterprogramme
Die Seite an sich hat mir sehr geholfen allerdings fehlt mir was in der Auflistung, nämlich die Unterprogramme. Wie fangen sie an und wie hören sie auf? Wenn mir das jemand sagen könnte mach ich mich, wenn ich schon gerade dabei sind, an die Arbeit und erstelle ein Modell und füge es in den Artikel ein. --MfG E.Wallace 18:50, 30. Jun. 2008 (CEST)
- hier -- @xqt 06:46, 1. Jul. 2008 (CEST)
- werd mich an ein geeignetes Modell fürs Wiki setzen. --MfG E.Wallace 13:15, 1. Jul. 2008 (CEST)
Da kommen mehr Fragen als Antworten bei Programmablaufplänen auf mich zu. Naja dieser Artikel hier ist durchaus verbesserungswürdig. Da ich es selbst allerdings auch nicht weiß kann ich es schlecht machen. Was passiert z.B. wenn man im Nebenprogramm eine Sprungmarke verwendet, die ansonsten nur im Hauptprogramm vorkommt? (z.B. in einer Prüfung). Wenn etwas geprüft wird verwenmdet man die Raute und lässt es dann so weiterlaufen wie man es gerade braucht, je nach dem ob die Bedingung erfüllt ist oder eben nicht. In meinem konkreten Beispiel soll es bei Nichterfüllung der Bedingung zurückgesetzt werden. Dafür sollte man eigentlich die Sprungmarke irgendwie ins Unterprogramm-PAP einbringen, doch wie? --MfG E.Wallace 13:20, 4. Jul. 2008 (CEST)
- Mal abgesehen davon, dass es in halbwegs moderner Programmierung keine Sprungmarken mehr geben sollte, und ein Unterprogramm niemals ins Hauptprogramm verzweigen sollte, kann ich im Artikel auch nichts über Sprungmarken finden? --arilou (Diskussion) 11:45, 7. Mär. 2012 (CET)
- Die Sprungmarke ist ein Kreis.
- Die als Weblink verfügbare Ausgabe 1966 nennt es unter 4.3.2 "Übergangsstelle".
- Die damaligen Programmierer arbeiteten mit Stapeln von einigen Hundert Lochkarten; unkommentiert und womöglich noch nicht einmal mit dem Text bedruckt. Die DIN 66001 passt zu den seinerzeitigen Programmiersprachen. Insbesondere war man dicht am Assembler.
- Wenn tatsächlich ein Unterprogramm als solches abgegrenzt ist, gibt es auch keine Sprünge aus einem Unterprogramm in das aufrufende Programm.
- Der mit dem doppelten Strich links und rechts ausgewiesene Kasten ist allerdings nicht notwendigerweise ein programmtechnisches Unterprogramm; es kann sich auch um eine Gruppe von Anweisungen handeln, für die es auf einem gesonderten Blatt einen eigenen PAP gibt.
- Insbesondere die in den 1960ern und 19970ern verwendeten Programmiersprachen (wie etwa Fortran) kannten Unterprogramme mit mehreren Einstiegspunkten. Mehrfaches Return ist auch in modernen Sprachen möglich, entspricht allerdings nicht der reinen Lehre.
- Diese Technologien zielen auf GOTO und eine besondere Freude namens en:Goto #Computed GOTO und en:Goto #Assigned GOTO ab. Diese beiden sind der Hintergrund für die sechseckige "Programmodifikation" unter 4.1.3.
- Die als Weblink verfügbare Ausgabe 1966 nennt es unter 4.3.2 "Übergangsstelle".
- GOTO :dinner --PerfektesChaos 19:10, 12. Mär. 2012 (CET)
- Die Sprungmarke ist ein Kreis.
- Archivierung dieses Abschnittes wurde gewünscht von: arilou (Diskussion) 16:58, 18. Sep. 2020 (CEST)
Revert vom 12.März.2012
Wenn im Artikel einzelne Programme aufgeführt werden sollen, dann nur
- wenn's tatsächlich nur so wenige gibt, dass man problemlos an einer Hand alle abzählen kann
- oder nur welche, die von besonderer Bedeutung sind (Referenz-Implementierung o.ä.), also eine besondere (und nenn- und erklärbare) enzyklopädische Relevanz besitzen.
Ansonsten verkommt so 'ne Liste ganz schnell zur "ich-will-hier-auch-genannt-werden" Liste, knapp an der Werbung. --arilou (Diskussion) 15:38, 12. Mär. 2012 (CET)
- Archivierung dieses Abschnittes wurde gewünscht von: arilou (Diskussion) 16:58, 18. Sep. 2020 (CEST)
Beispiele für verschiedene Konstrukte
Hallo, es wäre evt. auch noch sinnvoll Beispiele für verschiedene Kontrukte zu ergänzen, also Schleifen, Bedingungen, Try-Catch, Case, Sprungmarken, Funktionsaufrufe, ... (nicht signierter Beitrag von 217.6.221.183 (Diskussion) 10:31, 3. Sep. 2012 (CEST))
- Im gegebenen Beispiel ist eine (sogar komplexere) Schleife drin sowie Bedingungen.
- Case/Select/Switch gibt's nicht, ebensowenig ein spezielles Try-Catch Konstrukt.
- Sprungmarken programmiert man sowieso nicht.
- Funktionsaufrufe sind simpel.
- Insgesamt seh' ich keine Notwendigkeit, den Artikel mit weiteren Beispielen zuzukleistern; außerdem sind PAPe sowieso veraltet; ob inzwischen auch Struktogramme als veraltet gelten - möglich. --arilou (Diskussion) 12:44, 3. Sep. 2012 (CEST)
- Danke für die Anregung; aber ich fürchte, hier gibt es ein kulturelles Missverständnis. Den vorstehenden Bemerkungen von Arilou stimme ich zu und führe sie gern noch etwas aus; auch für künftige Anfragen:
- Der DIN-Programmablaufplan gehört in die 1960er und 1970er Jahre.
- Damals wurde auf Lochkarten programmiert. Sie trugen oft nur die Löcher und mussten ggf. mühsam zusätzlich mit dem Text bedruckt werden. Es gab nur wenige Kommentarkarten; um so unhandlicher wurde der Stapel aus oft nur wenigen 100 Karten. Es gab weder Einrückungen noch Leerzeichen um Operatoren (sonst hätte man eine neue Karte gebraucht). Es gab nur Großbuchstaben (weil spätestens die Zeilendrucker nichts anderes konnten); Namen von Variablen und Funktionen durften nur sechs Zeichen lang sein (so noch Fortran77).
- Der Ausdruck des Quellcodes auf Papier (Terminals hatte es eher wenig, kaum mit 25×80 Zeichen) war eine unübersichtliche Wüste.
- Der DIN-Programmablaufplan war deshalb eine wichtige Möglichkeit, die Funktionalität übersichtlicher darzustellen. Er diente auch der Kommunikation zwischen Programmierern, die mit weichem Bleistift auf kariertem Papier arbeiteten, und den Ablocherinnen (Datatypisten).
- Er beschränkt sich auf die damals vorhandenen Sprachelemente.
- Try-Catch, Case – das gehört in modernere, etwa objektorientierte Programmierung.
- Hierfür wäre unbedingt UML zu verwenden.
- Den DIN-Programmablaufplan sollte man hier außen vor lassen.
- Einige von dir angeregten Sprachelemente von seinerzeitiger Bedeutung sind im Artikel aufgeführt:
- Schleifen – ist als Beispielbild gezeigt; die spezifische „Zählschleife“ allerdings nicht.
- Bedingungen – das ist die „Raute“.
- Case – da könnte man von der Raute mehr als zwei, drei Zweige ausgehen lassen, ggf. in ungenormten Design. Das gab es damals schlicht nicht, allerdings ein vielfaches GOTO.
- Sprungmarke – das ist ein Kreis, allerdings etwas kleiner gezeichnet als Start, Stopp, „weitere Grenzpunkte“
- Funktionsaufruf – das ist als Rechteck möglich; mit Funktionsname, Parametern usw. als Text. Die Funktion selbst ist auch das Oval mit spezifischem Start/Stopp; in gesondertem Ablaufplan. Allzu viel mit Modularisierung hatte man damals noch nicht.
- Try-Catch magst du dir gern für dich persönlich aufmalen.
- War der DIN-Programmablaufplan zur damaligen Zeit dringend benötigtes Arbeitsmittel, auf dessen Formatierung streng geachtet wurde, mag man ihn heute auch in freierer Gestaltung für alle möglichen Abläufe einsetzen; von Postbearbeitung bis Müllverbrennung.
- Der DIN-Programmablaufplan gehört in die 1960er und 1970er Jahre.
- Mir fällt auf, dass ich versprochen hatte, noch eine der letzten Papierversionen herauszusuchen. Total verschlumpft.
- Danke für die Anregung; aber ich fürchte, hier gibt es ein kulturelles Missverständnis. Den vorstehenden Bemerkungen von Arilou stimme ich zu und führe sie gern noch etwas aus; auch für künftige Anfragen:
- Liebe Grüße --PerfektesChaos 14:47, 3. Sep. 2012 (CEST)
- Archivierung dieses Abschnittes wurde gewünscht von: arilou (Diskussion) 16:58, 18. Sep. 2020 (CEST)
Bekannte Software fehlt
Leider wieden diese 2 Vertreter im Artikel ohne Begründung gelöscht!--77.25.225.165 13:55, 3. Mai 2013 (CEST)
- Und vollauf zu Recht. Was "bekannte" Vertreter sind, oder "wichtige" Diagramm-Software, ist POV. Wikipedia ist keine Linksammlung und keine Werbeplattform. Möglich wäre ein extra Listenartikel "Liste von Diagrammzeichenprogrammen".
- Alternativ: Wenn dir eine neutrale, belegbare Einordnung/Begründung möglich ist, warum bestimmte Software aufgeführt gehört, dann ja. (So was wie "Erstmals wurde Algorithmus xyz in Software abc implementiert.", oder "65% der Linux-Programmierer verwenden GNU-C++.<ref>Beleg dazu<ref>"
- --arilou (Diskussion) 19:28, 4. Mai 2013 (CEST)
- So lieber arilou,
- 1. Menne uns die WP-Regel, die eine Auflistung von relevanter Software in einen derartigen Artikel verbietet!!!
- Du solltest doch selbst wissen, das jeder seine Software verwendet, wenn er diese kennt und hat,
- deshalb sind Marktfüher für eine Kategorie an Software immer wieder anzutreffen.
- Jedoch bezweifle ich, das ein derartiges Vorgehen dann Werbung ist, da in der Regel
- die Alternativen im Artikel des Markführes im entsprechenden Artikel gelestet werden!
- Du machst gerade selbst WP:POV!!! Wenn Du selbst freie Software hier löscht!!!
- 2. Du kast gern den Listenartikel Liste von Diagrammzeichenprogrammen anlegen!!!
- Du hast das aber nicht getan, warum hat Du hier nur gelöscht? Wann wirst Du das selbst tun?
- Du kanst gern hier begründen warum:
- Dia
- Viso
- Code Visual to Flowchart
- keine relevanten Vertreter diese Software-Gattung sind!
- Du kannst hier echt was selbst zur Qualität der WP leisten, in dem Du
- (So was wie ::"Erstmals wurde Algorithmus xyz in Software abc implementiert.", ::oder "65% der Linux-Programmierer verwenden GNU-C++.<ref>Beleg dazu<ref>" !!!
- hier selbst einbringst als nur zu fordern, selbst keine produktive Arbeit hier einbrigen ::und sich wie ein Troll hier auzuführen!!!
Natürlich gehört relevabnte Software im Artikel genannt. Und dabei spielt es überhaupt keine Rolle, welcher Lizenz sie unterliegen. Das hat rein garnichts mit Werbung zu tun. --M@rcela ¿•Kãʄʄchen•? 20:22, 5. Mai 2013 (CEST)
- Da stimme ich M@rcela voll zu. Meine einzige Forderung: "relevant" muss a) definiert sein ("warum ist Software xyz 'relevant'?") und b) belegt sein. Es muss im Artikel stehen, warum genau die genannten Softwarepakete hier relevant sind (und implizit natürlich, warum andere also nicht genannt sind).
- Zu den "Argumenten" des IP-Users:
- WP-Richtlinien, was genannt werden soll: Man lese aufmerksam und genau Wikipedia ist keine Linksammlung und keine Werbeplattform ~ selbigen Link habe ich ja bereits angegeben.
- Selbstverständlich ist das Aufführen von Software ok, die "marktführend" ist. Dann muss in den Artikel:
* Produkt xyz (von Hersteller abc) ist marktführend, es wird von n % der Verwender benutzt<ref>Marktanalyse der Zeitschrift qwertz<ref>
- Also bitteschön a) Nennung des Relevanzkriteriums "marktführend" und b) ein Beleg dazu.
- Das Fordern einer Begründung für die Relevanz (z.B. "marktführend") sowie eines zugehörigen Belegs ist kein POV, lieber IP-User.
- "Wenn Du selbst freie Software hier löscht!!! ~ Freie Software zu sein ist kein Freibrief für einen WP-Eintrag.
- "Du kast gern den Listenartikel Liste von Diagrammzeichenprogrammen anlegen" - soweit ich das sehe, bis doch du derjenige, der bestimmte Informationen in die WP aufgenommen haben will? Warum muss das jetzt plötzlich meine Aufgabe sein? "begründen warum [...] keine relevanten Vertreter [seien]" ~ Relevanznachweis und Belegpflicht liegen auf Seiten dessen, der die entsprechende Information im Artikel haben will, also auf deiner Seite.
- "[etwas zur] Qualität der WP leisten" ~ rate mal, was ich gerade mache...
- --arilou (Diskussion) 09:52, 6. Mai 2013 (CEST)
- Es gibt Hunderte und Tausende von Programmen, die das mindestens mit englischsprachiger Oberfläche anbieten. Da kann es auch keinen Marktführer geben, weil die dicksten Fische grad ein oder zwei Prozent Marktanteil hätten.
- Pragmatisch kann man nur so vorgehen, dass Software aufgezählt wird, deren Basis-Produkt einen deWP-Artikel hat, also schon mal relevant ist.
- Microsoft Visio – wie bisher
- Corel – kann es mit mehreren Produkten (Corel Designer)
- Igrafx FlowCharter
- ? gimp – kann das auch mit irgendeiner Komponente; Details herausfinden, dann spezifiziert eintragen
- ? AutoCAD – kann das meines Wissens auch; mit näheren Angaben hier eintragen
- CADAM – kann das auch
- Einen Ehren-Eintrag sollte das Produkt bekommen, mit dem die vorhandenen dekorativen Bildchen gezeichnet wurden, wenn der globale user:daniel (en-sysop) sich noch dran erinnern kann. Ich glaube, vor Jahren hatten wir das mal unter Weblinks, aber ich finde es nicht mehr, oder es war http://www.gso-koeln.de/papdesigner/ von denen hier.
- Zu den vielen, vielen anderen netten und sinnvollen Produkten gehören (auch shareware-Verzeichnisse abfragbar):
- yED
- Code Visual to Flowchart
- … … … ausufer
VG --PerfektesChaos 11:02, 6. Mai 2013 (CEST)
- Lieber Benutzer:PerfektesChaos: Nein. Das ganze steht und fällt mit deiner Aussage:
- "Pragmatisch kann man nur so vorgehen, dass Software aufgezählt wird, deren Basis-Produkt einen deWP-Artikel hat, also schon mal relevant ist." - da bin ich strikt dagegen. Die Relevanz muss für hießigen Artikel begründet sein.
- Viele malen ihre Flussdiagramme mit Word, Powerpoint, OOo Writer, MS Paint. Viel Spaß beim Aufzählen aller Software, mit der man PAPe malen kann, selbst wenn du dich auf die beschränkst, die einen WP-Artikel haben.
- Außerdem muss man dann auch Bleistift, Papier, Kugelschreiber, Buntstift und Karton aufführen - mit ihnen werden sehr viele PAPe erstellt, und alle haben WP-Artikel. Sie müssen dann auch aufgeführt und verlinkt werden bei jedem Artikel, der etwas beschreibt, dass man auf Papier darstellen kann (Diagramme, Textformen, Skizzen, Bilder, Musik etc.pp.).
- Mein Vorschlag (ne, sogar eine Forderung): Solange niemand eine vernünftige Definition von "relevant für diesen Artikel" liefert, und für die gewünschte Vermerkung einer bestimmten Software belegt, soll gar keine Software hier aufgeführt werden.
- Ich seh' ehrlich auch keinen enzyklopädischen Mehrwert in so einer Liste.
- Und wenn sich kein "Marktführer" finden lässt, dann wird hier eben auch keiner genannt.
- --arilou (Diskussion) 12:03, 6. Mai 2013 (CEST)
WP:Dritte Meinung: Statt einer Aufzählung wären ein Absatz Erstellung von Programmablaufplänen sinnvoll: Grundsätzlich können Programmablaufpläne mit jedem Grafikprogramm gezeichnet werden. Spezielle Module und unterstützende Funktionen bieten beispielsweise ... . Daneben gibt es Programme, die Ablaufpläne aus Quellcode generieren können ... oder ... . etc. --Siehe-auch-Löscher (Diskussion) 13:33, 6. Mai 2013 (CEST)
- Halte ich durchaus für sinnvoll.
- Allerdings bleibt auch dabei die Frage "Warum gerade xyz und abc als Beispiele, warum nicht auch efg und hij?"
- Was wiederum darauf hinausläuft, a) zu definieren, warum gerade diese Beispiele sinnvoll sind (z.B. "weitverbreitet"), und b) zu belegen, dass diese Beispiele selbige Kriterien auch tatsächlich erfüllen (jeder kann behaupten, Programm xyz sei weitverbreitet...).
- So einen Abschnitt finde ich sinnvoll, er löst aber das Problem nicht wirklich.
- --arilou (Diskussion) 14:50, 6. Mai 2013 (CEST)
- PS: Ich bin mal so frei und behaupte, dass 10* mehr PAPs in MS Word oder Powerpoint gezeichnet werden als in MS Visio. Ist genauso eine Behauptung wie "Visio ist zum PAP-Zeichnen weitverbreitet", und würde zweitere als 'falsch' aufzeigen. Belegen, Leute!
- Relevant (im Sinne einer Nennung im Artikel) sind alle, die hier einen Artikel haben. Wobei AutoCAD sicher geeigent aber wenig typisch ist. Ich habe damit schon Serienbriefe geschrieben, trotzdem ist es keine Textverarbeitung. MS Project wäre da viel eher ein Kandidat. --M@rcela ¿•Kãʄʄchen•? 15:01, 6. Mai 2013 (CEST)
- Das ist falsch. Die Relevanz für diesen Artikel ist noch lange nicht gegeben einfach dadurch, dass eine Software überhaupt einen WP-Artikel besitzt. --arilou (Diskussion) 11:34, 7. Mai 2013 (CEST)
- Relevant (im Sinne einer Nennung im Artikel) sind alle, die hier einen Artikel haben. Wobei AutoCAD sicher geeigent aber wenig typisch ist. Ich habe damit schon Serienbriefe geschrieben, trotzdem ist es keine Textverarbeitung. MS Project wäre da viel eher ein Kandidat. --M@rcela ¿•Kãʄʄchen•? 15:01, 6. Mai 2013 (CEST)
- Das Problem wird durch einen Text auf jeden Fall qualifizierter. Wenn da steht Grundsätzlich können Programmablaufpläne mit jedem Grafikprogramm gezeichnet werden. weiß der Leser immerhin, weshalb PowerPoint nicht gesondert erwähnt wird, obwohl seine komplette Abteilung damit arbeitet. --Siehe-auch-Löscher (Diskussion) 15:19, 6. Mai 2013 (CEST)
Ich bin oben wahrscheinlich etwas missverständlich gewesen. Klar ist, dass es Unmengen von Programmen gibt, deren Aufzählung den inhaltlichen Teil des Artikels übersteigen und sprengen würde.
- Die klassischen CAD-Zeichnungs-Programme (2D) wie AutoCAD, CADAM können das regelmäßig. Vierecke, Kreise, Pfeile dazwischen mit festgeklebten Endpunkten und etwas Text sind eher eine Unterforderung. Meist gibt es eine Komponente, die die fertigen Elemente bereitstellt.
- Die Universal-Grafikpakete wie Corel, gimp haben meist ein Plug-In oder dergleichen, das die Elemente und deren spezielle Funktionalität unterstützt. Die Basisfunktion, manuell Kreise und Vierecke zu malen und mit Pfeilen zu verbinden, ist ohnehin mit jedem Malprogramm zu erzielen.
- Diagramm- und Planungssoftware wie MS Project hat das auch häufig an Bord.
- Oft ist die Funktion nur aufgesetzt und nicht sehr komfortabel. Der rein zeichnerische Ansatz der originären Grafikprogramme bedarf viel Handarbeit beim Layout und bei nachträglichen Veränderungen.
- Besser ist die automatische Generierung aus Pseudocode, bei der die gewünschte Grafik sich aus den Zeilen einer fiktiven Programmiersprache ergibt. Sie kann in der den Programmierern vertrauten Logik schnell verändert werden und liefert das aktualisierte Schema.
- Dazu gibt es -zig Produkte, auch als Shareware.
- Die IDE und Software-Dokumentationswerkzeuge sind oft in der Lage, Ablaufpläne aus dem Original-Quellcode bestimmter Programmiersprachen zu generieren.
- Allerdings wird heute überwiegend auf UML abgestellt und nicht auf die altertümliche DIN.
- Das ist für ein einzelnes Unterprogramm einmal machbar.
- Ein ganzes Softwaresystem lässt sich auf diese Weise nicht sinnvoll darstellen. Es liefert etliche Quadratmeter Tapete, und auch deren Darstellung auf dem Bildschirm ist nicht geeignet, irgendetwas zu verstehen, weil jedes Detail in die Grafik aufgenommen wird.
- Zweck der grafischen Darstellung ist es, für Menschen verständlich einen Überblick zu schaffen. Dazu ist die Reduktion auf das Wesentliche erforderlich; komplexe Teilaufgaben sind redaktionell im Text eines einzigen Blocks zusammenzufassen.
- Ansonsten werden Programmablaufpläne heutzutage in der eigentlichen Software-Entwicklung und Programmierung nicht mehr benutzt; nur noch bei Kommunikation mit den End-Anwendern zur Verdeutlichung und in der Ausbildung an Schulen und für Erstsemester.
VG --PerfektesChaos 10:00, 7. Mai 2013 (CEST)
Kurze Frage, PerfektesChaos, mit welcher Software macht man heute CodeReviews?
Naja Aivosto Oy > Visustin v6 wäre wohl auch zu nennen, da es bei Zoschke erhältlich ist Damit kann mann Quellcode-Dateien öffen, um die Ausführungsabfolge (Execution Flow) in einem Flußdiagramm zu visualisieren....--77.24.163.10 12:52, 8. Mai 2013 (CEST)
Vorschlag für die Textpassage
- Auswahl von Software zur Erstellung von Programmablaufplänen **
- Dia ein universelles Diagramm-, Zeichen- und Illustrationsprogramm
- Microsoft Visio ein universelles Diagramm- und Zeichenprogramm mit einer VBA-API
- Code Visual to Flowchart zur automatischen Erzeugung von Programmablaufpänen aus vorhanden Quelltexten
Außerdem gibt es viele Quellcodegeneratoren, wie das BOUML zur Erzeugung von Quelltexten aus UML-Plänen und Zeichenprogramme wie yED
- Wer es besser kann, der darf es gern verbessern ;)
- lg--77.24.52.205 17:50, 6. Mai 2013 (CEST)
- Nun, das halte ich für recht einfach. Ich baue auf Benutzer:Siehe-auch-Löschers Ansatz auf:
Grundsätzlich können Programmablaufpläne mit jedem Grafikprogramm oder auch von Hand auf Papier gezeichnet werden. Viele Grafik- und Büro-Programme bieten entsprechende Vorlagen, unterstützende Funktionen oder spezielle Module. Es gibt auch Programme, die speziell für das Erstellen von Diagrammen entwickelt wurden; diese bieten oft zusätzliche Fähigkeiten wie zum Beispiel automatisches Entflechten („kreuzungsfrei machen“) von Pfeilen und Verknüpfungslinien, oder das Prüfen auf Korrektheit entsprechend der DIN. Es gibt auch Programme, die Ablaufpläne aus Pseudocode oder aus Quellcode einer bestimmten Programmiersprache generieren können, oder umgekehrt aus einem Programmablaufplan den zugehörigen Quellcode in einer bestimmten Sprache erstellen können.
- ...und das Ganze ohne die Nennung irgend eines konkreten Programms "als Beispiel". Warum auch.
- --arilou (Diskussion) 11:28, 7. Mai 2013 (CEST)
Hallo arilou, wenn schon Software und Vorteile von Software zur Erstellung der PAP's genannt im Artikel werden, dann sollten auch die Vorteile von bekanter Software oder typischen Vertretern im Text stehen, weil sonst der Hinweis, dass man Software vewenden kann kein echter Mehrwert für den Artikel ist.
Du wirst in Kürze mit Sicherheit nicht um die Nennung von Programmnamen in diesem Zusammenhang herumkommen, wenn Du den Artikel gut machen willst, so lang es in der keine eigene WP:Kategorie oder eine Liste von geeigneter PAP-Software hier zu gibt.
Du kast diesen zustand selbst Ändern.
Die Gründe warum es in der WP kaum pasende Artikel hierfür gibt, weil es für diese Anwendungen sehr viele oft unbekannte Anbieter oder schon vom Markt verschwundene Anbieter mit unterschiedlichen Konzepten z.B. mit UML- bzw. GrafkFokus oder Codegeneratoren für einen sehr kleinen Markt gibt, sind auch Dir sicherlich selbst gut bekannt.
Wenn ich mich recht erinnere hast Du aus einer gesichtenten Version die Softwareauflistung gelöscht und hier diese Disk angestoßen. Deshalb erwarte ich auch, das Wir von Dir hier zeitnah realistische konsensfähige Vorschläge hierzu bekommen, die kein Nein und kein WischWaschi sind...--77.24.51.216 15:29, 7. Mai 2013 (CEST)
- Zu deinem Vorschlag "dann sollten auch die Vorteile von bekannter Software oder typischen Vertretern im Text stehen" stimme ich voll zu. Unter einer kleinen Randbedingung:
- "Vorteil": Zu jeder genannten Software muss dann auch im Text genannt werden, worin genau diese eine Software einen Vorteil bringt (den andere nicht bietet; ansonsten musst du alle Programme nennen, die diesen Aspekt anbieten);
- "bekannt": Dass z.B. "Visio" unter (allen!) Computer-Nutzern "bekannt" wäre, ist eine Behauptung. Selbst unter denen, die sich über den Programmablaufplan bei WP informieren wollen, ist Visio vmtl. eher unbekannt. Belege mir die "Bekanntheit" von Visio, und es darf ohne irgend einen Widerspruch meinerseits in den Artikel.
- "typisch": Ein Beleg, dass die genannte Software typisch ist. Z.B. ein (halbwegs reputabler) Zeitschriften-Artikel, der Software xyz als "typischen Vertreter von Diagramm-Erstellungs-Software" bezeichnet. Und dann ist noch nicht geklärt, warum von den unzähligen "typischen" gerade diese eine genannt werden soll, und nicht alle, die halbwegs "typisch" sind.
- "der Hinweis, dass man Software vewenden kann kein echter Mehrwert für den Artikel" - nuja; aber die Aussagen, dass es auch Software mit Auto-Entflechten u.ä. gibt, ist schon eine Information für die WP:OmA.
- "Du wirst in Kürze mit Sicherheit nicht um die Nennung von Programmnamen in diesem Zusammenhang herumkommen" - das ist eine Behauptung deinerseits. "wenn Du den Artikel gut machen willst" - ich sehe nicht, dass der Artikel "auf jeden Fall schlecht" wäre, wenn keine konkreten Softwareprodukte genannt werden. Ein Leser kann sehr gut informiert werden, was ein PAP ist und wie er regelkonform aufgebaut ist, ganz ohne dass konkrete Software-Produkte aufgeführt werden. Die Wikipedia ist eine Enzyklopädie, kein Softwareverzeichnis.
- "Du kannst diesen Zustand selbst ändern." Zur Zeit beschränke ich mich darauf zu verhindern, dass ein Neu-Autor entgegen den WP-Gepflogenheiten hießigen Artikel imo verschlimmbessert. Scheint mit z.Zt genug Arbeit für meine Person.
- "Die Gründe warum [...]" - Den Satz, und was du damit sagen möchtest, hab' ich nicht 100% verstanden, bzw. ist evtl. nicht ganz eindeutig.
- "gesichtete Version" - das Sichten ist eingeführt worden, damit IP-User-Vandalismus und "offensichtlicher Müll" nicht an die Leser ausgeliefert wird; es stellt keine weitergehende Legitimation dar. "Deshalb erwarte ich auch, das Wir von Dir hier zeitnah realistische konsensfähige Vorschläge hierzu bekommen, die kein Nein und kein WischWaschi sind" - ich halte mein "Nein" für deine Beiträge in dieser Weise für dringend notwendig. Dass mein obiger Vorschlag etwas wischi-waschi sei -hm- möglich. Den 1. Satz sowie vom 3. Satz den ersten Teil kann man eigentlich getrost wegstreichen, ja, da hast' recht.
- Zu deinem Vorschlag "dann sollten auch die Vorteile von bekannter Software oder typischen Vertretern im Text stehen" stimme ich voll zu. Unter einer kleinen Randbedingung:
- --arilou (Diskussion) 10:41, 8. Mai 2013 (CEST)
Es wird keinen konkreten Textvorschlag von arilou geben aber dafür gibt es Unterstellungen in Form einesWP:PA gegen über IP's gratis
- Ein brauchbarer temporärer IP- Kompromissvorschlag wurde ja revertiert
- und der Artikel ohne Not ein Tag später vom Benutzer:He3nry gegen annonyme Edits gesperrt.
- Ja glaubt wirklich Jemand das sind faire und akzeptable Alternativen???
- Nein, Ich lasse mich nicht so von Benutzer:He3nry und Benutzer:Arilou wie ein Idioten behandlen!!! (nicht signierter Beitrag von 2.205.123.110 (Diskussion) 17:58, 16. Mai 2013 (CEST))
- "Es wird keinen konkreten Textvorschlag von arilou geben" - ähm, hallo? Der konkrete Vorschlag steht oben, auf deinen Einwand "etwas wischi-waschi" bin ich eingegangen, darüber können wir auch weiter diskutieren.
- Den Rest beantworte ich auf meiner persönlichen Disku-Seite, da er bzgl. des Artikels weitgehend off-topic ist.
- Ach ja, eins noch: "temporäres" gehört nicht in den Artikel, "Kompromissvorschläge" macht/bespricht man in der Disku, und was "brauchbar" ist, ist POV.
- --arilou (Diskussion) 14:02, 17. Mai 2013 (CEST)
und warum Benutzer Diskussion:Arilou steht Dein Vorschlag bis heute nicht im Artikel?
- Weil ich mich an die WP:Wikikette und die WP-Gepflogenheiten halte, bei umstrittenen Abschnitten erst mal auf der Diskussionsseite eine akzeptierte Version auszuarbeiten. Derzeitige Version ist:
Viele Grafik- und Büro-Programme bieten Vorlagen zum vereinfachten Erstellen von Programmablaufplänen, unterstützende Funktionen oder spezielle Module. Spezielle Programme bieten oft zusätzliche Fähigkeiten wie zum Beispiel automatisches Entflechten („kreuzungsfrei machen“) von Pfeilen und Verknüpfungslinien, oder das Prüfen auf Korrektheit entsprechend der DIN. Mitunter können Ablaufpläne aus Pseudocode oder aus Quellcode einer bestimmten Programmiersprache automatisch generiert werden, oder es kann umgekehrt aus einem Programmablaufplan der zugehörige Quellcode in einer bestimmten Programmiersprache erstellt werden.
- ...etwas ent-wischi-waschi-t, wie gewünscht. --arilou (Diskussion) 09:12, 22. Mai 2013 (CEST)
- Finde ich gut. --Siehe-auch-Löscher (Diskussion) 09:20, 22. Mai 2013 (CEST)
- ...etwas ent-wischi-waschi-t, wie gewünscht. --arilou (Diskussion) 09:12, 22. Mai 2013 (CEST)
- Wo sind Beispiele mit Programmnamen von Marktfühern und von Spezialprogrammen (Codegeneratoren) in den Entwurf geblieben?
- Diese würden nämlich als Wp:Belege für den gewünschten Textvorschlag sehrwohl taugen...
- Wenn diese fehlen, dann ist es wirklich noch richtig Wischwaschi, weil es bekanntermaßen keine Universalsoftware für alle Anwendungsfälle zur PAP Erzeugung gibt....
- Da muss unbedingt nachgebessert werden!
- Lg.--77.24.82.69 20:05, 22. Mai 2013 (CEST)
- Ja, dass solche Funktionalitäten existieren, sollte belegt sein/werden.
- Aber - das wird dann kaum mehr als ein paar
<ref>
's; "Beispiele" und "Programmnamen" im Fließtext werden wohl weiter ziemlich 'Fehlanzeige' bleiben. - Auf deine Behauptungen(!) "Marktführer", "bekanntermaßen" geh' ich jetzt nicht nochmals ein.
- --arilou (Diskussion) 15:57, 23. Mai 2013 (CEST)
das wird dann kaum mehr als ein paar "Beispiele" und "Programmnamen"
im Fließtext werden wohl weiter ziemlich 'Fehlanzeige' bleiben.
Und warum nicht mehr Informationen, wenn es offensichtlich nicht die eine SoftwareLösung gibt ? warum keine WP:Belege ? warum immernoch kein umfassender Textvorschlag?? Warum dieses Theater um einige Links???
um die Nennung des einen oder anderen Marktführer oder typischen Vertreter wird man halt nicht vorbeikommen das ist halt WP:NPOV!!! (nicht signierter Beitrag von 77.25.184.31 (Diskussion) 15:31, 25. Mai 2013 (CEST))
- Bitte genauer lesen: Die Aussage war, dass die geforderten Belege zu
<ref>
s werden. Die tauchen im Fließtext nur als kleine blaue [1] oder ähnliches auf.- "Und warum nicht mehr Informationen, wenn es offensichtlich nicht die eine SoftwareLösung gibt ?"
- Den Einwand hab' ich nicht verstanden. Kannst du bitte genauer ausführen, was du mit "mehr Informationen" meinst?
- "warum keine Belege/'umfassender' Textvorschlag?" - weil ich kein D-Zug bin, und mein Leben nicht nur aus Recherche für die WP besteht. Da dauert's halt auch mal ein paar Wochen, bis ich die Zeit finde.
- "Theater um Links" - weil du nicht verstehst. Es geht nicht um "Links oder keine Links". Sondern um Begründung für jeden genannten Link.
- Und bzgl. "Marktführer" und "typischer Vertreter" kannst' oben nachlesen. Belege, dass jemand "Marktführer" ist, oder als "typisch" anerkannt ist. Dann hab' ich gar nichts dagegen, entsprechende Links hier aufzunehmen. Aber die blose Behauptung von Dir, Software xxx von Hersteller yyy sei Marktführer - da könnt ja jeder kommen und alles behaupten.
- --arilou (Diskussion) 12:06, 27. Mai 2013 (CEST)
- Damit arilou hier nicht so ganz alleine steht:
- Es gibt auf diesem Gebiet keinen „Marktführer“. Das habe ich einen halben Kilometer weiter oben schon einmal dargelegt.
- Es gibt Tausende von Programmen, die weltweit in den letzten dreißig Jahren entstanden sind und ein paar dämliche Kreise und Vierecke mit Text drin und Pfeilen dazwischen malen können.
- Die größten davon mögen ein ganzes Prozent Marktanteil im PAP-Sektor haben. Davon kann man sich aber nicht „Marktführer“ nennen.
- Das Thema DIN-PAP ist veraltet, wird in dieser Form nicht mehr professionell für die Entwicklung genutzt und ist Banane.
- VG --PerfektesChaos 23:17, 27. Mai 2013 (CEST)
- Damit arilou hier nicht so ganz alleine steht:
Totaler Wiederspruch für PerfektesChaos
- Es gibt meines Wissens keine Software die alle Anforderungen und Wünsche zur PAP-Erstellung
perfekt umsetzen kann...
- trotzdem gibt es Software, die einige spezielle Anforderungen der PAP-Erstellung besonders gut umsetzen können und dabei gibt es sehrwohl Marktführer und Software die besonders häufig im Einsatz ist...
- das ein PAP mehr ist als "paar dämliche Kreise und Vierecke mit Text drin und Pfeilen" ist, soltest Du selbst besser wissen, um hier für qualifiziert zu gelten...
- Die DIN-PAP gilt zwar als veraltet aber ist meines Wissens ist die DIN nicht zurückgezogen worden und wird heute aber in modifizierter Form als UML-Aktivitätsdiagramm verwendet. Das gilt auch für das Vorbild von der IBM!
- Das die Lehre gern auf andere und vermeintlich modernere Methoden zur Dokumentation von Software wie UML und PseudoCode verweist, ist kannt und kollidert mit dem Sinn den Zweck eines PAP's, den Codefluss in einer Funktion oder Methoden zubeschreiben bzw. zu dokumentieren in keinster Weise.
Deshalb bleibe ich immernoch bei meiner Forderung: einzelne representative Vertreter von geeigneter Diagrammsoftware mit Ihren Vorteilen bei der PAP-Erstellung im Artikel als WP:Beleg im Artikel PAP zubenennen. Solang es keine WP-Kategorie PAP-Software gibt. Das ist keine Werbung, da es ja wohl fast allen klar ist, das es keine einzelne Software gibt, die ALLE Anforderungen und Wünsche zur PAP-Erstellung perfekt ermöglicht! (nicht signierter Beitrag von 77.24.213.252 (Diskussion) 14:16, 2. Jun. 2013 (CEST))
- Archivierung dieses Abschnittes wurde gewünscht von: arilou (Diskussion) 16:58, 18. Sep. 2020 (CEST)
Quelle nicht mehr abrufbar
Unter dem Link http://www.fh-jena.de/~kleine/history/software/DIN66001-1966.pdf ist die zitierte Quelle nicht mehr abrufbar. Kann sie noch anderweitig gefunden werden? (nicht signierter Beitrag von Volvoxdiekugelamoebe (Diskussion | Beiträge) 12:50, 11. Okt. 2015 (CEST))
- auf archive.org verfügbar.
- --arilou (Diskussion) 15:23, 16. Okt. 2015 (CEST)
Auch dort ist die pdf nicht mehr zu finden. (nicht signierter Beitrag von 195.245.65.225 (Diskussion) 08:38, 20. Jul 2016 (CEST))
- Quatsch, sie ist dort sehrwohl:
- DIN 66001-1966.pdf
- --arilou (Diskussion) 09:16, 2. Dez. 2016 (CET)
- Archivierung dieses Abschnittes wurde gewünscht von: arilou (Diskussion) 16:58, 18. Sep. 2020 (CEST)