mikrocontroller.net

Forum: PC-Programmierung Struktogramme in C


Autor: __Son´s B. (bersison)
Datum:

Bewertung
-1 lesenswert
nicht lesenswert
Hallo.
Habe einen Fehler in einem main-Ablauf, aus dem Kopf heraus ist mir der 
Ablauf zu unübersichtlich.
Daher möchte ich die Programmierung mit einem 
Struktogramme/Programmablauf-Diagramm graphisch darstellen.

--1--
Welche Freeware hat sich bewährt?
Reicht MS Excel oder Word?
--2--
Ist das Nassi-Shneiderman-Diagramm für einfache Programmabläufe (bin 
Einsteiger) sinnvoll?
--3--
Wann und in welchen Fällen sollte man(n) vor(!) der eigentlichen 
Programierung, eine graphische Strukturdarstellung erzeugen?
Oder sind es veralterte Hilfsmittel (DIN 66001 von 1983)?

Autor: Bernd K. (prof7bit)
Datum:

Bewertung
4 lesenswert
nicht lesenswert
Diese genormten Darstellungen werden überbewertet.

Mal es so hin daß es für Dich selbst maximal übersichtlich und 
aussagekräftig ist und somit maximal nützlich und produktiv ist. 
Notfalls erfinde kurzerhand eine neue Diagrammart die genau dieses 
Problem gut illustrieren kann. So sind die anderen auch alle entstanden.

Erst wenn Du eine offizielle Doku abliefern muss die einem genauen 
Standard entsprechen muss fängst Du an mit genormten Diagrammformen und 
rechtwinkligen Pfeilen nutzlose Zeit zu verbrennen.

Um schnell mal Kreise oder Kästchen mit Pfeilen zu verbinden bietet sich 
dia an. Ansonsten Zettel und Stift oder noch besser Whiteboard und 
Schwamm.

Aufruf- und Aufrufer-Bäume aus existierendem C-Code mit doxygen und 
graphviz.

: Bearbeitet durch User
Autor: Walter T. (nicolas)
Datum:

Bewertung
-1 lesenswert
nicht lesenswert
__Son´s B. schrieb:
> Welche Freeware hat sich bewährt?

Karopapier oder noch besser (falls es nachher eingescannt werden soll): 
Punktrasterpapier.



__Son´s B. schrieb:
> Wann und in welchen Fällen sollte man(n) vor(!) der eigentlichen
> Programierung, eine graphische Strukturdarstellung erzeugen?

a) Wenn das Programm mehr als zwei Verzeigungen nehmen kann oder aus 
anderen Gründen die der Ablauf unübersichtlich werden könnte.

b) Bei Zustandmaschinen und ihren Übergängen. Wobei da andere Diagramme 
besser sind als Struktogramme.

