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.

[anda_skoa]

Doch letzlich blieb es für mich, das es kein OOP war, sodern der Versuch OOP in C zu realisieren.

Ich finde es mehr eine Frage der jeweiligen Konzepte.
Vererbung und Polymorphismus brauchen Tricks, aber zum Beispiel das Zusammenfassen von abhängigen Daten in Structs und darauf operierende Methoden sind ohne jegliche Kunstgriffe möglich.

Nehmen wir als einfaches Beispiel ein 2D Rechteck.
In C++

class Rect
{
public:
  Rect() : m_x(0), m_y(0), m_w(-1), m_h(-1) {}
  ~Rect() {}

  int x() const { return m_x; }
  // usw.

  bool isValid() const { return m_w >= 0 && m_h >= 0 }

private:
  int m_x;
  // usw.
};

In C

struct Rect
{
  int x;
  // usw;  
}

// constructor helper
void rect_init(struct Rect *rect)
{
  rect->x = 0;
  rect->y = 0;
  rect->w = -1;
  rect->h = -1;
}

// constructor
struct Rect *rect_new()
{
  struct Rect *rect = (Rect*)malloc( sizeof( Rect ) );
  rect_init( rect );
  return rect;
}

// destructor
void rect_delete(struct Rect *rect)
{
  if ( rect ) free( rect );
}

// getter
int rect_x(struct Rect *rect)
{
  return rect->x;
}

int rect_isValid(struct Rect *rect)
{
  return rect->w >= 0 && rect->h >= 0;
}

Ciao,
_

[dml]

Siehst du, genau dort ist zum Beispiel wieder ein Problem, du musst extra das struct an die Funktion übergeben, wenn keine Vererbung kann das ziemlich lang werden... . Ich arbeite zwar auch mit structs anstatt class jetzt in c, doch mein Ansatz ist jetzt nicht mehr so OOP orientiert wie vorher. Die wichtigen struct Objekte werden global definiert und so habe ich Zugriff auf sie.

[anda_skoa]

Bei C++ musst du das Objekt auch angeben, auf dem die Methode ausgeführt werden soll. Der Unterschied ist lediglich in der Positionierung im Befehl.

Bei globalen Objekten und frei stehenden Funktionen braucht man das in beiden Sprachen nicht, allerdings hat man dann eine sehr starke Bindung von Funktion an eine bestimmte Instanz.
Wenn man die selbe Funktion auf eine andere Instanz ausführen möchte, muss man entweder die Funktion duplizieren oder das Objekt übergebbar machen.

Für mein Gefühl ist das der Aufwand, gleich am Anfang die Signatur der Funktion so zu gestalten, besser einkalkulierbar, als spätere Änderungen.

Für mich ist der Ansatz nur globale Objekte zu verwenden am ehesten vergleichbar mit Klassen, die nur statische Daten und statische Methoden enthalten. Und das macht man auch nur sehr selten, wenn überhaupt.

Aber Programmierung ist eben auch sehr vom persönlichen Geschmack abhängig

Ciao,
_

[dml]

Na, der this Zeiger muss nun bei einer Methode nicht mit angegeben werden.
Alle Objekte möchte ich ja auch nicht global erstellen, sondern die Wichtigen. Auch finde ich es einmal eine gute Übung nicht OOP zu programmieren, ist eigentlich auch interessant, wie man es dann lößt.

[anda_skoa]

Na, der this Zeiger muss nun bei einer Methode nicht mit angegeben werden.

Nicht in der Argumentenliste aber sehr wohl als Teil des Aufrufs:

// in C
funktion(object, parameter)

// in C++
object->funktion(parameter)

Ciao,
_

[dml]

Stimmt auch wieder.

Es mischen sich aber Objekte in die Parameterliste, wodurch sie von Diesen schwerer zu unterscheiden sind.
Bei Auto->tanken(benzin); weiß ich das die Methode tanken durch den Parameter benzin den Zustannd des Autos verändert.
Bei giessenPflanze(Pflanze, Wasser); ist das logisch, aber nicht gesichert.