UML (mit Umbrello und C)

[dml]

Dieser Thread soll mehr ein Geplaudere sein, als eine richtige Frage.

Hallo

Nachdem ich einige Male jetzt hin und her Programmiert habe, da alle Varianten Vor- u. Nachteile brachten und mit der kontinuierlich steigenden Komplexität, auch die Übersicht über den Quellcode mehr und mehr verloren geht, habe ich mich jetzt entschieden eine UML Dastellung für das Projekt zu entwickeln.
Doch dabei gibt es leider auch ein paar kleine Probleme. Ich arbeite Prozedural mit structs, Arrays und Pointern, die denkbar schlechteste Verraussetzung für UML. Trotzdem einen Überblick über die Funktionalität zu verschaffen, schaffe ich schon und der ist besser als keinen, oder nur ihn zu beschreiben.
Doch drängt sich mir hier auch eine Grundsätzliche Frage für C++ Projekte auf. Ist zwangsweise auf Grund der starren Ordung in UML nur UML Quellcode richtig?

----
Ein wenig hebt sich die Frage natürlich selbst auf, da UML gewisse C/C++ Programmierwerkzeuge nicht darstellen kann, doch das Entität-Beziehungsdiagramm lässt keine logischen Fehler zu, ausser den selbst darin gemachten. Darf man deshalb so weit gehen zu sagen: "Wenn sich vom Quellcode nicht so ein Diagramm darstellen lässt, ist der Quellcode falsch."?

[undefined]

Na ja – ob ich jetzt dafür Umbrello heranziehen würde.

Um einen Überblick auf meine Projekte zu behalten tendiere ich eher zu Doxygen und gut Dokumentierten Quelltext.

Ich habe mal vor Jahren Umbrello getestet und schnell wieder verworfen, weil ich im Design ohnehin immer wieder etwas Ändern würde. Bei jedem meiner Projekte (egal ob php/c/c++) würde ich einiges nicht mehr so machen wie Vorher.

Ich finde Modularisierung entsteht steht immer aus den Erfahrungen einzelner Projekte heraus, ist somit ein Ständiger Lernprozess.
Das einzige was hiervon Stark abweicht wäre SQL

[anda_skoa]

Ich würde sagen dass Code dessen Struktur nicht in QML darstellbar ist nicht notwendigerweise falsch oder schlecht ist, aber vermutlich schwer zugänglich.

Wie undefined schon geschrieben hat ist Doxygen ansich ein gutes Werkzeug um die Interna von Software zu dokumentieren, aber oft gibt das eine zu hohe Detailsstufe.

In so einem Fall können QML Diagramme, besonders solche die nicht direkt die Struktur beschreiben (z.B. Sequenzdiagramme), einen zustäzliche Zugang eröffnen, der sehr hilfreich ist, wenn man lange nicht mehr an dem Code gearbeitet hat oder wenn jemand neu zur Codebasis hinzu kommt.

Ciao,
_

[dml]

Erst einmal herzlichen Dank für Euere Antworten!
Bei meinem ersten 1/2 C Programm merke ich schnell wie sehr ich es gewöhnt bin OOP in C++ zu programmieren und eigentlich auch bevorzuge. Doxygen arbeite ich mich gerade herran, Doku schön auf Englisch, ich bin halt eine sehr verwöhnter Mensch. Da braucht es noch ein wenig Zeit.
Es stimmt schon das ein selbst entwickeltes Programm am Stimmigsten ist, doch das ständige Ausbessern und Erweitern ist auch ziemlich bis extrem Zeitaufwendig, was ich so versuche zu reduzieren. Denn wirklich relevant sind meine Projekte, zu mindest zur Zeit, noch nicht. Auch wird die Einarbeitungszeit von jemand Anderen gerade bei Open Source Projekten, oder bei Teamprojekten, mit deren Größe und Komplexität immer wichtiger.
Ich werde so verfahren wie anda_skoa es auch sieht. Doxygen verwenden und dazu ein paar UML-Diagramme, ohne auf deren Vollständigkeit und unbedingten Korrektheit zu achten, merke so schon wie sehr es an OOP gebunden ist.

[anda_skoa]

Erst einmal herzlichen Dank für Euere Bei meinem ersten 1/2 C Programm merke ich schnell wie sehr ich es gewöhnt bin OOP in C++ zu programmieren und eigentlich auch bevorzuge.

Ich benutze zwar auch lieber C++, aber man darf nicht vergessen, dass OOP eine Sammlung von Konzepten ist, die großteils auch in C umgesetzt werden können.

Ciao,
_

[dml]

Ich hatte mir einmal einen Artikel zu OOP und C angeschaut. Doch letzlich blieb es für mich, das es kein OOP war, sodern der Versuch OOP in C zu realisieren. Da bin ich zu dem Entschuss gekommen, des wenn es eh nicht ganzes OOP ist lieber die gänigen Sprachmittel in C zu verwenden.
Und jetzt fliegen mir die Variablen durch die Gegend wie die Tauben auf dem Dach.