Autor: db8fs (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
__Son´s B. schrieb:
> Hallo.
> Habe einen Fehler in einem main-Ablauf, aus dem Kopf heraus ist mir der
> Ablauf zu unübersichtlich.
> Daher möchte ich die Programmierung mit einem
> Struktogramme/Programmablauf-Diagramm graphisch darstellen.

Um Fehler im Code zu erkennen, sind Diagramme nicht das adäquate Mittel.

Warum restrukturierst du deinen Code nicht so, dass dein main()-Ablauf 
so einfach wird, dass du kein Diagramm mehr brauchst. D.h. globale 
Variablen von der main()-Methode als Parameter in Funktionen 
hineinschleifen. Die Funktionen dabei so einfach machen, dass klar ist, 
was darin passiert.

Am besten schreibste dir kleine Tests, die die Funktionalität deiner 
neuen Funktionen prüfen.

> --1--
> Welche Freeware hat sich bewährt?
> Reicht MS Excel oder Word?

Kommt drauf an, wer das lesen muss bzw. was gefordert wird. Für UML ist 
Enterprise Architect, Magic Draw, Altova UModel, ArgoUML verfügbar. Wenn 
du nicht erst UML lernen willst, musste halt das nehmen, womit du 
zurecht kommst.

> --2--
> Ist das Nassi-Shneiderman-Diagramm für einfache Programmabläufe (bin
> Einsteiger) sinnvoll?

Kann man machen, macht aber außer vermutlich in der Schule/Lehre keiner 
mehr. Praxis sind UML Interaktionsdiagramme (Sequenzdiagramme).

> --3--
> Wann und in welchen Fällen sollte man(n) vor(!) der eigentlichen
> Programierung, eine graphische Strukturdarstellung erzeugen?
> Oder sind es veralterte Hilfsmittel (DIN 66001 von 1983)?

Unterscheide fachliche Sicht (Domäne) von technischer Sicht (Umsetzung). 
Fachlich lohnt es sich oft, Struktur, Verhalten, Anwendungsfälle, 
Verteilungssicht zu dokumentieren. Als Grobdokumentation versteht sich - 
ein so feingranulares Modell, dass man Code daraus generieren kann, wird 
selten gemacht.

Wenn du aber noch Probleme hast, C-Code zu verstehen - dann hilft dir 
nur Übung im Restrukturieren des Codes unter bestmöglicher Beibehaltung 
der Funktionalität. Und das sehr oft machen und so wenig neuen Code wie 
möglich schreiben, damit du erstmal deine Anwendung selber sauber 
verstehst.

Mehr kann ich dir nicht raten.

Autor: Dirk B. (dirkb2)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Du kannst deinen Code mal von doxygen bearbeiten lassen.
http://www.stack.nl/~dimitri/doxygen/

Auch ohne Metainformationen im Code gibt das einen Überblick der 
Software.
Wenn man es entsprechend einstellt, mit Hyperlibnk zu den Funktionen 
oder auch als Aufrufdiagramm.

Es gibt auch eine Erweiterung (Moritz), die daraus Ablaufdiagramme 
erstellt.
Über die Qualität kann ich aber nichts sagen.
http://moritz.sourceforge.net/

Autor: Wilhelm M. (wimalopaan)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich kann

https://www.sourcetrail.com/

empfehlen

Autor: __Son´s B. (bersison)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
DANKE, für eure konstruktiven Ratschläge und Infos!

Autor: JJ (Gast)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
Für Ablauf und UML Diagramme kann ich dir yED sehr empfehlen:
https://www.yworks.com/products/yed

Autor: Achim S. (achs)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
Du brauchst einen Editor, der Deinen Quelltext lesbar darstellt. Erst 
dann kannst Du die Anmerkungen zu Deinem letzten Programm überhaupt 
verstehen.

Am Ende musst Du so kodieren, dass Du es lesen kannst, alles andere ist 
Management-Bullshit. Das man nur Notepad zu programmieren braucht ist so 
sinnfrei wie man brauche nur einen Hammer und keine verschiedenen 
Schraubenzieher. Wenn Du ein akutes Verständnis-Problem hast, dann nimm 
ein Papier und Bleistift dazu, aber komme nicht auf die Idee, dass sowas 
über den Moment hinaus einen Wert besitzt. Es veraltet in dem 
Augenblick, wo Du es verstanden hast, dann ist es wertlos.

Autor: Bernd K. (prof7bit)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Achim S. schrieb:
> Das man nur Notepad zu programmieren braucht ist so
> sinnfrei wie man brauche nur einen Hammer und keine verschiedenen
> Schraubenzieher.

Das hat noch nie einer behauptet. Selbst die Vim- und Emacs-Fraktionen 
behaupten das nicht. Auch hat er weder nach einem Editor gefragt, noch 
hat er behauptet Notepad zu nutzen, wie kommst Du also darauf?

Autor: Achim S. (achs)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Bernd K. schrieb:
> Auch hat er weder nach einem Editor gefragt, noch
> hat er behauptet Notepad zu nutzen, wie kommst Du also darauf

In seinem Post Beitrag "if-Anweisungen als Block" hat er 
explizit von "optimieren" und "übersichtlicher" geschrieben, bei recht 
ungewöhnlicher Codegestaltung.

Mit der Frage híer drängt sich der Verdacht auf, dass der Editor keine 
für ihn ausreichende Navigation über den Code ermöglicht. Chromacoding, 
selektive Displays etc. sollten heute Standard sein. Es gibt ja auch 
Editoren, die "normalen" Code in Nassi-Shneydermann darstellen wenn 
gewünscht. (EasyCase?)

Die Notepad-Metapher stammt hier nicht von ihm, begegnet mir aber im 
Umfeld von "hab auch Software gemacht"-Managern hin und wieder und ist 
halt einfach falsch. Ein guter Editor sollte C & Co ähnlich gut 
präsentieren wie die veralteten Diagramme, die er sucht.

: Bearbeitet durch User
Autor: Mark (Gast)
Datum:

Bewertung
2 lesenswert
nicht lesenswert
__Son´s B. schrieb:
> Wann und in welchen Fällen sollte man(n) vor(!) der eigentlichen
> Programierung, eine graphische Strukturdarstellung erzeugen?
> Oder sind es veralterte Hilfsmittel (DIN 66001 von 1983)?

Diese DIN dokumentiert Vorgehensweisen die damals schon 40 Jahre alt 
oder noch älter waren. Ob man die heute noch anwendet hängt vom Problem 
ab.

Im Prinzip ist es mit solchen Techniken wie mit dem Werkzeugkasten eines 
Handwerkers. Vor eine gegebene Aufgabe gestellt sucht der Handwerker ein 
passendes Werkzeug aus dem Kasten. Manchmal, aber selten, ist es das 
alte schon angerostete Werkzeug ganz unten in der Tasche. In der Hand 
des Meisters leistet es dann seinen Dienst.

Ich verwende Blockdiagramme (auch Flussdiagramme, Programmablaufpläne, 
PAPs genannt) nur noch ganz selten. Normalerweise schnell hingekritzelt 
auf Papier und kurz danach weggeworfen, oder am Whiteboard wenn ich 
meinem Chef etwas in ganz einfachen Worten erklären muss.

PAPs haben das grundsätzliche konzeptionelle Problem, dass sie 
Systemaspekte nicht klar trennen, zum Beispiel Algorithmen, Prozesse und 
Interaktion mit dem System.

PAPs gehören noch in die Werkzeugtasche des Softwerkers, allerdings ganz 
unten und in der Tasche sollten bessere Werkzeuge für die graphische 
Darstellung von Software sein.

Autor: chris (Gast)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
Für einfache Sachen gibt es den Pap-Desiner:
http://friedrich-folkmann.de/papdesigner/Hauptseite.html

Autor: Sheeva P. (sheevaplug)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
chris schrieb:
> Für einfache Sachen gibt es den Pap-Desiner:
> http://friedrich-folkmann.de/papdesigner/Hauptseite.html

Wenn man so etwas für viele verschiedene Typen von Diagrammen, obendrein 
portabel für Windows, Linux, MacOS/X und diverse weitere Betriebssysteme 
haben will, empfehle ich gerne das Programm "dia" [1].

[1] http://dia-installer.de/

Autor: Wilhelm M. (wimalopaan)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
Sheeva P. schrieb:
> chris schrieb:
>> Für einfache Sachen gibt es den Pap-Desiner:
>> http://friedrich-folkmann.de/papdesigner/Hauptseite.html
>
> Wenn man so etwas für viele verschiedene Typen von Diagrammen, obendrein
> portabel für Windows, Linux, MacOS/X und diverse weitere Betriebssysteme
> haben will, empfehle ich gerne das Programm "dia" [1].
>
> [1] http://dia-installer.de/

Soweit ich den verstanden habe, will er seinen Code in eine alternative 
/ graphische Darstellung automatisch transformieren: wenn er seinen 
Ablauf zeichnen könnte, hätte er womöglich das Problem nicht.

Deswegen hätte er evtl. mehr Nutzen von sowas wie

https://www.sourcetrail.com/

oder

https://woboq.com/codebrowser.html

Ist aber nur eine Vermutung von mir ...

Autor: __Son´s B. (bersison)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo zusammen.

Wie bereits am 18.12. geschrieben, habe ich einige Anregungen dankend 
angenommen und verarbeitet.
Besonders die Gedanken darum, WARUM und FÜR WEN meine Darstellungen 
gedacht sind... Zielorientiert!

Da es ausschließlich zu meiner eigenen Orientierung vorgesehen ist, und 
ich so oder so dauernd mit Excel hantiere, werde ich Abläufe mit 
einfacher Excel-Graphik darstellen - einfache Kästchen mit 
aussagefähiger Beschriftung und ein paar Wege-Pfeilen.

Nun verselbstständigen sich einige eurer Vermutungen/Unterstellungen ins 
"Merkwürdige". Daher werde ich dieses Thread nicht weiter verfolgen.

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.