UML Diagramme notwendig für gute OOP?

freakC++

Hallo zusammen,
ist es nützlich oder empfehlenswert UML Diagramme für große Klassenprojekte zu entwerfen? Ich habe das bis jetzt nie gemacht, doch nervt es mich total an solche Diagramme zu erstellen! Brauche ich das wirklich?

Vielen Dank
lg, freakC++

PS.: War mir nicht sicher, ob das Forum hier das richtige ist...

Tachyon

"Rund um die Programmierung" wäre passender.

Was heisst notwendig? Wenn Du es als übel betrachtest, dann machst Du vermutlich erst das Programm und dann gießt Du Deinen Code nachtröglich in UML-Diagramme. Das ist aber nicht Sinn des Ganzen. Normalerweise macht man sowas, bevor Codezeilen produziert werden.
Lastenheft->[Pflichtenheft <-> Scenarien-> Use Cases -> Statische und dynamische Analyse -> UML Diagramme].
UML ist zwar nicht zwingend notwendig, aber irgendwelche Äquivalente (und wenn es eine eigene Notation ist) sind für große Projekte eigentlich unabdingbar. Wenn Du es nicht benötigt hast, dann waren die Projekte wohl noch nicht wirklich groß.
UML vereinheitlicht die Notation in einem international gebräuchlichen Standard. Deine eigene Notation kannst vermutlich nur Du selbst lesen.

pumuckl

Für richtig große Projekte sind Übersichtskizzen auf jeden Fall hilfreich. Du musst nicht jede einzelne Klasse bis ins kleinste Detail ausmodellieren und es muss nicht unbedingt UML sein. Viele Designdetails werden ja doch on the fly während der Implementierung gemacht und noch mehrmals abgeändert. Aber die grobe Architektur deines Systems sollte schon klar sein und mit einer Handvoll Diagrammen dokumentiert werden, sonst kommt man schnell durcheinander.

C++ Forumbot

Dieser Thread wurde von Moderator/in Phoemuex aus dem Forum C++ in das Forum Rund um die Programmierung verschoben.

Im Zweifelsfall bitte auch folgende Hinweise beachten:
C/C++ Forum :: FAQ - Sonstiges :: Wohin mit meiner Frage?

Dieses Posting wurde automatisch erzeugt.

freakC++ schrieb:

ist es nützlich oder empfehlenswert UML Diagramme für große Klassenprojekte zu entwerfen?

Ja, später wirst du darüber glücklich sein alles übersichtlich und struktiert vor dir zu haben, statt im Source zu wühlen.

freakC++ schrieb:

doch nervt es mich total an solche Diagramme zu erstellen!

Ja, micht nervts auch manchmal

Beachte, UML ist nicht das was man in der Schule lernt, also einfach nur Klassendiagramm, da steckt nocht sooo viel dahinter. Schaust dir einfach mal an.

freakC++ schrieb:

PS.: War mir nicht sicher, ob das Forum hier das richtige ist...

Nope, eher RudP.

asc

freakC++ schrieb:

ist es nützlich oder empfehlenswert...

...eine ordentliche Projektplanung zu machen?

Den nichts anderes ist die Frage nach UML & Co. UML ist nur ein Werkzeug um Software zu planen und nach dieser Planung zu entwickeln. Und auch da muss man fragen: Bis in welchen Detailgrad geht man.

Grundsätzlich hat UML wie andere graphische Notationen auch, den Vorteil das sie auch ein Außenstehender (mit wenig anfänglicher Erklärung) lesen kann, und man sich anhand von Diagrammen auch besser im Gesamtkonzept wiederfindet. UML ist ein mögliches Werkzeug was sowohl in einer groben Vorabplanung (Skizzieren der aller wichtigsten Entitäten, ggf. mit Nennung der grundlegenden Methoden; grobe Übersicht der Beteiligten und ihrer Funktionen...) bis hin in eine "Programmierung mittels UML" (Bis ins kleinste Detail mit UML arbeiten).

Meine Erfahrungen von Firmen ist aber eher: Maximal ein Grobkonzept (das noch nicht einmal an die grundlegenden Anforderungsänderungen angepasst wird, und spätestens nach der Hälfte des Projektes mehr Unwahrheiten als Tatsachen enthält) oder auf der anderen Seite sich in den Details der Planung zu verrennen (gerade UML-Anfängern geht es häufig so) und dann mehr Zeit damit verbringen die passenden Designelemente zu finden und verstehen, als sich mit der Planung zu beschäftigen.

