Liebe Community, Ich habe mich gerade gefragt, ob es eine "einfache" Möglichkeit gibt mein inzwischen ziemlich komplexes (viele Zeilen) C Projekt automatisch in eine Rohfassung eines Flow-Charts zu übersetzen. Das ist ja nun sicher ein Problem das jeder, der mehr oder weniger Programmiert und danach dokumentieren will schon einmal hatte, deshalb hoffe ich gerade: Gibt es Freeware oder Tools die ihr dafür empfehlen könnt? Viele Grüße Alex
Zum Nachvollziehen nutze ich gerne die "Call Hierarchy" von Eclipse CDT. Aber zum Dokumentieren ist das leider nicht so richtig geeignet. :-( Gruß Dennis
Es gab früher EasyCase (heute EasyCode), der C in NassiShneiderman darstellen konnte. Der Wert ist aber in der Regel gleich 0, da C eine ungleich größere Ausdrucksstärke besitzt als ein Flowchart. Es gibt in der Regel 3 Möglichkeiten, in absteigender Empfehlung 1) Schreibe Deinen Code so sauber, dass ein Programmierer ihn versteht. Dann male für jede dedizierte Zielgruppe angepasste Flowcharts (bzw. lasse malen) 2) Programmiere in Flowcharts (z.B. Matlab/Simuling/Stateflow) und lasse Dir den C-Code erzeugen. 3) Dokumentiere Deinen Code z.B. mit Doxygen und lasse eindrucksvolle (aber meist wertlose) Dokumentation in meisterhaftem Layout erstellen
Dennis S. schrieb: > Zum Nachvollziehen nutze ich gerne die "Call Hierarchy" von Eclipse CDT. > Aber zum Dokumentieren ist das leider nicht so richtig geeignet. :-( Dann lass Doxygen drüberlaufen, das kann diese Informationen ebenfalls extrahieren und auch wunderschöne Graphiken aus den Aufruf- und Aufrufer- und verschiedenen anderen Bäumen bauen. Mit den richtigen Kommentaren im Quelltext generiert das eine komplette Dokumentation mit einem einzigen Mausklick.
Nur leider sind die Callgraphen zur Doku ziemlich ungeeignet. Weil dann dokumentiert ist, wer was aufruft, aber nicht das Entscheidende: unter welchen Umständen. Highlevel-Doku bekommt man nicht automatisch, weil man dazu viele Details weglassen muß. Dazu muß man aber inhaltlich verstehen, was wichtig ist und was nicht, und das können Computerprogramme nicht.
Nop schrieb: > Highlevel-Doku bekommt man nicht automatisch, weil man dazu viele > Details weglassen muß. Dazu muß man aber inhaltlich verstehen, was > wichtig ist und was nicht, und das können Computerprogramme nicht. Deshalb kann man ja bei jedem zu dokumentierenden Element soviel erklärenden Text hinschreiben wie nötig ist um diese lnformationslücken zu füllen.
Bernd K. schrieb: > Deshalb kann man ja bei jedem zu dokumentierenden Element soviel > erklärenden Text hinschreiben wie nötig ist um diese lnformationslücken > zu füllen. Äh? Ich schrieb doch, das Problem sind nicht Informationslücken, sondern Informations-Overkill. Die Kunst nicht nicht das Hinzufügen von Informationen (der Code ist schon seine eigene vollständige Doku!), sondern das Entscheiden, welche man wegläßt.
@Nop >Nur leider sind die Callgraphen zur Doku ziemlich ungeeignet. Weil dann >dokumentiert ist, wer was aufruft, aber nicht das Entscheidende: unter >welchen Umständen. Wie soll denn ein Programm, das einen Text liest, feststellen wann welche Verzweigung greift? Wie soll ein Programm, das den Ablauf in einer realen Anwendung beobachtet, feststellen, ob eine Verzeigung nur Sonntagnachmittag um 9 Uhr greift oder der Normalfall ist. Wie willst Du bei einem Programm, das sich mit den Verzweigungen beschäftigt, bei dessen Ausgabe, DEINEN Abzweig, in den hunderten von Verzweigungen finden?
Das Stichwort lautet Parser. Aber das was Du suchst, wird es wohl nicht geben. Das wäre viel zu komplex (auch in der Ausgabe) - so dass es nichts bringen wird. Ich habe mal (vor langer Zeit) Pseudocode in Flussdiagramme umgesetzt (meine Dipl.-Arbeit :- ) ) - auf der relativ abstrakten Ebene macht das zumindest grafisch noch Sinn.
> Gibt es Freeware oder Tools die ihr dafür empfehlen könnt?
1 | $ make docs |
2 | : |
3 | $ xdg-open docs/Index.html |
Sebastian S. schrieb: > Wie soll denn ein Programm, das einen Text liest, feststellen wann > welche Verzweigung greift? Das schrieb ich bereits: gar nicht. "Dazu muß man aber inhaltlich verstehen, was wichtig ist und was nicht, und das können Computerprogramme nicht."
Sebastian S. schrieb: > Wie soll denn ein Programm, das einen Text liest, feststellen wann > welche Verzweigung greift? Dir ist aber der Sinn eines Flowcharts schon bekannt? Es wird - wie im darauf basierenden Programm - definiert, unter welchen Bedingungen welche Verzweigung ausgeführt wird. Auf Deine Frage bezogen: Der "Inhalt" der IF-Anweisung ist die Bedingung für die Verweigung.
Alex schrieb: > Ich habe mich gerade gefragt, ob es eine "einfache" Möglichkeit gibt > mein inzwischen ziemlich komplexes (viele Zeilen) C Projekt automatisch > in eine Rohfassung eines Flow-Charts zu übersetzen. Das ist ja nun > sicher ein Problem das jeder, der mehr oder weniger Programmiert und > danach dokumentieren will schon einmal hatte, Ehrlich gesagt, nein. Daher wirst du auch nicht viele Tools finden. Kennst du den doofen Spruch "Wer Ordnung hält ist nur zu faul zum Suchen"? Der gilt umgekehrt auch für das Programmieren. Wer keine Ordnung hält, der muss halt suchen. Wer keine Lust hat zu Suchen sollte besser Ordnung halten. Ordnung im Code hält man unter anderem durch Struktur, Konsistenz, Modularisierung. Ordnung kann man auch nachträglich in Code bringen. Das nennt sich dann Refactoring. Für C gibt es mittlerweile ein paar Refactoring-Tools (Eclipse CDT hat ein paar einfache eingebaut), aber das Meiste muss man in C immer noch von Hand machen. Ach ja, Refactoring ist nicht das Ziel, sondern der Weg zu Ordnung. Refactoring ohne Sinn und Verstand nützt gar nichts.
Danke! Ja, ich halte meinen Code schon für weitgehend gut dokumentiert und übersichtlich. Aber nichtsdestotrotz ist es ein Riesenprojekt... und für Leute die sich einarbeiten sollen wäre eine Übersicht schön, deshalb meine Hoffnung auf ein Programm, das mir zumindest Teile der Code-To-Flowchart-Arbeit abnimmt =)
Alex schrieb: > deshalb > meine Hoffnung auf ein Programm, Na, dann bin ich aber sehr gespannt, welche Erfahrungen Du mit Crystal... machen wirst. Bitte berichte ...
Alex schrieb: > Danke! > Ja, ich halte meinen Code schon für weitgehend gut dokumentiert und > übersichtlich. Aber nichtsdestotrotz ist es ein Riesenprojekt... und für > Leute die sich einarbeiten sollen wäre eine Übersicht schön, deshalb > meine Hoffnung auf ein Programm, das mir zumindest Teile der > Code-To-Flowchart-Arbeit abnimmt =) Warum erstellst du dann nicht einfach von Anfang an dein Programm mit einem Flowchart to Code Programm ? Vorteile: -> Dein Flowchart ist die Basis für deinen Code -> Der Code generiert sich nach deinem FlowChart -> Du erstellst das Flowchart mit deiner gewählten Programmiersprache -> Compilierst es mit deinem Compiler -> Erstellst Bitmaps deiner allen möglichen Möglichkeiten im Programm -> Der Code steht dir und anderen zur Verfügung -> Das Flowchart stützt dich bei der Dokumentation Nachteil: -> Du musst dein Programm von Anfang an per Flowchart erstellen
prof.coder schrieb: > Warum erstellst du dann nicht einfach von Anfang an dein Programm > mit einem Flowchart to Code Programm ? Weil AVR Studio mit ASF der Ausgangspunkt des Projekts war. ;)
Alex schrieb: > prof.coder schrieb: >> Warum erstellst du dann nicht einfach von Anfang an dein Programm >> mit einem Flowchart to Code Programm ? > > Weil AVR Studio mit ASF der Ausgangspunkt des Projekts war. ;) Dann überführe es doch in ein Flowchart to Code Programm, keiner kennt den Code besser wie du. Und dein Projekt ist in jedem Bereich visualisierbar, auch in deinen "xxl if cases" oder was auch immer.
Nop schrieb: > (der Code ist schon seine eigene vollständige Doku!) Das ist in der Realität eher selten der Fall. Wenn man selbstsprechende Namen für Funktionen, Variablen usw. verwendet und die Funktionen schön klein und übersichtlich hält, mag das hinhauen. Freilich auch eher dann, wenn das Gesamtprojekt noch eine überschaubare Größe hat. Bei einem Projekt mit Millionen von Zeilen Code will ich mal denjenigen sehen, der sich den ganzen Sourcecode durchliest ;-) Sich selbst dokumentierender Code ist nicht die Regel, sondern die Ausnahme. Leider.
:
Bearbeitet durch User
Mark B. schrieb: > Nop schrieb: >> (der Code ist schon seine eigene vollständige Doku!) > > Das ist in der Realität eher selten der Fall. Nein, das ist in der Realität immer der Fall. Das Problem ist, dass mit der vollständigen Doku keiner was anfangen kann. Es müssen (wie Nop schon schrieb) Details weggelassen werden und das Wesentliche klarer formuliert werden. Darum funktioniert weder C_to_ Flow noch Flow_to_C in der Praxis wirklich gut. Was gut funktioniert ist z.B. Mathematische_Ausdrücke_To_C oder Spezial-Notation_to_Spezial-C.
prof.coder schrieb: > Warum erstellst du dann nicht einfach von Anfang an dein Programm > mit einem Flowchart to Code Programm ? weil das nur dann sinnvoll ist, wenn die Modellierung in diesem Flowchart erfolgt (incl. Simulation etc.) und nicht nur das Zeichnen. Das geht z.B. mit Matlab/Simulink/Stateflow und macht meist nur eingeschränkt Sinn. Z.B. bei Mathematik-lastigen Anwendungen oder einfachen Statemaschines. Bei vielen realen Aufgaben bricht man sich aber dabei die Finger.
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.