Hallo Leute! Da wir zur Zeit im Fach Softwareentwicklung Struktogramme durchnehmen (neben den ganzen "Softwareentwicklungsprozessgeschichten") habe ich folgende Idee. Ich möchte mir ein Programm schreiben, welches aus dem C-Code ein Struktogramm erstellt. Dabei dachte ich an eine Dynamische Grafikerzeugung mittels SVG (Skalierbare Vektorgrafik). Allerdings habe ich ein Problem, wie ich den C-Code sozusagen nach bestimmten Schlüsselwörtern parse, woraufhin dann das jeweilige Struktogramm-Element erzeugt werden soll. Zum Beispiel das Erkennen von Funktionen. Wie beschreibe ich zum Beispiel: "suche nach int oder char oder void oder [Datentyp - Rückgabewert], dann suche nach einem beliebig langen String [Funktionsname] und dann nach einer klammer mit darin beliebig viel enthaltenen int, float, char [Datentypen] gefolgt von einem beliebig langen String [Argument-x] und einer Klammer" Wisst ihr was ich meine? Das Programm könnte ebenfalls in C oder VB oder Perl geschrieben werden. Ich denke die Wahl der Programmiersprache zum Schreiben des Programms ist nicht relevant, da der "Parser" überall der Gleiche Aufwand sein wird. Vielleicht könntet ihr mir helfen. Danke!
noch als kleiner Hinweis: Das Ganze sollte natürlich mehr als eine Programmierübung für mich als ein verwendbares und total ausgeklügeltes Tool zu betrachten sein. Somit beschränke ich mich auch nur auf 'prozedurale Programmierung', sprich ohne OOP mit Klassendiagrammen etc.
Google mal nach UML, es gibt schon haufenweise Tools die sowas machen. Zu meiner Zeit z.B. "Rational Rose". Kostenlos z.B. "Umbrello", hab da grad mal zum Testen ein paar C++ - Files importieren lassen, sah gut aus.
und wenns zum Selbermachen ist: Lager den Graph-Generierungs-Teil doch einfach in graphviz aus. Das macht die ganze Layout-Geschichte und SVG/PNG/XXX-Ausgabe. Dein "Parser" muss praktisch nur noch den Call-Graphen als einfaches Text-File im Graphviz-Format exportieren, fertig™.
Markus S. schrieb: > Das Programm könnte ebenfalls in C oder VB oder Perl geschrieben werden. > Ich denke die Wahl der Programmiersprache zum Schreiben des Programms > ist nicht relevant, da der "Parser" überall der Gleiche Aufwand sein > wird. Das ist ein grober Irrtum. Der Produktivitätsunterschied zwischen C und Perl für solche Aufgaben dürfte leicht bei einem Faktor 10 liegen... Davon abgesehen, gibt es Parsergeneratoren seit mehr als 40 Jahren... Und Struktogramme sind auch schon längst überholt. f.
Franz P. schrieb: > Und Struktogramme sind auch schon längst überholt. jep struktogramme bringen genau gar nix. sie sind (auch von ungeübten/fachfremden Personen) weder einfacher zu lesen als pseudo- oder c-code noch bringen sie mehr Informationen rüber.
Vlad Tepesch schrieb: > Franz P. schrieb: >> Und Struktogramme sind auch schon längst überholt. > > jep struktogramme bringen genau gar nix. Zumindest in der Form wie sie der TO einsetzen will: Ich habe C Code und will ein Struktogramm In der umgekehrten Richtung sieht die Sache etwas besser aus. Struktogramme erlauben dem Anfänger seine Lösungsidee in einer strukturierten Art und Weise zu formulieren ohne sich gleich in den Details eine Programmiersprache zu verheddern. Der große Nachteil von Struktogrammen: Sie sind nur schwer und mit viel Aufwand zu ändern. Wie du schon angesprochen hast, geht das mit Pseudocode viel einfacher. Das Problem bei Pseudocode: Gerade Anfänger stecken zuviel Aufwand rein, indem sie versuchen ihren Pseudocode wie den tatsächlichen Code aussehen zu lassen und dann verlieren sie sich erst recht wieder in irrelevante Syntax-Details. > Wisst ihr was ich meine? Ja. Aber das funktioniert so nicht wie du dir das vorstellst. Um so etwas machen zu können, musst du schon ein wenig Ahnung von Themen wie Compilerbau (im speziellen: wie schreibe ich sinnvoll einen Syntaxparser) und den dort benutzten Techniken haben. Mit Rekursionen solltest du auch nicht mehr auf Kriegsfuss stehen und dynamische Datenstrukturen (im speziellen Bäume) dürfen für dich auch kein Fremdwort sein.
Macht Ihr da noch Nassi-Shneiderman-Diagramme ? Da kenn ich tatsachlich noch ein par DOS-Basierte Konverter aus der Urzeit... Solangs nicht objektorientiert ist, geht das ja noch - aber sonst würde ich schon dem OO Entwicklungszyklus OOA-OOD-OOP folgen ...
Andreas schrieb: > Macht Ihr da noch Nassi-Shneiderman-Diagramme ? hört sich danach an. Das spricht eigentlich schon fast dafür die Uni zu wechseln. zumindest aber, in die Vorlesung so wenig Energie, wie möglich zu investieren und stattdessen auf eigene Faust zu recherchieren und sich OOD aneignen
Vlad Tepesch schrieb: > Das spricht eigentlich schon fast dafür die Uni zu wechseln. Was für'n Quatsch? Der Themenersteller hat doch von C-Code geschrieben. Lasst mal Euren OOP-Revolver für einen Moment stecken.
Franz P. schrieb: > Markus S. schrieb: >> Das Programm könnte ebenfalls in C oder VB oder Perl geschrieben werden. >> Ich denke die Wahl der Programmiersprache zum Schreiben des Programms >> ist nicht relevant, da der "Parser" überall der Gleiche Aufwand sein >> wird. > > Das ist ein grober Irrtum. Der Produktivitätsunterschied > zwischen C und Perl für solche Aufgaben dürfte leicht bei einem > Faktor 10 liegen... Das kommt darauf an, wie gut derjenige die Sprachen kann. Wenn man C gut kennt und noch lex/yacc verwendet, kann man damit auch schneller am Ziel sein, als wenn man erst Perl lernen muß.
Atmi schrieb: > as was du entwickeln möchtest, gibt es schon. > > Google -> "Doxygen" vielleicht soltlest du deinen eigenen Rat mal befolgen. Doxygen erzeugt Dokumentation für files, funktionen, klassen, namespaces - eigentlich alle Elemente des Codes. Doxygen erstellt keine Ablaufpläne auf Codezeilenbasis. Ich vermute, das macht kein Tool, weil es einfach keinen Sinn macht Was bringt es dir, wenn du den Code Zeile für Zeile in ein Diagram überführst. Ein Tool kann nicht wissen, welche Teile Zusammen gehören und quasi eine Aktion darstellen, oder wie Feingranular dein Struktogram sein soll.
will man das trotzdem würde ich nach einem Compiler suchen, bei dem man einfach an den aus dem Code erstellten AST kommt. den könnte man versuchen soweit zurechtzustutzen, dass man ein diagramm draus machen kann. wie gesagt, ich se da kein sinn drin.
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.