Ich persönlich setze (ausschließlich privat!) UML als Mittel zu Übersicht ein. Dies kann je nach Situation auf ganz hoher Ebene dienen (Im wesentlichen nur: welche Bereiche gibt es, wo kann ich - grob betrachtet - das Projekt in Untereinheiten zerlegen) oder um ein speziellen Fall zu betrachten, wo sich im Code einfach nicht aufzeigt welches vielleicht die beste Lösung ist (In der Regel eine Hand voll Klassen mit Eigenschaften/Methoden, die dank besserer Übersicht vielleicht nochmal ganz anders angeordnet werden). Für letzteres ist durchaus auch "Roundtrip-Engineering" sinnvoll - Sprich der automatische Abgleich von UML zum Code und zurück.

cu André

rüdiger

Klassendiagramme finde ich persönlich nicht so sonderlich sinnvoll, da sie einem nichts über die Interaktion aussagen. Daher finde ich sie im Designprozess nicht sonderlich praktisch, um damit Designfragen zu klären. Vielleicht sind die nützlich, um Mitarbeitern klar zu machen, welche Interfaces sie entwerfen müssen. Aber man muss dann ja eh noch spezifizieren, was genau dahinter steckt.

KasF schrieb:

freakC++ schrieb:

ist es nützlich oder empfehlenswert UML Diagramme für große Klassenprojekte zu entwerfen?

Ja, später wirst du darüber glücklich sein alles übersichtlich und struktiert vor dir zu haben, statt im Source zu wühlen.

Aber dann nimmt man doch lieber ein Klassendiagramm, welches aus dem aktuellen Sourcecode generiert wurde und keines, was man in der ersten Planungsphase mal "auf einen Zettel geschmiert" hat.

marco.b

@rüdiger: Stimme dir teilweise zu, die Relation zwischen Klassen kann man damit aber schon ganz gut vorplanen und gedanklich durchspielen. Unnötig ist hingegen das Reinhacken jedes Attributes und jeder Methode.

UML hat einen Vorteil bei der Planung: da es standardisiert ist (und sogar ein Standard zum Speicher von UML gibt) gibt es Werkzeuge die für einen Code in Sprache X aus der anfänglichen UML Planung generieren. So spart man sich doppelte Arbeit (erstellen der Diagramme und erstellen der 1:1 Abbildung in Quellcode).
Umgekehrt kann man natürlich jederzeit wieder aktuelle Diagramme aus dem Quellcode erzeugen. Oder komplexere Interaktionen zwischen Objekten sich in einem Sequenzdiagramm visualisieren lassen.
Wer also UML verteufelt hat sich nie damit befasst. Es ist ein Werkzeug wie jedes andere auch und man selbst bestimmt zu welchem Grad man es einsetzt (wenn es der Chef tut bekommt man im Gegenzug Geld - fairer Deal würde ich sagen).

volkard

freakC++ schrieb:

Hallo zusammen,
ist es nützlich oder empfehlenswert UML Diagramme für große Klassenprojekte zu entwerfen?

Nein. UML zum Planen von Projekten ist genauso dummer Unfug, wie Struktogramme zum Planen von Methoden zu nehmen. In Kreisen wie den IHK-Ausbildern ist UML deswegen beliebt, weil die einheitlichen Prüfungen in 6 Sprachen erfüllt werden könnten und die Prüfer peinlicherweise meistens nur eine oder zwei lesen können.

freakC++ schrieb:

Ich habe das bis jetzt nie gemacht, doch nervt es mich total an solche Diagramme zu erstellen! Brauche ich das wirklich?

Dein Gefühlt trügt Dich nicht. Du brauchst UML nicht.

UML hat einen völlig anderen Sinn, als damit Projekte zu planen. Es ist zum Dokumentieren da. Zum Beispiel kann ich in Pseudocode/Bildchen/Abschätzungen/Prototypen ein Projekt planen und dann die Planung als Auftrag per UML (zum Beispiel nur Klassendiagramme und völlig unzureichende Beschreibung des Zwecks) an 128 Programmiersklaven verteilen. Und ich kann damit leichter 1250 Seiten Programmdokumentation ausdrucken, als wenn ich versuchen würde, etwas hilfreiches zu tun.

knivil

Andere Namen: Useless modeling languages, unwanted modeling language. Zu stark an OOP-Modell von Sprachen wie Java, C++ und Co angeleht. Selbst Templates haben es schwer, ganz zu schweigen von type classes in Haskell. Viele Konzepte, die nicht in Java enthalten sind, werden einfach nicht erfasst. So dass man auf Teilsystemebene erst ansetzen kann. Auch ist die graphische Notation sehr wirr. Wenn ich mir so die Beispiele bei Wikipedia (en) ansehe, gehen die vielleicht noch. Aber was bei grossen Sachen? Mein Favorit ist das composite structure diagram des FibonacciSystems.

asc schrieb:

freakC++ schrieb:

ist es nützlich oder empfehlenswert...

...eine ordentliche Projektplanung zu machen?

UML != Projektplanung

asc

knivil schrieb:

asc schrieb:

freakC++ schrieb:

ist es nützlich oder empfehlenswert...

