UML Diagramme notwendig für gute OOP?
-
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).
-
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.
-
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
-
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.
-
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).
-
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 ...
-
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.
-
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.
-
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
-
;fricky schrieb:
schau mal hier: http://embeddedforecast.com/UML_for_C_Developers.pdf
Kannte ich schon.
pointercrash() schrieb:
Ich hab' z.K.g, daß es das gibt und beiseite gelegt.
Zum perfekten Häuslbesuch brauch' ich 'nen Bleistift, 'nen Collegeblock und 'nen Stoß Fachmagazine - dann klappt's auch mit dem OOP.
-
Ich denke es kommt auch etwas auf die Art Programm an, die man schreiben will. Wir mussten in einer Veranstaltung mal ein komplettes Projekt zuerst mit UML vorplanen. Dabei ging es aber um eine Desktopapplikation ohne viel Schickschnack mit Hilfe des MVC Muster.
Der erste Schritt war das Anwendungsfalldiagramm. Daraus konnte man dann direkt die Controller mit zugehörige Funktionen bestimmen. Im Klassendiagramm kam dann das Model dazu und man hat die Schnittstellen festgelegt, damit später jeder Funktionen schreiben konnte ohne sich dauernd absprechen zu müssen. Etwas überflüssig waren dann nur die Sequenzdiagramme, da die meisten Anwendungsfälle entweder zu simpel waren, oder sehr von der Implementierung abhängig, die bis dahin noch gar nicht bekannt war.