Hallo zusammen,
ich habe eine Frage an euch. Wie erstellt ihr eure Ablaufpläne oder Flußdiagramme? Ich möchte nicht wissen, mit welcher Software oder ob ihr die von Hand macht.
Mich interessiert mehr, wie ihr es aufteilt. Zeichnet ihr nur grob den Ablauf auf oder zB.: jede einzelne Funktion? Erstellt ihr das Programm schon "fertig" auf dem Papier? (als Skizze)
Mit steigender Erfahrung wird das nicht mehr nötig sein, das ist mir klar, aber soweit bin ich nicht, sonder erst auf dem Weg dorthin.
Wie habt ihr angefangen?
Als Beispiel würde ich das versuchen: 3x i2c Sensoren ; 2x Taster; 1x LCD ;
Wie würdet ihr das in einem Flussdiagramm unter bringen? ( KEIN CODE!!!) jeder Sensor kommt in ein "Kästchen" mit genauer Struktur oder doch nur der Name vom Sensor und gut ist?
Keine Ahnung wie ich es besser erklären könnte. Sorry.
Ich habe mehrere Arduino Bücher, aber dort wird das Thema nicht behandelt. Es geht nicht um irgend welchen Code, der nicht funktioniert, sondern von der Idee , auf's Papier.
Kennt jemand vielleicht auch ein paar Tutorials dazu, dann würde ich mich über einen Link freuen.
Mit drei Sensoren, 2 Tastern und LCD könnte das noch auf ein Blatt passen.
Klassischerweise macht man aber Struktogramme/Flussdiagramme hierarchisch.
Auf der obersten Ebene ist das oft noch sehr abstrakt:
"Taster einlesen", "Sensoren lesen", "Temperaturen berechnen", "Anzeige", "Eingaben verarbeiten" etc.
Für die Funktion "Taster einlesen" z.B. gibt dann auf einem extra Blatt ein eigenes Struktogramm.
das hilft dann auch, den Code besser zu strukturieren.
Oft sind dann in der loop nur noch die Aufrufe der Hauptfunktionen ggf in einer Zeitscheibe.
Mit steigender Erfahrung wird das nicht mehr nötig sein, das ist mir klar,
Sorry, aber das ist vollkommener Schwachsinn!
Ich will gar nicht sagen, wie viele Jahrzehnte ich schon programmiere....
Aber auf Flussdiagramme zu verzichten ist dumm. persönliche Ansicht
Mal abgesehen, von den Programmflussdiagrammen, habe ich die Datenflussdiagramme lieben gelernt.
Mittlerweile starte ich oft mit einem solchen Datenflussdiagramm, noch weit bevor ich festlege, welche Hardwarekomponenten jetzt wirklich in dem Projekt verwendet werden.
Bei einem Flussdiagramm geht es oft erstmal darum eine Übersicht über das System zu haben. Damit du überhaupt weißt was du implementieren musst. Es geht hier nicht unbedingt darum darzustellen wie das konkret gemacht wird. Das kann man natürlich auch tun, aber es ist vielleicht eher der Schritt danach.
Oder um in Software Engineering Begriffen zu bleiben: erst kommt die Analyse und danach der Entwurf
Außerdem gibt es dafür wie gesagt auch andere Diagrammtypen, vor allem für komplexere Sprachen, wenn nicht mehr alles rein prodzedural ist.
Eine Übersicht über den Hardwareaufbau des Systems ist kein Flussdisgramm, sondern ein Komponentendiagramm (wobei man sich hier nicht jedes Detail UML-konform machen muss) oder Blockdiagramm (der Begriff kommt eher aus der Elektronik, da sich Software Design nicht wirklich um Hardware kümmert).
Wenn das System viele Interaktionen mit dem Benutzer hat, kann auch das UML Use Case Diagramm hilfreich sein
ich erstelle bei komplexeren Aufgaben immer noch gerne ein Flussdiagramm. Es zwingt einen den Algorithmus zu strukturieren und systematisch vorzugehen. Ich benutze Papier und Bleistift. Ich kann auf Papier intuitiver arbeiten. Der Bleistift lässt sich für Änderungen radieren.
Bei einfachen Programmieraufgaben entsteht das Flussdiagramm einfach im Kopf und wird nicht mehr aufs Papier gebracht.
Bei komplexen Bedingungen mit Statusvariablen und mehreren Sensoren hilft eine Logiktabelle um den Überblick zu behalten.
Für die Programmierung finde ich auch wichtig das EVA-Prinzip zu berücksichtigen.
Wenn ich ein Projekt systematisch angehe, dann entsteht erst eine Beschreibung, was das Programm machen soll. Was wird eingegeben, was ausgegeben und wie werden die Daten verarbeitet.
Daraus entsteht sowohl der Plan für die Hardware wie auch die groben Flussdiagramme. Dabei wird das Projekt in die einzelnen Teile zerlegt und dann ggf. als Probeprojekte getestet.
Ich muss gestehen, dass ich die Hardware gelegentlich noch auf Papier bringe- den Datenfluß allerdings nicht. Mir reicht es komischwerweise es im Kopf zu haben... Ich fange dann in der Regel an, die Ausgabewerte zu erstellen, dann die Eingabewerte und dann die Verarbeitung von Eingabe zu Ausgabe. Dabei bemühe ich mich das so offen und allgemein zu gestalten, so dass ich dann immer noch Funktionen ergänzen kann.
Aktuelles Projekt wo ich es so mache ist ein TFT mit Touch und ganz vielen Menu- Ebenen. Von anvisierten 30 Ansichten in der Menu- Struktur sind bereits 10 fertig und laufen quasi auf Anhieb...
Erstmal ganz großes DANKE für die Antworten!
Das hat mir schon sehr geholfen und ich traue mich gar nicht zu fragen, ob ihr vielleicht ein paar Bilder von euren Diagrammen habt und sie zeigen könnt?
´habe auch so wie Du bei absolut "0 angefangen.
Wikipedia, Tabellenbücher etc. zu Rate gezogen.......
Dann für unsere Steuerung das beiliegende entworfen.
(Ich sende hier nur mal Blatt 1 und 5 als Beispiel und hoffe das das mit dem Datei Anhängen klappt)
Erstellt habe ich das im Auto-CAD. Sicher nicht das beste Programm dafür
aber damit kenne ich mich eben aus. Geht sicher auch mit Word und Excel zur Not.
Das „anfängste“, das mir bislang begegnet ist, sind drei Kästchen mit den Buchstaben E, V und A.
Obwohl ich mittlerweile für viele Dinge keinen Programmablaufplan mehr brauche, hat es mir erst kürzlich geholfen, die Ursache dafür zu finden, warum es mir nicht möglich war, mir einen eigentlich sehr einfachen Ablauf als PAP vorstellen zu können. Und wenn es um erste Ideen geht, benutze ich immer noch gerne Papier und Bleistift. Ich bin passionierter Kritzler
Ich erstelle meine Abläufe und Ablaufdiagramme mit yEd (gibt es online "Live" ohne installieren")
Damit lassen sich komplexere Programme und Abhänigkeiten gut umsetzen. HIer
und die Live Version >HIER<
Gruß
DerDani
