UML - Buzzword für Manager?
-
ich finde uml schon nützlich um sich und anderen was klar zu machen. Code generieren ist auch nett. Wichtiger find ich aber noch, sich das Diagramm aus dem Code generieren zu lassen. Das macht mir doxygen ganz nett.
Zum ganze modell-driven-design zeug, würd mich interessieren, ob das wirklich irgendwo erfolgreich und in großem Stil eingesetzt wird. Meine Meinung zum Nutzen ist zwiespältig, insbesondere kenn ich aber auch niemanden konkret (oder in nem Forum, außer irgendwelche Leute die in irgendwelchen Magazinen irgendwelche Artikel schreiben) der sagt, dass das in Seiner Firma gemacht wird und der ne echte Meinung dazu haben kann.
-
JaJa schrieb:
Aber mit nem >100 Klassen UML Diagram auf DIN A0 in Schriftgröße 10 ausgedruck, behältst du den Überblick.
Ja - dank der Möglichkeit, dass es sowas wie packages gibt, hab ich selten mehr als 10 Klassen auf einem Diagramm gleichzeitig. Komponentenstrukturdiagramme können zudem bei größeren Projekten auch den groben Umriss zeigen und Abhängigkeiten von Packages kann man auch sehr schön darstellen.
Vernünftige Case-Tools wie Together können das auch wunderbar intuitiv ineinanderschachteln, so dass man prima einzelne Diagramme durchgucken kann.zur MDA: ich befasse mich gerade in meiner Diplomarbeit mit dem Thema, insb. mit dem Bereich Modelltransformationen wie etwa das QVT der OMG. Bin auch nicht der Meinung, dass momentan damit wirklich produktiv gearbeitet werden kann, da man einfach noch zu wenig darüber bescheid weiß. Nicht zuletzt weil es neben dem OMG Ansatz zich andere parallele Ansätze gibt (ATL, XDE (Rose), MOLA,...) und ich entwickel gerade auch wiederum nen parallelen Ansatz der Ähnlichkeiten zum QVT hat, aber ohne ne eigene Transformationssprache nutzen zu müssen. Wir benutzen zum imperativen transformieren einfach Java (um die Regeln zu definieren) und ne eigene entworfene Patternsprache um Objekte aus dem Quellmodell zu matchen sowie ne zusätzliche Sprache um Regelanwendungsstrategien entwerfen zu können... - das ganze in nem Java-Framework. Die Patternsprache und die RuleStrategy-Sprache sind übrigens beides DSLs die wiederum in einem recht guten eigenen DSL-Framework entwickelt wurden (zum Thema: wann benutzt man dsls
).
Ich halte die Verwendung von Frameworks für Transformationen für besser, als eigene Sprachen zu Verwenden, da der Aufwand für das Erlernen der jeweiligen Sprache in keinem guten Verhältnis zum Nutzen steht. Man kann zwar evtl. sogar sehr schön deklarativ Regeln entwerfen mit Hilfe der OCL - hat aber dafür doch recht viele Einschränkungen in der Mächtigkeit der Ausdrücke bzw. hat ganz schön mit der OCL selbst zu kämpfen... sprich - sehr aufwändig! und bislang gibts ja kaum Tools die QVT überhaupt umsetzen. Together hat eine sehr rudimentäre Umsetzung davon... bin aber auch nicht wirklich begeistert... finde mein Framework persönlich viel intuitiver - man versteht halt einiges sehr viel schneller weil die zugrundeliegende Sprache bekannt ist.
ModelToCode Generation - was man auch der MDA zuordnen mag - ist ja durchaus schon nen relativ fester Bestandteil in einigen Entwicklungsszenarien. Siehe z.B. Rhapsody bei der Entwicklung von Embedded Systemen mit Echtzeitbetriebssystemen oder ähnliches - da braucht man einfach ne konsistente abspielbare Modellbasis und kann sich Interpretationsfehler von Entwicklern nicht leisten (siehe Flugzeigbeispiel meinerseits).Zum Thema Buzzwords: man kann es tatsächlich übertreiben. Hätte zu obigen auch noch einiges über Turing-Vollständigkeit oder transitive Hüllen schreiben können ohne aber mehr aussagen zu können
... gerade wenn man lediglich Aufzählungen von dollen Wörtern bringt, behauptet wie toll das alles ist und sich dabei nen AST (Abstract Syntax Tree) freut, was für'n toller Hecht man ist ... nunjaP.S. TOoooor!
-
kartoffelsack ausgeloggt schrieb:
Zum ganze modell-driven-design zeug, würd mich interessieren, ob das wirklich irgendwo erfolgreich und in großem Stil eingesetzt wird. Meine Meinung zum Nutzen ist zwiespältig, insbesondere kenn ich aber auch niemanden konkret (oder in nem Forum, außer irgendwelche Leute die in irgendwelchen Magazinen irgendwelche Artikel schreiben) der sagt, dass das in Seiner Firma gemacht wird und der ne echte Meinung dazu haben kann.
ich fürchte das kann dir nur der typ sagen den wir gerade verbrannt haben weil er versucht hat zu fliegen
@prof84
siehe es so - you are nothing in town until somebody says you are an asshole!
*duck weg*
-
SideWinder schrieb:
phlox81 schrieb:
Hier mal ein Beispiel wie toll UML und CaseTools eingesetzt werden können:
http://thedailywtf.com/forums/thread/86833.aspxDa muss man garnicht mehr in den Code, jeder kann einfach und schnell
den Zusammenhang erkennen, und man kann alles leicht und einfach editieren...Willst du jetzt mit Hilfe eines Eintrags bei TDWTF die Nachteile von UML aufzeigen? Ich hoffe nicht ...
Hier mal ein UML-Diagramm eines kleines Teils meines Projekts. ...um mal ein weiteres Beispiel zur allgemeinen Belustigung zu bringen.
Ich muss dazu sagen, dass es sehr kompakt ist. ...das UML-Tool, das ich nutze bietet auch andere, nicht so kompakte, Darstellungen. Die sind teilweise übersichtlicher. ...ich habe an dem Diagramm sogar schon was entdeckt, wo ich nochmal im Code nachgucken sollte, weil vielleicht ein kleiner Design-Fehler gemacht wurde. ...offensichtlich kann man also bestimmte Dinge aus solchen Diagrammen erkennen.
-
kartoffelsack ausgeloggt schrieb:
Zum ganze modell-driven-design zeug, würd mich interessieren, ob das wirklich irgendwo erfolgreich und in großem Stil eingesetzt wird. Meine Meinung zum Nutzen ist zwiespältig, insbesondere kenn ich aber auch niemanden konkret (oder in nem Forum, außer irgendwelche Leute die in irgendwelchen Magazinen irgendwelche Artikel schreiben) der sagt, dass das in Seiner Firma gemacht wird und der ne echte Meinung dazu haben kann.
Dadurch, dass uml durch jede größere Geschäftsetage geistert, gibts da einige. BMW zum Beispiel hat nen eigenes Vorgehens-Model entwickelt.
IBM ist auch ganz groß dabei..
-
Gregor schrieb:
Hier mal ein UML-Diagramm eines kleines Teils meines Projekts. ...um mal ein weiteres Beispiel zur allgemeinen Belustigung zu bringen.
(...)
Schön zu sehen, dass es hier offenbar doch Leute gibt, die UML produktiv einsetzen. Bei den vielen negativen Meinungen bisher bin ich echt stutzig geworden, wie die Leute den Überblick behalten bei großen Projekten.
-
DocJunioR schrieb:
Dadurch, dass uml durch jede größere Geschäftsetage geistert, gibts da einige. BMW zum Beispiel hat nen eigenes Vorgehens-Model entwickelt.
IBM ist auch ganz groß dabei..Ja, von BMW hab ich auch schon so ein Plakat-UML-Diagramm gesehen und ich glaub es war noch ne kleinere Schriftgröße als 10.
Gibts von den ganzen großen Frameworks (Java, MFC, .NET...) auch ein UML Diagramm? Ne richtige Doku sagt doch viel mehr aus als so ein UML Diagramm. Bei diesen Diagrammen sieht man doch nur wie was zusammen hängt, aber nicht was dinge machen, dazu muss man doch die Doku oder den Code selbst lesen.
Euer Spamfilter is noch nicht so toll
-
byto schrieb:
Gregor schrieb:
Hier mal ein UML-Diagramm eines kleines Teils meines Projekts. ...um mal ein weiteres Beispiel zur allgemeinen Belustigung zu bringen.
(...)
Schön zu sehen, dass es hier offenbar doch Leute gibt, die UML produktiv einsetzen. Bei den vielen negativen Meinungen bisher bin ich echt stutzig geworden, wie die Leute den Überblick behalten bei großen Projekten.
Oh, nein, sorry. Nicht, dass Du mich falsch verstehst: Ich setze UML momentan eigentlich gar nicht ein. Das Projekt, aus dem da ein kleiner Teil als UML-Diagramm dargestellt wurde, ist privater Natur. Mit anderen Worten: Ich bin momentan der einzige, der darauf Zugriff hat und der von dem Design betroffen ist. Momentan ist das Projekt aber mit so um die 175 Klassen noch relativ überschaubar: Das Design habe ich somit größtenteils im Kopf, dafür brauche ich überhaupt gar kein Diagramm. Wenn ich an einer Stelle irgendein Design-Detail nicht mehr weiß, dann reicht mir praktisch auch ein scharfer Blick auf den Code und innerhalb von 5 Minuten ist mir das wieder klar. Ein UML-Diagramm würde ich als Grundlage nutzen, wenn ich jemand anderen in das Design einweisen müsste. ...einfach, um das Design bei der Erklärung auch vernünftig "zeigen" zu können. Möglicherweise wären UML-Diagramme auch hilfreich, wenn das Projekt noch deutlich wächst, weiß nicht.
...eigentlich wollte ich nur mal so ein UML-Tool ausprobieren, das ich wohl demnächst immer - in meine bevorzugte IDE integriert - zur Verfügung haben werde. Ergebnis: Es ist noch ziemlich buggy, aber das wird schon!
Ich weiß noch nicht, ob ich in Zukunft deutlich mehr UML benutzen werde. Wenn dieses Tool in Zukunft besser nutzbar ist und stärker in die IDE integriert ist, könnte das durchaus der Fall sein.BTW: Interessant ist auch, dass in solchen Klassendiagrammen bestimmte Klassen plötzlich eine viel stärkere Rolle zu spielen scheinen, als sie es letztendlich tun. In dem Diagramm da oben erscheint mir zumindest die Klasse "EdgeHandler" als ziemlich zentral (auf den ersten Blick). Letztendlich ist das aber nur eine Klasse, die überall so nebenbei benötigt wird und keine sehr wichtige Aufgabe hat. ...vom Design her ist sie schon gar nicht als "zentral" einzuordnen. Aber das hängt wohl auch damit zusammen, wie man so ein Diagramm anordnet. Wie schon gesagt: Die Anordnung auf dem Diagramm da oben ist das Resultat der automatischen Generierung. Da steckt eigentlich keine Arbeit drin.
-
Also schrieb:
Gibts von den ganzen großen Frameworks (Java, MFC, .NET...) auch ein UML Diagramm? Ne richtige Doku sagt doch viel mehr aus als so ein UML Diagramm. Bei diesen Diagrammen sieht man doch nur wie was zusammen hängt, aber nicht was dinge machen, dazu muss man doch die Doku oder den Code selbst lesen.
Also da hast du UML zum Einen falsch verstanden und zum Zweiten siehst du es nicht richtig.
UML soll Dokumentationen nicht ersetzen sondern ergänzen. UML dient dazu, die Zusammenhänge zwischen Komponenten, Klassen, etc. zu verdeutlichen.
Ansonsten noch was: Wenn deine Funktionsnamen nicht annähernd den Sinn der Funktion wiedergeben, solltest du drüber nachdenken, ob nicht Maler nen sinnvollerer Beruf für dich wäre als Programmierer..
-
Solange man alleine an einem Projekt arbeitet, ist das ja auch noch nicht so dramatisch. Aber sobald sich ein Projekt auf mehrere Entwicklerteams aufteilt, spätestens dann ist der Nutzen imo nicht von der Hand zu weisen. Klar, wenn man alleine arbeitet, dann reicht auch der Blick in den Code, falls man mal vergessen hat, wie ein gewisses Subsystem aussieht oder wie irgendwas funktioniert. Da man den Code ja irgendwann selbst geschrieben hat, steigt man da auch recht schnell wieder durch. Aber sobald es um Programmteile geht, die Dritte entwickeln, dann hörts doch oft schon auf und man ist froh um jedes Diagramm. Zumindest geht es mir so.
-
dito @byto
-
DocJunioR schrieb:
UML soll Dokumentationen nicht ersetzen sondern ergänzen. UML dient dazu, die Zusammenhänge zwischen Komponenten, Klassen, etc. zu verdeutlichen.
Ansonsten noch was: Wenn deine Funktionsnamen nicht annähernd den Sinn der Funktion wiedergeben, solltest du drüber nachdenken, ob nicht Maler nen sinnvollerer Beruf für dich wäre als Programmierer..
Genau das ist es doch. Das UML Diagramm funktioniert, weil die Namen der Klassen aussagen, was die Klasse macht. Die einzige Zusatzinformation ist der Zusammenhang der Klassen, was aber ohne Beschreibung auch fast nix bring.
Und ich kann auch den Code bzw. die Klassen der anderen (Java, MFC) verstehen ohne so ein Diagramm.
Aber wieso bekommt man von größeren Frameworks eigentlich kein UML Diagramm zusehen? Haben die etwa keines?
-
Also schrieb:
Genau das ist es doch. Das UML Diagramm funktioniert, weil die Namen der Klassen aussagen, was die Klasse macht. Die einzige Zusatzinformation ist der Zusammenhang der Klassen, was aber ohne Beschreibung auch fast nix bring.
Nicht wirklich. Du beziehst Dich offenbar auf Klassendiagramme und die zeigen Dir nur die Struktur der Klassen und nicht, was diese Klassen machen. UML Diagramme zeigen Dir nix anderes als was der Code Dir auch sagt. Aber es ist halt eine andere Sichtweise. Du siehst z.B. grafisch, zwischen welchen Klassen es Assoziationen gibt, wie die Kardinalitäten sind etc pp. Das siehst Du auch, wenn Du in den Code guckst klar. Aber im Diagramm ist es u.U. übersichtlicher.
Und ich kann auch den Code bzw. die Klassen der anderen (Java, MFC) verstehen ohne so ein Diagramm.
Aber wieso bekommt man von größeren Frameworks eigentlich kein UML Diagramm zusehen? Haben die etwa keines?
Es geht ja weniger darum, dass Du als Endnutzer eines Frameworks dieses verstehst. Vielmehr geht es darum denjenigen die Arbeit zu erleichtern, die dieses Framework entwickeln.
-
byto schrieb:
Und ich kann auch den Code bzw. die Klassen der anderen (Java, MFC) verstehen ohne so ein Diagramm.
Aber wieso bekommt man von größeren Frameworks eigentlich kein UML Diagramm zusehen? Haben die etwa keines?
Es geht ja weniger darum, dass Du als Endnutzer eines Frameworks dieses verstehst. Vielmehr geht es darum denjenigen die Arbeit zu erleichtern, die dieses Framework entwickeln.
Das sehe ich anders. Das kann auch für Nutzer des Frameworks interessant sein.
Trotzdem gibt es natürlich nirgendwo ein Klassendiagramm der gesamten Java-Standardbibliothek als zentralen Bestandteil der Dokumentation. Die besteht aus mehreren tausend Klassen und entsprechend dürfte es auch mit einem Klassendiagramm schwer sein, sich darin zurechtzufinden. ...zumal sich die meisten Nutzer dieses Diagramm nicht ausdrucken könnten. Du kannst Dir überlegen, wie groß das wäre, vermutlich könnte man damit ne Hauswand füllen.
Was es aber gibt - und was auch sinnvoll ist - sind Klassendiagramme von bestimmten - kleinen - Bereichen der Java-Standardbibliothek. Soetwas findet man in vielen Büchern. Wenn man sich in der Java-Standardbibliothek zurechtfinden möchte, wird man das eh nicht auf einen Schlag erledigen können. Stattdessn wird man sich immer wieder kleiner Bereiche dieses Frameworks vornehmen, die es dann zu verstehen gilt.
-
Ein Diagramm der gesamten Java-Bibliothek halt ich auch nicht grade für sinnvoll. Die UML-Klassendiagramme (welche übrigens nur einer von 9 verschiedenen Typen sind) sollen Beziehungen zwischen Klassen darstellen..
Da erklär mir mal einer die Beziehung zwischen Socket und JFrame.Wie dem auch sei. Es wird sich immer an Klassendiagrammen aufgehalten. Was ist mit Use-Case-Diagrammen? Komponentendiagrammen oder Sequenzdiagrammen? Da fängt der Spaß ja eigentlich an..
-
Da wollt ihr ein UML Diagramm immer, um den Überblick über ein großes Projekt zu haben, aber wenn das Projekt zu groß ist, dann taugt UML dafür nicht mehr, hmm...
Komponentendiagramm ist OK, obwohl es nicht UML sein muss, eigentlich reichen ein paar Kästchen und Verbindungslinien. Ob da jetzt Pfeile, Knuppel oder sonstwas dran sind, ist doch egal, da der Text doch mehr aussagt.
Usecasediagramm wäre oft ganz schön, aber meistens wissen die Kunden doch noch nicht so genau was sie wollen bzw. wie das dann ablaufen soll.
Sequenzdiagramme haben ein bisschen was von Struktogrammen, entweder sie sind so detailiert, dass man sich gleich den Code anschauen hätte können, oder sie sagen das aus, was man sich sowieso denken hätte können. Manchmal sind sie gut.
-
Also schrieb:
Da wollt ihr ein UML Diagramm immer, um den Überblick über ein großes Projekt zu haben, aber wenn das Projekt zu groß ist, dann taugt UML dafür nicht mehr, hmm...
Nein, im Gegenteil. Gerade bei großen Projekten ist der Einsatz von Diagrammen zur Visualisierung sinnvoll. Aber es macht halt wenig Sinn, z.B. ein Klassendiagramm des gesamten Projekts anzulegen, weil dieses sehr unübersichtlich wäre. Stattdessen macht man halt Teildiagramme der einzelnen Subsysteme oder Komponenten oder whatever. Ob man das nun mit UML oder einer anderen Modellierungssprache macht, ist im Grunde egal. Hauptsache alle Entwickler im Umkreis "sprechen die gleiche Sprache", damit es nicht zu Mißverständnissen kommt. UML ist dabei halt am weitesten verbreitet...
Komponentendiagramm ist OK, obwohl es nicht UML sein muss, eigentlich reichen ein paar Kästchen und Verbindungslinien. Ob da jetzt Pfeile, Knuppel oder sonstwas dran sind, ist doch egal, da der Text doch mehr aussagt.
Das trifft vielleicht zu, wenn man der einzige ist, der diese Diagramme dann verwendet. Sobald jemand anders diese Diagramme zu Gesicht bekommt, sollte die Sprache schon wohl definiert sein, um Mißverständnisse zu umgehen.
Usecasediagramm wäre oft ganz schön, aber meistens wissen die Kunden doch noch nicht so genau was sie wollen bzw. wie das dann ablaufen soll.
Es müssen ja nicht die Kunden sein, die Dir ihre Anforderungen in Form von Use Cases näher bringen. Im Gegenteil: DU kannst mit Hilfe von Use Cases die doch häufig Schwammig formulierten Anforderungen formalisieren und Dich somit auf einen klaren Anforderungskatalog mit dem Kunden einig werden. Deswegen sind die Uses Cases ja so schön simpel gehalten, dass sie quasi jeder verstehen kann.
Sequenzdiagramme haben ein bisschen was von Struktogrammen, entweder sie sind so detailiert, dass man sich gleich den Code anschauen hätte können, oder sie sagen das aus, was man sich sowieso denken hätte können. Manchmal sind sie gut.
Dazu habe ich ja oben schon was geschrieben. Wenn man den Code selbst geschrieben hat, dann braucht man sicherlich kein Sequenzdiagramm, um das Verständis aufrecht zu erhalten. Da kann man bei Bedarf einen Blick in den Code werfen und ist wieder auf der Höhe. Aber spätestens wenn mehrere Entwicklerteams zusammenarbeiten, dann werden diese Diagramme interessant. Sagen wir, die Subsysteme A, B und C sollen nun miteinander kommunizieren. Jedes Subsystem ist von einem anderen Team entwickelt worden. Dann kann man die Beispielabläufe wunderbar in Sequenzdiagrammen formulieren, ohne dass sich jedes Team erst durch den Code der anderen wühlen muss. Im Gegenteil: Die Implementierung der anderen braucht und soll sie gar nicht interessieren. Was interessiert, sind die Schnittstellen sowie Art und Ablauf der Kommunikation.
-
byto schrieb:
Sequenzdiagramme haben ein bisschen was von Struktogrammen, entweder sie sind so detailiert, dass man sich gleich den Code anschauen hätte können, oder sie sagen das aus, was man sich sowieso denken hätte können. Manchmal sind sie gut.
Dazu habe ich ja oben schon was geschrieben. Wenn man den Code selbst geschrieben hat, dann braucht man sicherlich kein Sequenzdiagramm, um das Verständis aufrecht zu erhalten. Da kann man bei Bedarf einen Blick in den Code werfen und ist wieder auf der Höhe. Aber spätestens wenn mehrere Entwicklerteams zusammenarbeiten, dann werden diese Diagramme interessant. Sagen wir, die Subsysteme A, B und C sollen nun miteinander kommunizieren. Jedes Subsystem ist von einem anderen Team entwickelt worden. Dann kann man die Beispielabläufe wunderbar in Sequenzdiagrammen formulieren, ohne dass sich jedes Team erst durch den Code der anderen wühlen muss. Im Gegenteil: Die Implementierung der anderen braucht und soll sie gar nicht interessieren. Was interessiert, sind die Schnittstellen sowie Art und Ablauf der Kommunikation.
Dazu gibts dann eine Schnittstellenbeschreibung, da brauch ich kein Sequenzdiagramm.
byto schrieb:
Usecasediagramm wäre oft ganz schön, aber meistens wissen die Kunden doch noch nicht so genau was sie wollen bzw. wie das dann ablaufen soll.
Es müssen ja nicht die Kunden sein, die Dir ihre Anforderungen in Form von Use Cases näher bringen. Im Gegenteil: DU kannst mit Hilfe von Use Cases die doch häufig Schwammig formulierten Anforderungen formalisieren und Dich somit auf einen klaren Anforderungskatalog mit dem Kunden einig werden. Deswegen sind die Uses Cases ja so schön simpel gehalten, dass sie quasi jeder verstehen kann.
Machst du das so oder hast du gelernt, dass man es so machen soll?
-
Ich merk schon, die Diskussion ist sinnlos. Viel Spaß weiterhin beim Programmieren.
Cheers, byto
-