...eine ordentliche Projektplanung zu machen?

UML != Projektplanung

Aber ein Mittel (von vielen) um diese umzusetzen - wobei es nur eine Darstellungsform ist (Und wie ich auch schon gesagt habe, durchaus die Gefahr besteht in unnötige Details zu verlieren).

knivil schrieb:

...Zu stark an OOP-Modell von Sprachen wie Java, C++ und Co angeleht.

Logisch, UML ist vor allem vom Objektorientierten Ansatz bestimmt. Das ist aber jedem klar der sich Anschaut welchen Ursprung die UML hat.

knivil schrieb:

Selbst Templates haben es schwer...

Sofern es nicht in die Komplexität der Template-Metaprogrammierung von C++ geht, gibt es Templates in UML (ich glaube ab UML 2).

freakC++ schrieb:

Hallo zusammen,
ist es nützlich oder empfehlenswert UML Diagramme für große Klassenprojekte zu entwerfen? Ich habe das bis jetzt nie gemacht, doch nervt es mich total an solche Diagramme zu erstellen! Brauche ich das wirklich?

Ne, so n diagramm bringt kaum was. Ordentliche Klassen und Funktionsnamen bringen z.B. viel mehr.

rüdiger schrieb:

Aber dann nimmt man doch lieber ein Klassendiagramm, welches aus dem aktuellen Sourcecode generiert wurde und keines, was man in der ersten Planungsphase mal "auf einen Zettel geschmiert" hat.

Ja, das stimmt. Habe mich nicht ganz sauber ausgedrückt.

asc

zusammen schrieb:

Ne, so n diagramm bringt kaum was. Ordentliche Klassen und Funktionsnamen bringen z.B. viel mehr.

Dann gratuliere ich dir für deinen genialen Überblick auch bei Projekten mit sehr vielen Sourcedateien/Klassen, gerade wenn auch etliche komplexe Fälle in der Anwendung sind...

Ich bin kein Fürsprecher für komplexe UML-Diagramme, aber sie helfen die Komplexität durch bessere Übersicht zu reduzieren. Und nicht selten hilft ein anderer Blick auf die Entwicklung um Fehler im Design bereits im Vorfeld zu vermeiden (auch bevor noch die erste Zeile Code geschrieben wurde).

knivil

Logisch, UML ist vor allem vom Objektorientierten Ansatz bestimmt. Das ist aber jedem klar der sich Anschaut welchen Ursprung die UML hat.

Und warum schimpft es sich dann unified ... und warum heisst es dann modeling, wenn es ungeeignet fuer Modelierung im Vorfeld ist ... und warum heisst es dann language, wenn es gar nicht den Anspruch erhebt, das geschriebene Wort zu ersetzen ...

volkard

knivil schrieb:

Logisch, UML ist vor allem vom Objektorientierten Ansatz bestimmt. Das ist aber jedem klar der sich Anschaut welchen Ursprung die UML hat.

Und warum schimpft es sich dann unified ... und warum heisst es dann modeling, wenn es ungeeignet fuer Modelierung im Vorfeld ist ... und warum heisst es dann language, wenn es gar nicht den Anspruch erhebt, das geschriebene Wort zu ersetzen ...

Java erhebt auch den Anspruch, eine Programmiersprache zu sein.
Die Linke erhebt den Anspruch, eine Partei zu sein.
Aber ub es sinnvoll ist, sowas zu nehmen, ist eine ganz andere Sache und darauf wurde geantwortet.

Bashar

knivil schrieb:

Und warum schimpft es sich dann unified ...

Weil es den Anspruch hat, die ca. 100 OO-Notationen aus den 80ern und frühen 90ern zu ersetzen.

und warum heisst es dann modeling, wenn es ungeeignet fuer Modelierung im Vorfeld ist ...

Ist es? Sagt wer?

und warum heisst es dann language, wenn es gar nicht den Anspruch erhebt, das geschriebene Wort zu ersetzen ...

Das ist eine alberne Frage.

pointercrash**

Ist ungefähr wie die Frage:

Ist ein Bidet notwendig für gutes Kacken

Ich brauch' weder UML noch Bidet, für andere mag es unverzichtbar sein. Für reine Dokumentationszwecke (jetzt mein' ich nur UML ) scheint's mir zu umständlich und für den Vollentwurf sowieso. Mag aber auch auf meinen Tätigkeitsbereich zurückzuführen sein und es spielt an anderen Stellen seine Stärken aus.
Ich hab' z.K.g, daß es das gibt und beiseite gelegt.

pointercrash() schrieb:

Mag aber auch auf meinen Tätigkeitsbereich zurückzuführen sein und es spielt an anderen Stellen seine Stärken aus. Ich hab' z.K.g, daß es das gibt und beiseite gelegt.

schau mal hier: http://embeddedforecast.com/UML_for_C_Developers.pdf