UML - Buzzword für Manager?
-
Prof84 schrieb:
http://www.sdm.de/web4archiv/objects/download/fachartikel/1/sdm_pub_os_salger_ludwig.pdf
seltsam. dein thema - aber keine verschleierung. es geht doch. mach's ihm nach.
-
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...phlox
-
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 ...
Varus schrieb:
..., aber Prof84s Heiße-Luft-Gelaber setzt noch mal einen traurigen Höhepunkt. Ohne ein Wörterbuch verstünde ich seine Aussage nicht.
Dann versuche dich in diese Richtung zu bilden, dann kannst du auch endlich dein Stück vom Kuchen abschneiden.
MfG SideWinder
-
Varus schrieb:
Gregor schrieb:
Hmmm... die meisten Aussagen von Prof84 sind IMHO verständlich, ohne dass man sich auf die "Buzzwords" einlassen muss. Zumal eine ganze Menge dieser Begriffe mehr oder weniger selbsterklärend ist. Es ist halt Prof84s Sprache, das kann man doch einfach akzeptieren.
Nein, ich finde das kann man nicht. Diese Mischsprache, die aus einer deutschen Hülle und unübersetztem Englisch besteht, kommt häufig bei jenen vor, die sich intellektuell hervortun wollen (http://de.wikipedia.org/wiki/Profilneurose).
Fachwörter haben ihre Berechtigung, wenn sie das Verständnis nicht unnötig erschweren. Nun habe ich schon Wirtschaftsinformatik studiert und wurde während dieser Zeit zur Genüge mit übelstem Denglisch konfrontiert, aber Prof84s Heiße-Luft-Gelaber setzt noch mal einen traurigen Höhepunkt. Ohne ein Wörterbuch verstünde ich seine Aussage nicht.
Gregor schrieb:
Ich finde es immer Schade, wenn eine Diskussion einen Verlauf nimmt, bei dem man sich nur noch über die Tippfehler der anderen lustig macht.
Wenn’s wenigstens nur die Tippfehler wären. Aber wenn jemand schon glaubt, er könne es sich erlauben, Sprachen zusammenrühren wie bunte Farbe und mit Schlagwörtern um sich zu werfen, so sollte dieser doch wenigstens in dem, was er tut, sicher sein. Seine Rechtschreibung lässt schon mal nicht darauf schließen.
Ich hätte bei jedem seiner Postings mindestens 2 Bullshit-Bingo Reihen vollbekommen -.-
-
SnooPed schrieb:
Ich kann mir persönlich nicht vorstellen, dass ich den Überblick über ein Framework mit >100 Klassen halten kann, wenn ich kein Klassendiagramm dazu hab, bzw. ob ich dann noch Aussagen treffen kann, ob das Produkt vom Design her vernünftig ist oder nicht. Plus ich kann mir nicht vorstellen, dass das ne Firma heute noch ohne zulässt, aber trotzdem ne QS Abteilung besitzt ;).
Aber mit nem >100 Klassen UML Diagram auf DIN A0 in Schriftgröße 10 ausgedruck, behältst du den Überblick.
-
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..
