Hallo, wollte mal fragen, ob bei den hiesigen Programmierern für diverse AVR's Flussdiagramme zum Einsatz kommen. Wenn ja, gibt's da spezielle Programme für oder wird einfach jede mögliche Art verwendet? Werden/können diese dann im Atmel Studio bei den Projekten hinterlegt? Wie macht Ihr das überwiegend? Neugierige Grüße Peter
Peter schrieb: > Wie macht Ihr das überwiegend? Einfach losprogrammieren. Wenn mit Flussdiagramm, dann Bleistift und Papier.
Peter schrieb: > wollte mal fragen, ob bei den hiesigen Programmierern für > diverse AVR's Flussdiagramme zum Einsatz kommen. Flussdiagramme sind im Zeichen von blockorientierter Programmierung völliger Unfug. Guck dir mal Nassi-Shneiderman-Diagramme an. Die sind erheblich hilfreicher, wenn es um die Entwicklung der Programmstruktur geht. http://de.wikipedia.org/wiki/Nassi-Shneiderman-Diagramm
Einfach programmieren. Vielleicht noch hier und da ein
1 | // TODO:
|
2 | // was auch immer
|
einfügen, das hilft, wenn man erst mal das Grundgerüst aufbaut und sich zunächst auf entsprechende Details noch nicht konzentrieren möchte (Top-Down-Prinzip). Bis ich ein Flussdiagramm fertig habe, bin ich auch mit programmieren fertig. Zumindest wenn ich die Sprache gut beherrsche; tue ich das nicht, sind die Programme sowieso sehr einfach und die Frage stellt sich gar nicht erst.
Für das Zusammenspiel zwischen ISRs und Hauptprogramm sind Flussdiagramme das brauchbarste. Diese AVR Programme bleiben recht klein. Tools für den Entwurf der Struktur lohnen sich nicht.
Wolfgang schrieb: > Flussdiagramme sind im Zeichen von blockorientierter Programmierung > völliger Unfug. Sagst Du. Gut. Du hast aber nicht das Copyright auf Allgemeingültigkeit. Es gibt Leute, die lassen sich ihr Werkzeug nicht vorschreiben und benutzen nach wie vor Flussdiagramme.
Flussdiagramme weniger (aber auch schon mal ab und zu). State Machines werden immer dokumentiert, auserdem die Architektur generell, also das Zusammenspiel der einzelnen Komponenten. Doku ist wichtig, am Besten paralell zur Implementierung, weil nachher macht mans eh nicht mehr. Die Bastler hier die eh alles in die main.c stopfen machen das natürlich nicht. Dementsprechende Sourcen sieht man dann hier oft im Forum.
Also ich finde es durchaus sinnvoll, sich vorher Gedanken zu machen, was das Programm nachher leisten soll. Wenn das Konzept steht, braucht man es nachher nur noch zu kodieren. Formell gibt es dafür keine Regeln, aussagefähig muss es sein. Hat mir übrigens letztens auch ein SPS-Programmierer gesagt
Kai Mauer schrieb: > Es gibt Leute, die lassen sich ihr Werkzeug nicht vorschreiben und > benutzen nach wie vor Flussdiagramme. Das Problem daran ist, dass sich die Kapselung, wie sie sich bei blockorientierter Programmierung fast von selbst ergibt, in einem Flussdiagramm erstmal überhaupt nicht zu Tage tritt. Nicht mal Eingang und Ausgangen, wie sie im Programm nachher auftauchen, sind daran wieder zu erkennen. Man macht sich das Leben einfach unnötig schwer. Mit Vorschreiben hat das nichts zu tun. Wer einmal Nassi-Shneiderman-Diagramme für den Entwurf in einer blockorientierten Programmiersprache verwendet hat, wird davon nie wieder zu Gunsten eines Flussdiagramms abrücken. Wer natürlich einen Spagettiprogrammierstil, am liebsten mit wilden Goto-Orgien verwendet, findet sich im Flussdiagramms tausend mal besser wieder.
Wolfgang schrieb: > Wer natürlich einen Spagettiprogrammierstil, am liebsten mit wilden > Goto-Orgien verwendet, findet sich im Flussdiagramms tausend mal besser > wieder. Unsinnige Unterstellung.
Auch hier ist es vermutlich nicht das ODER ... Sondern eher das "sowohl als auch". Also kein Grund sich gleich wieder an die Kehle zu gehen.... Und es gibt ja auch noch mehr: Datenflussdiagramme
Angehängte Dateien:
-
tempregler.svg
32 KB
Ulrich F. schrieb: > Datenflussdiagramme Finde ich 9000 mal hilfreicher als Flussdiagramme oder Nassi-Shneidermann. Grobes Beispiel im Anhang (ich male sowas aber von Hand und schreibe formlos noch viel mehr Details dazu).
Tom schrieb: > Ulrich F. schrieb: >> Datenflussdiagramme > > Finde ich 9000 mal hilfreicher als Flussdiagramme oder > Nassi-Shneidermann. Grobes Beispiel im Anhang (ich male sowas aber von > Hand und schreibe formlos noch viel mehr Details dazu). Dito.
Peter schrieb: > wollte mal fragen, ob bei den hiesigen Programmierern für > diverse AVR's Flussdiagramme zum Einsatz kommen. Ich nehme an, du meinst mit Flussdiagrammen Programmablaufpläne (PAPs): http://de.wikipedia.org/wiki/Flussdiagramm http://de.wikipedia.org/wiki/Programmablaufplan Kurze Antwort: Nein, ich verwende Programmablaufpläne so gut wie nicht. Gleiches gilt für Struktogramme (Nassi-Shneiderman-Diagramme). Etwas längere Antwort (;-)): Wenn ein Architekt ein Haus plant, fertigt er davon mehrere Zeichnungen an, die das Haus aus unterschiedlichen Abständen und Richtungen zeigen. Über den Betrachtungsabstand wird der Detaillierungsgrad festgelegt, durch die Änderung Betrachtungsrichtung werden Größen wie Länge, Breite und Höhe des Hauses oder Teilen davon sichtbar gemacht, die in einer Einzelansicht nicht alle zu erkennen sind. Nur durch Betrachtung aller dieser Zeichnungen kann sich der Kunde ein Bild davon machen, ob das geplante Haus tatsächlich seinen Wünschen entspricht. Genau so ist es bei der Software: Eine Ansicht davon ist der Quellcode. Er ist – formal gesehen – vollständig, da er detailliert alle Informationen zu den verwendeten Algorithmen, Datentypen usw. enthält. Für die zeilgerichtere Planung, die bessere Übersicht und das späteren Verständnis durch andere ist es aber sinnvoll, weitere Ansichten anzufertigen. Vergrößerung des Betrachtungsabstands ===================================== Wie bei den Zeichnungen des Hauses gibt es die Möglichkeit, den Betrachtungsabstand zu vergrößeren, d.h. den Detailreichtum zu verringern, um einen besseren Gesamteindruck zu bekommen. Hier kommen PAPs ins Spiel, mit denen im Wesentlichen folgendes erreicht wird: 1. Die programmiersprachenspezifische Syntax wird durch generische grafische Symbole (Rechtecke, Rauten, Pfeile usw.) und Prosatexte ersetzt, was die Lesbarkeit durch weniger geübte Programmierer verbessert. 2. Solange nur der Gesamtablauf eines Programms oder eines Teils davon dargestellt werden soll, werden Dinge wie z.B. genaue Variablentypen, Dimensionierung von Arrays, Fehlerabfragen u.ä. weggelassen, da das durch sie erzeugte "Rauschen" die wesentlicheren Aspekte teilweise verdecken könnte. So gesehen sind PAPs eigentlich eine feine Sache. Auch Struktogramme zielen in die gleiche Richtung, nur dass diese die Kontrollstrukturen von vornherein auf das beschränken, was in der strukturierten Programmierung als "sauber" angesehen wird. Das erleichtert die anschließende Umsetzung in Quellcode, und Spaghetti-Code mit vielen Gotos kann gar nicht erst entstehen. Es gibt aber noch eine weitere Darstellungsform mit einer ähnlichen Ausdruckstärke wie PAPs und Struktogramme: Pseudecode. Da Pseudokcode kompakter ist und am Computer schneller erstellt und modifiziert werden kann, ziehe ich ihn den beiden genannten grafischen Darstellungsformen ganz klar vor. Wenn man eine Programmiersprache und die strukturierte Programmierung allerdings gut beherrscht, kann man in den meisten Fällen sogar auf den Pseudokcode verzichten, denn: - Die sprachspezische Syntax liest sich dann praktisch genauso schnell wie Prosatext, in einigen Fällen sogar noch schneller (da kompakter). - Ein Programm, das in viele kleine und überschaubare Unterprogramme mit aussagekräftigen Namen aufgegliedert wird, verlagert Details immer in die jeweils nächsttieferen Ebene in der Unterprogrammhierarchie. Die Unterprogrammnamen (ggf. ergänzt durch Kommentare) treten dabei an die Stelle des Prosatexts im Pseudokcode. - Mit etwas Geschick kann man das "Rauschen" in Form von Deklarationen Fehlerabfragen u.ä. oft hinreichend von den algorithmischen Teilen des Programms zu trennen, so dass es nicht mehr stört. Einige neuere Programmiersprachen (die leider nicht für AVRs und andere kleine µC) verfügbar sind), unterstützen diese Trennung sogar explizit. Eine Dokumentation mit Pseudocode braucht man dann nur noch an den ganz seltenen Stellen, wo der eigentliche Algorithmus wegen Defiziten der Programmiersprache oder auf Grund von unvermeidlicher Handoptimierung unleserlich wird. Pseudocode hat hier gegenüber grafischer Diagramme den Vorteil, dass man ihn als Kommentar direkt in den Quellcode integrieren kann, was die Pflege bei späteren Änderungen erleichtert. Den Sinn von PAPs und Struktogrammen sehe ich vor allem bei Leuten, die eine Programmiersprache gerade erlernen oder darin noch nicht sehr sattelfest sind. Durch das Zeichnen des Diagramms und dem anschließenden Schreiben des Quellcodes werden die Entwicklung des Programmablaufs und die Auseinandersetzung mit syntaktischen und semantischen Eigenheiten der Programmiersprache zeitlich voneinander getrennt, so dass man sich immer nur auf jeweils eine der beiden nicht ganz leichten Aufgaben konzentrieren muss. Auch für einen Lehrer ist es leichter, seinen Schüler zu beraten, da er anhand des Diagramms schneller sehen kann, ob der Schüler überhaupt den richtigen Ansatz für das zu erstellende Programm gefunden hat. Veränderung der Betrachtungsrichtung ==================================== Die Vergrößerung des Betrachtungsabstands (d.h. die Verringerung des Detaillierungsgrads), wie sie durch PAPs, Struktogramme und Pseudocode bewerkstelligt wird, ist aber nur ein Aspekt, um den Überblick über komplexe Programe zu er- und behalten. Wie oben am Beispiel des Hauses erläutert, kann man nicht nur den Abstand, sondern auch die Richtung der Betrachtung variieren. Dafür gibt es sehr viele Möglichkeiten, die ich hier nicht alle aufzählen kann. Ein sehr gutes Beispiel hat weiter oben Tom gezeigt: Tom schrieb: > Grobes Beispiel im Anhang Es handelt sich dabei um ein Datenflussdiagramm. Es entsteht aus dem Quellcode (sofern in einer imperativen Sprache wie C, C++, Pascal oder Basic geschrieben) nicht einfach durch Weglassen von Syntax und Details, und man kann umgekehrt auch nicht durch Hinzufügen von Syntax und Details das Diagramm direkt und ohne viel Denkarbeit in Quellcode überführen. Deswegen ist es eine komplett andere Ansicht des Programms, die viele Dinge zeigt, die einem beim Betrachten eines PAPs verborgen bleiben. Wie der Name bereits sagt, handelt es sich hier um eine datenflussorientierte Ansicht, während beim PAP der Kontrollfluss im Vordergrund steht. Das Sequenzdiagramm ist weitere wichtige Ansicht: http://de.wikipedia.org/wiki/Sequenzdiagramm Mit ihm können zeitliche Abfolgen, Synchronisation und Kommunikation von/zwischen nebenläufigen Programmteilen auf einem oder mehreren Prozessoren beschrieben werden. Programmteile, in denen eine Aktivität durch Ereignisse getriggert wird (wie bspw. die byteweise Verarbeitung von Nachrichten über eine serielle Schnittstelle) können übersichtlicher durch ein Zustandsdiagramm dargestellt werden: http://en.wikipedia.org/wiki/State_diagram Es gibt aber auch Darstellungsformen, die schon wesentlich älter als die Softwareentwicklung sind. Ein Beispiel sind geometrische Skizzen. Die Auswertung von GPS-Koordinaten, das Herausrechnen der perspektivischen Verzerrung eines Kamerabildes oder die Berechnung einer Roboterkinematik (um nur einige Beispiele zu nennen) würden trotz ihrer Komplexität in einem PAP, Struktogramm oder Datenflussdiagramm als ein einzelner Block mit ein paar dicken Formeln dargestellt werden. Nachvollziehen kann man diese aber erst mit einer entsprechenden Skizze. Alle vier in diesem Abschnitt genannten Darstellungsformen sind meiner Meinung nach viel wichtiger als PAPs und Struktogramme, da ihr Inhalt nur sehr schwer aus dem Quellcode extrahiert werden kann. Umgekehrt ist es auch schwierig, den Quellcode zu schreiben, bevor man sich diese Dinge visuell klar gemacht hat. Des Weiteren sind mir auch keine textuellen Beschreibungsformen (vergleichbar mit Pseudocode) bekannt, die als vollwertiger Ersatz für die Diagramme dienen könnten Das heißt aber nicht, dass man jetzt krampfhaft versuchen sollte, mit jedem dieser Diagrammtypen das komplette Programm zu beschreiben. Vielmehr überlegt man sich für jeden komplexeren Programmteil, welcher Typ diese Komplexität am übersichtlichsten darstellt bzw. ob der Quellcode mit Kommentaren nicht schon aussagekräftig genug ist. Man ist man dabei natürlich auch nicht auf die Diagrammtypen nach DIN, ISO, UML und anderen (De-facto-)Standards beschränkt. Erlaubt ist alles, was einem selbst oder anderen das Leben leichter macht.
Vielen lieben Dank für die zahlreichen Antworten. Sind für mich sehr interessante Ansätze vorhanden, die bei mir sicherlich auf die eine oder andere Art zur Anwendung kommen werden. Hat sich gelohnt. Gruß Peter
Thread beobachten
Seitenaufteilung abschalten
Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.