Hallo zusammen! Ich schreibe gerade an meine Diplomarbeit und würde gerne mal wissen, wie ihr das so bei euren Flußdiagrammen haltet. Da ich alle meine Variablen in Strukturen angeordnet habe, sind die Variablenname insgesamt ziemlich lang und somit für ein Flußdiagramm doch eher unpassend. Also beschreibe ich das Flußdiagramm sinngemäß mit Worten. Allerdings fehlt mir dann irgendwie der richtige Bezug zum Programm selbst, da sich der Leser ja nun alle Variablen selbst zusammenklamüsern muss... Bin leicht verwirrt und finde im Webz leider nichts so wirklich interessantes zu dem Thema. Habt ihr da evtl. einen Tipp? :) Gruß und vielen Dank, Johann
Schreib einfach die Strukturnamen in den Kopf des Flussdiagrammes, und verwende in den Kaesten dann nur das was nach den Punkten kommt. Mach die FD's in moeglichst kleinen Teilen also auf Funktionsebene und verweise in den anderen FD's auf die Namen. Ju
Hallo Ju, danke für die Antwort! Ich stell mich da jetzt mal ein bisschen blöd und frage ganz frech ob du da nicht vielleicht ein Beispiel hast? Wär super :-) Gruß, Johann
Wie lang sind denn die Variablennamen? Sprechende bezeichner sind gut, SCHREIENDE sind schrott. Hab mal eine Software gesehen wo der Verunstalter Variablen wie Sätze ausgeschrieben hat. Sowas ist Amateurliga. -> Diese_Variable_wird_jeden_Schreifendurchlauf_incrementiert_und_ist_vom_T yp_integer = Diese_Variable_wird_jeden_Schreifendurchlauf_incrementiert_und_ist_vom_T yp_integer+1;
Du hast zBsp.: zwei Struct's
typedef struct {
uint16_t limits[4];
uint16_t home[4];
uint8_t backlash[4];
uint16_t minvel;
uint16_t maxvel;
uint16_t cylMoveTimeOut;
uint16_t stepDelay;
} t_MachineProfile;
typedef struct {
uint16_t x;
uint16_t y;
uint8_t z;
uint16_t a;
} t_Position;
und die Variablen global
t_Position pos;
t_MachineProfile mProfile;
ein FD faengt mit dem "Start - Oval" an
in dieses Oval schreibst Du
Start
(with: pos, mProfile)
und in den Kaesten oder Romben
dann
x == limits[0]
oder
backlash[3] = a;
Das war jetzt mal mein erster Versuch... bin aber nicht wirklich glücklich damit... Ist das verständlich genug?
Ist natürlich auch noch nicht vollständig, es fehlen bei den Verzweigungen noch die Nein-Zweige. Soll nur ein Beispiel sein! :-)
Steel schrieb: > Sowas ist Amateurliga. > > -> > Diese_Variable_wird_jeden_Schreifendurchlauf_incrementiert_und_ist_vom_T > yp_integer = > Diese_Variable_wird_jeden_Schreifendurchlauf_incrementiert_und_ist_vom_T > yp_integer+1; Full Ack; Soweit ich mich erinnern kann werden vom Compiler nur die ersten 36 (oder so) Zeichen zur Unterscheidung der Variablen benutzt. Oder ist das Alte Schule? Ich hab mich an die Kamel-Schreibweise gewoehnt. Und verwende fuer locale oder globale Variablen Prefixe in menuscula. Ju
Oder ich mache natürlich alles mit den Variablen und beschreibe diese dann im begleitenden Text, wöre ja auch möglich oder? Dieser Mischmasch ist irgendwie so .. naja :-/
Johann schrieb: > Das war jetzt mal mein erster Versuch... bin aber nicht wirklich > glücklich damit... > Ist das verständlich genug? Viel zu viel geschreibe in den Kaesten. Deine Variablennamen sind verstaendlich genug. Du kannst die erklaerenden Texte weglassen. verwende lieber gleich die C-Syntax also adcAN1Val_us = x oder in den Verzweigungen adcAN1Val_us <= 100?
Als algemeinen Hinweis vielleicht noch eines. Wenn ein Flussdiagramm als Grundlage zur Programmierung dient solltest Du Pseudocode-Syntax oder Syntax der Programmiersprache verwenden in der auch das Programm geschrieben wird. Ist das Flussdiagramm naturwissenschaftlicher Art solltest Du die Mathematischen Syntax und Operatoren verwenden. Derjenige der Deine DA liest sollte wissen auf was er gefasst sein darf und sollte eine entsprechende Vorbildung mitbringen. Ju
Ein Flussdiagramm ist ja eher etwas von den einfacheren Dokumentationsmoeglichkeiten. Meist muss auch noch ein State-Event-Action-Diagramm hin.
Lieber nicht Konstrukte der Programmiersprache in dem Diagramm verwenden. Für den Programmierer ist das toll, aber für nicht Programmierer ungünstig. Beschäftige Dich mal mit UML. UML ist eine Darstellungssprache, die unter anderem auch für solche Diagramme vorgesehehn ist. Ziel von UML ist es, eine eindeutige Symbolik umabhängig von der Programmiersprache zu verwenden. So wie auch die Mathematik, die Chemie und die Musik ihre eigene standarisierte Symbolsprache verwendet. Ich denke, UML ist inzwischen allgemeiner Standard. Übrigens können die aktuellen Office Programme neben ihrer alten eigenen Symbolbibliothek auch UML. Schau es Dir mal a, Du wirst sehen, dass ein UML Diagramm fast genau so aussieht, wie Dein Entwurf. Nur mit dem Vorteil, dass UML Dir ganz genau vorschreibt, wie Du die Symbole, Linien und Pfeile zu beschriften hast.
Hm ich habe UML nur mal in einer Informatikvorlesung gesehen und da wurde meiner Erinnerung nach gesagt, dass es sich eher für OOP eignet. Da ich ja weder Klassen o.ä. in meiner Mikrocontrollerprogramm habe, dachte ich ein Flußdiagramm wäre besser. Ich glaube das wäre jetzt zu aufwändig mich für diese Programm in UML einzuarbeiten. ;) Ich habe das jetzt erstmal so umgesetzt, dass ich den gesamten Algorithmus zu meiner Regelung als Diagramm in Wortform darstelle und die einzelnen Teilbereiche dann in C-Syntax schreibe. Zusätzlich dazu erfolgt eine kurze Beschreibung in Textform. Gefällt mir ganz gut soweit :-) Vielen Dank für die Hilfe!
Es wird spät und man möge mir meine Tippfehler verzeihen ;-)
Normalerweise macht man ein Flussdiagramm BEVOR man codiert. Der Code ist also noch unbekannt. Daher haben Variablennamen im FD nichts verloren. Es geht um die Übersicht des Ablaufes, der auch für Nicht-Programmierer verständlich sein soll.
Bilder sagen mehr als Worte. Daher kann ein simples Flußdiagramm den Erkenntnisprozeß der späteren Leser verbessern. Einen Irrgarten sollte man aber vermeiden. MS-Visio wäre eine Variante wenn es nicht so teuer wäre.
UML ist keine Programmiersprache und hat mit OOP nur wenig gemeinsam. UML ist geeignet, um OOP Programme zu dokumentieren. Es ist aber auch genau so gut geeignet, andere Programme oder Prozesse zu beschreiben. UML ist sogar dazu gedacht, Geschätfsprozesse, Abteilungs-Hierarchien und Timing-Diagramme zu erstellen. Was Du da gezeichnet hast, ist im beinahe ein UML Diagramm. UML legt präzise fest, wann eine Linie durchgezogen oder gestrichelt gezeichnet wird. UML legt auch fest, wozu Pfeile dienen, wie man die Ausgänge einer Entscheidung beschriftet und so weiter. Objektstrukturen sind nur ein kleiner Teil von UML. UML deckt aber auch genau solche Diagramme ab, wie das von Dir gezeichnete. Der Vorteil in UML besteht darin, das die Symbole spezifiziert sind. Du kannst UML Diagramme auf der ganzen Welt vorziegen. Jeder der UML beherrscht, wird Dein Diagramm ohne großartige Erklärungen verstehen. Hätten wir kein UML, dann würde jeder andere Symbole verwenden und man müsste erstmal erklären, was die Symbole bedeuten. Ich könnte z.B. Dreiecke für Entscheidungen verwenden, die "Ja" Ausgänge grün malen und die "Nein" Ausgänge rot malen. Jemand anderes würde ganz andere Symbole verwenden und andere Farben. Und was, wenn die Entscheidung mehr als nur ja/nein Möglichkeiten kennt? Wie stellt man das dann dar? UML beantwortet diese Frage eindeutig. So wie man Schaltplane mit weitgehend genormten Symbolen zeichnet, sollte man auch Diagramme mit genormten Symbolen zeichnen.
Thread beobachten
Seitenaufteilung abschaltenBitte 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.