Hi!
Ich war aus meiner Praxissicht erst geneigt zu sagen, dass man die Flussdiagramme in der Tat nicht mehr nutzt. Dann habe ich mal darüber nachgedacht, wie ich arbeite und komme nun zu dem Ergebnis, dass ich zwar keine klassischen Flussdiagramme nutze, den Programmablauf (=Fluss) aber schon in größeren Schritten plane.
Das Flussdiagramm ist etwas für die Feinplanung der Umsetzung in Programmcode, da man auf dieser Ebene ja dann eigentlich jede Verzweigung visualisiert (wenn ich das richtig zusammen bringe, ich habe nie eine klassische Ausbildung in diesem Bereich gemacht, ich bin Quereinsteiger).
In der Praxis ist das für mich zuviel Aufwand. Das Flussdiagramm erst zu zeichnen und dann umzusetzen mache ich in der Praxis gar nicht mehr, weil ich den Fluss der einzelnen Prozeduren/Methoden quasi im Kopf visualisiere und dann umsetze.
Was die Grobplanung des Programmablaufes angeht, arbeite ich entweder prozess/prozedurbasiert (d.h. zuerst werden die Aufgaben festgelegt, die das Programm erledigen muss; benötigte Datentypen werden dann danach entworfen) oder "objektorientiert". Mein Weg zum letzteren ist dann zuerst die Datenstruktur zu modellieren und dann die zur Verarbeitung benötigten Methoden (Prozeduren bzw. Funktionen) zu entwerfen.
Da ich mir keine großen Gedanken mache, wie ich an ein Problem herangehe, ist es oft irgendwie beides. ;-)
Kurzer ernster Einwurf: ich arbeite beruflich mit einer Entwicklungsumgebung die leider nicht objektorientiert arbeitet; zudem ist der Ansatz oft die Prozessseite, da der Kunde festlegt, was passieren soll. In der Regel kennt der Kunde die Datenstrukturen gar nicht (versteht auch oft die Grundlagen der Datentypen gar nicht), so dass man quasi immer von der Prozessseite aus an die Aufgaben Beschreibung gehen muss.
In der Entwurfsphase kann ich dann, wenn ich die Zeit habe, die Sache aber natürlich von der Datenseite her angehen und dann evtl. andere Lösungsansätze erarbeiten, die man aus der Prozesssicht zuerst nicht "heraussehen" konnte. Das kann man dann wieder als Prozess beschreiben und so dem Kunden vermitteln, dass diese Version günstiger ist. Das klappt aber nicht immer. ;-)
Kurz gesagt: aus meiner Sicht sind Flußßdiagramme "Basics" die man sowieso draufhaben muss, um ein Programm schreiben zu können. Für den Einstieg sehe ich da keinen Fehler drin, sie zu nutzen. Man muss schließlich "hinter" die Sache mit den Programmfluss kommen, um selbst programmieren zu können.
Später nutzt man das nicht mehr, da man ein Programm prozess- oder objektorientiert plant. Dabei werden jeweils Verarbeitungsfunktionen geplant, die man dann später umsetzt. Bei diesem Schritt könnte man Flussdiagramme nutzen, aber aus Zeitgründen verzichtet man in der Praxis darauf, weil man das quasi im Kopf macht.
Trotzdem gibt es Fälle in welchen ich persönlich eine vereinfachte Art von Flussdiagrammen nutze: wenn ich mich in Programmcode einarbeiten muss, den ich nicht geschrieben habe, um dort logische Fehler im Ablauf zu finden, die bisher niemand gefunden hat... ;-)
Bis dann
Andreas
Elo
Andreas42
