UML noch zeitgemäß?

Hallo an Alle,

seit geraumer Zeit versuche ich für meine Arbeit den "Königsweg" für die Erstellung eines Programmes bevor man die erste Zeile Quelltext schreibt zu finden. Schnell kam ich da auf UML. Bei näherer Betrachtung ist mir schnell klar geworden: UML kann auch zum Selbstzweck mutieren, Bücher mindestens so dick wie gängige C#-Werke, eine hohe Lernkurve und kontroverse Diskussionen über Sinn-und Unsinn darüber im Web. Liege ich nicht vollkommen falsch so hat ja auch Microsoft den Pfad der UML-Tugend verlassen, Visio Integration in Visual Studio ist irgendwie auch nicht transparent nachvollziehbar.
Deshalb bin ich mittelmäßig ratlos und frage die Profis unter euch:
Wie und mit welchen Mitteln(Werkzeugen) soll man denn nun eine neue Anwendung planen wenn man pragmatisch an die Sache herangehen möchte?

Oder das gute alte Ablaufdiagramm und dann mit dem Classdesigner weiter...

Danke für die Hilfe!
Gruß wazer317

Hallo wazer317,

ich sehe UML als Angebot, aus dem man seine eigene Auswahl trifft. Wenn man für jedes Projekt, jede Klasse, jede Methode und überhaupt an jeder Stelle immer jeden anwendbaren Diagrammtyp verwendet, den UML anbietet, ist das sicher ein Overkill.

Aber Klassendiagramme und Diagramme für Use-Cases sind sicher in den meisten Fällen nützlich. Außerdem helfen gezielt weitere Diagramme, an besonderen Stellen, z.B. ein Sequenzdiagramms bei Synchronisationssituationen oder Zustandsdiagramme bei Klassen mit Zuständen (im Sinne von Zustandsautomaten) oder Aktivitätsdiagramme bei Klassen und Methoden mit komplexerem Zusammenspiel.

herbivore

Hallo zusammen,

ich sehe UML als Schnittstelle zwischen Projektplanung und Programmierung. Da es hier zu Sprachbarrieren kommen kann ist das eine uniforme Art und Weise etwas auszudrücken.

Ich bin der Meinung, dass UML in den Anwendungsfälle, Aktivität und Ablauf die höchste Achtung verdient hat. Es spiegelt hier Teile (wenn nicht sogar vollständig) vom Pflichtenheft wider.

Ich finde, dass UML eine angenehme Kommunikationsart zwischen Software-Entwickler und Projektplanung / Management bedeutet. Dass UML auch innerhalb von Software-Entwicklern verwendet werden kann (Klassendiagramm) halte ich für nebensächlich, denn ich denke dass hier jegliche einheitliche Form der Dokumentation hierfür ausreicht.

Soll heißen, dass für mich gilt: Projektplanungsphase, wo Anforderungen und Abläufe definiert werden UML alles andere nach Vereinbarung.

Im heutigen Zeitalter von agiler Programmierung (z.B. ExtremeProgramming oder Scrums) ist es wahrscheinlich zu viel verlangt ein vollständiges Klassendesign vor der Programmierung zu erstellen. Da macht es mehr Sinn aus dem aktuellen Quellcode ein Diagramm erstellen zu lassen und hinterher zu schauen, wo eventuell Design-Schwächen vorzufinden sind.

Viele Grüße
Norman-Timo

Hallo herbivore und Norman-Timo,

ihr habt mir echt sehr gute Tipps gegeben:

ich sehe UML als Angebot, aus dem man seine eigene Auswahl trifft.

Eben einfach mutiger sein etwas wegzulassen im Dschungel der Möglichkeiten...

Im heutigen Zeitalter von agiler Programmierung (z.B. ExtremeProgramming oder Scrums) ist es wahrscheinlich zu viel verlangt ein vollständiges Klassendesign vor der Programmierung zu erstellen. Da macht es mehr Sinn aus dem aktuellen Quellcode ein Diagramm erstellen zu lassen und hinterher zu schauen, wo eventuell Design-Schwächen vorzufinden sind.

Genau so werde ich einmal angehen.
Wenn also Visual Studio/C# die Burg /Festung ist dann ist UML der Wassergraben und die Zugbrücke darüber dazu, mal bildlich ausgedrückt.

Gruß und Danke
wazer317

UML wird meiner Meinung nach nur bei großen Firmen (Industriekonzernen) genutzt.
Bei kleinen Klitschen <10-15 Mann ist UML zu teuer. 🙂

Hallo,

UML wird meiner Meinung nach nur bei großen Firmen (Industriekonzernen) genutzt.
Bei kleinen Klitschen <10-15 Mann ist UML zu teuer.

Überhaupt nicht!

Bis man es geschaft hat, ein eigenes, verständliches Dokumentations, Entwurfst und Kommunikations-Model (UML ist das alles) zue entwickeln, hat man so viel Geld verschwendet, dass ein so kleine Firma vermutlich hops gegangen ist.
Und ohne Dokumentation oder standartisierte Kommunikation verliert man Qualität, Zeit und Geld (Darüber gibts ganze Bücher, wes halb man unbedingt Dokumentieren sollte).

In einer kleinen Firma (ich sprech aus Erfahrung) ist es nicht möglich, jedes UML Diagramm zu machen, jeden Methodenfluss abzubilden und ähnliches. Aber wie schon gesagt trifft man eine Auswahl aus den Diagrammen und eine kleine Firma muss halt leider eine kleine Auswahl treffen. Diese muss dann aber auch reichten, um alle Informationen zu transportieren.

Ach ja, und wenn man dann einen neuen Mitarbeiter bekommt, muss man ihn in UML nicht einlernen, sonder da das ein Standard ist, kann man Ihm die Doku geben und sagen: "Lies." UND ER KANN ES LESEN !! 😉

Gruß
Juy Juka

Ich bin der Meinung, ein Programm (die Umsetzung) entsteht im Kopf. UML (und andere, die vllt. nicht mehr ganz so gebräuchlich sind) stellen Schnittstellen zu anderen Programmieren im Team her (jeder denkt anders, bzw. würde das Programm ganz anders umsetzen) oder stellen komplexe Prozesse abstrakt dar. Zusätzlich hat UML den Vorteil (nicht nur das es "JEDER" lesen kann), es löst das was hab ich hier eigtl. vor einem halben Jahr programmiert - Problem (bzw. kann es bei richtiger Anwendung von UML lösen). Großer Nachteil ist wie bereits schon mehrfach geschrieben worden, die Zeit.

Die Zeit ist glaub ich gar nicht so das PRoblem.
Das größere Problem ist denke ich die Einarbeitungszeit.
Jeden Mitarbeiter UML beizubringen usw. dauert auch u. kostet. Nicht jeder der informatik studiert hat, hat auch mal richtig was mit UML zu tun gehabt, kenn das ja bei mir aus der Firma, hier wird kaum UML eingesetzt u. es funktioniert auch.

Ich persönlich halte UML für absolut überflüssig, das ist so ein bisschen die eierlegende Wollmilchsau, die dann doch nichts richtig kann.

Außerdem fehlen mir für UML vernünftige Tools, insbesondere Enterprise Architect ist IMHO dermaßen überfrachtet, dass es unbenutzbar ist.

Ich halte von entsprechenden DSLs deutlich mehr und nutze dementsprechend, wenn, dann lieber die Designer in VS.

Mhm. Ich würde die Designer von VS und UML(-Tools) nicht vergleichen.
UML ist für die Dokumentation und für das Designe gedacht (nicht nur bei Softwarentwicklung) und sollte/wollte garnicht zum Implementieren verwendet werden. Die Designer im Gegensatz sind dazu da, Implementationsarbeit zu übernehmen.

Ich behaupte der Vergleich ist wie Äpfel mit Birnen zu vergleichen.

my 2 cent
Juy Juka

Ich meine die Designer aus der Team Suite, zB den Klassendesigner ...

Oh, die kenn ich dann nicht.
Ich hab an VisualDesigner und Co. gedacht.

Gruß
Juy Juka

Ich finde in der Schule war UML und die ganzen anderen Diagramme das blödeste was es gegeben hat. Hat für mich keinen Sinn gemacht. Warum auch, der Code einer kleinen Consolen-Anwendung den hatte man sich im Kopf erstellt. Team oder ein größeres Projekt mit mehreren Schnittstellen gab es nicht.

Die Einstellung von Golo und moq kann ich jetzt leider nicht mehr nachvollziehen. Selbst in einem "Team" von 2 bis 3 Leuten, macht ohne entsprechende Schnittstellen jeder was er will und zum Schluss ist man dann auf jeden sauer. Deshalb UML!

Ich weiß nicht wie du beruflich tätig bist, ich arbeite in einer kleinen Software-Schmiede (5 Festangestellte und die gleiche Zahl an freien Mitarbeitern). Wir haben ein großes Produkt mit etwa 650-700 mittelständischen Bestandskunden (+Wartungsverträge) und eine handvoll Industriekonzerne (bsp. weltweit 250.000 Mitarbeiter). Bei uns wird nur dokumentiert was komplett eigenständig vom "Hauptprogramm" ist. Beispielsweise unser Compiler-Server, unser eigenes Bugtracking-/Projektmanagement System oder halt kleine eigene Projekte die abgekapselt sind vom "Hauptteil". Ansonsten gilt bei uns Code-Dokumentation (Soll 1:3) und natürlich Arbeit mit FxCop. Es gibt feste Einteilungen in dem Team, Person A ist für Bereich A (Bsp. GUI) zuständig, Person B für Bereich B, etc. Wir sind ein festes, kleines Team. Die Personen um uns herum sind wie gesagt, entweder freie Mitarbeiter oder Praktikanten.

Am Anfang der "neu" Entwicklungszeit, als wir einen Code-Freeze hatten, fehlte uns das Geld für UML und ähnliches. Wir hatten quasi nichts! Man muss ein Produkt auf die Beine stellen, dass von der Wirtschaft anerkannt wird und gekauft wird. Die beste Dokumentation bringt nichts, wenn das Produkt quasi null Umsatz erzielt. Daher wurde der Fokus auf die reine Entwicklung/Stabilität/Messen/etc gelegt. Natürlich entstehen dadurch nun große Nachteile. Es gibt bei uns diverse Funktionen die so komplex sind, dass derzeit nicht mehr überschaubar ist, welche Faktoren direkten Einfluss haben. Wir wissen zurzeit von cirka 50 Faktoren die eine einzige Property beeinflussen kann. Intern ist es bei uns, dass so genannte "schwarze" Loch. Nur unsere BWL'ler wissen wie die Theroie funktioniert. (Was passiert bei Knopfdruck in Oberfläche XYZ -> Auswirkung auf Workflow A,B,C,D,G und X)

Das nächste Problem ist, dass viele Benutzerinteraktionen bei diesem "Teilbereich" Auswirkung auf soviele Posten hat, Faktura/SAP, Export/Import, ... alles weiterhin komplette Teilbereiche. Es sind defintiv zuviele Querverweise!

Ich bin aber froh, dass wir auf Dokumentation im Sinne von UML,Ablaufplännen und etc weggeblieben sind. Anderenfalls wären wir nämlich (laut unseren Finzanzleuten) defintiv Insolvent.

Derzeit refactoren wir die kompletten Teile, die undurchsichtig sind. Wir stoßen Tag für Tag auf neue "alte" Probleme, die wir mit der Zeit lösen.

Viele Grüße,
moq!

Also ich kann mich auch nur Golo und moq anschließen. Wir arbeiten hier im Team mit mehreren Leuten und bis jetzt haben wir ohne UML verdammt gut gelebt. Schnittstellen werden natürlich auch festgelegt und zwar durch gute alte schriftliche Dokumentationen im Textformat. Ich gebe lieber jemanden ein 20 Seiten langes Worddokument in die Hand, als ein UML Diagramm. Den Text versteht jeder, da braucht man keine Einarbeitungszeit 🙂
Und ich kann mich nicht erinnern, das auf diese Art und Weise mal was nicht lief.

Aber ich denke mal, das das ein Thema ist worüber man streiten kann. Jeder hat andere Erfahrungen gesammelt, ob positiv oder negativ. Der eine liebt UML, weil er es sein ganzes "Leben" gemacht hat. Der nächste schwört auf schriftliche Dokumentation, weil es so auch immer geklappt hat ohne Probleme.

Die Einstellung von Golo und moq kann ich jetzt leider nicht mehr nachvollziehen. Selbst in einem "Team" von 2 bis 3 Leuten, macht ohne entsprechende Schnittstellen jeder was er will und zum Schluss ist man dann auf jeden sauer. Deshalb UML!

Ich hab nicht gesagt, jeder soll machen, was er will, sondern, dass ich DSLs für passender halte als UML.

Hrm, muss zugeben habe weder Struktogramme noch UML's jemals benutzt noch den Sinn dahinter erkannt. Selbst bei Teamarbeiten bietet jeder für seine Module die passenden Schnittstellen an. Gut, kann sein das bei größeren Teamprojekten es natürlich Sinn macht die Schnittstellen via UML den anderen darzulegen.

Aber mal ehrlich, nen paar XML Kommentare die man sich durchlesen kann helfen einen schneller weiter durchzusteigen als ein UML. Ich denke es ist gut wenn man UML's lesen oder diese nachträglich durch den VS Support dafür ausdrucken und sich an die Wand pinnen kann. Aber eigentlich haben UML's mir in der Vergangenheit nur geholfen indem ich meinen Produktleiter damit leichter die einzelnen Module als ganzes aufzeigen konnte.

Ansonsten fällt mir kein Gebrauch davon ein...

Oha! Eine Anti-UML-Fraktion? Hätte nicht gedacht, dass so etwas existiert.

Also ich habe festgestellt, das UML für kleinere Projekte nicht viel unterschied zu Textdokumenten macht. Je größer und komplexer ein Projekt jedoch wird, desto ehr war ich froh, ein Übersichtsdiagramm zu haben und/oder kleine Diagramme (eventuell begleitend zu einem Text).

Also ich würde schwören, dass man mehr Zeit verliert, wenn man einen Text liest (der ja irgend wie gestalltet ist) als wenn man die gleiche Information aus einem UML-Diagramm (besser gesagt mehreren, da in einem Text vermutlich alle UML-Sichten durcheinander gewirbelt sind) zu lesen.
Aber gut, darüber könnte man wirklich streiten. Vielleicht gibts ja eine Studie dazu oder so. Egal.

Gruß
Juy Juka

[EDIT]Tippfehler[/EDIT]

Oha! Eine Anti-UML-Fraktion? Hätte nicht gedacht, dass so etwas existiert.

😁

Also ich habe festgestellt, das UML für kleinere Projekte nicht viel unterschied zu Textdokumenten macht. Je größer und komplexer ein Projekt jedoch wird, desto ehr war ich froh, ein Übersichtsdiagramm zu haben und/oder kleine Diagramme (eventuell begleitend zu einem Text).

Übersichtsdiagramme, Ablaufdiagramme und kleinere Diagramme haben wir natürlich auch. Nur halt nicht über UML abgebildet. Und das Projekt ist schon ziemlich komplex 🙂

Aber gut, darüber könnte man wirklich streiten. Vielleicht gibts ja eine Studie dazu oder so. Egal.

Eine Studie dazu würde mich allerdings auch mal interessieren.

Weis nicht, grade bei größeren Programmen finde ich ein Programmablaufdiagramm schlüssiger. Eigentlich sehe ich es so das nicht der Programmierer den Ablauf eines Programms vorgibt und somit eh kein UML vorgeben kann. Sondern das die Aufgabe vom Produktleiter ist, dieser erstellt den Programmablaufplan und der Systemarchitekt gibt vor wie z.B. das UML aussieht.

Der Programmierer geht nicht anhand des UML's vor, ihn interessiert das große ganze ja nicht - sondern kümmert sich nur darum das sein Modul vom Programmablaufplan her das erfüllt was es soll - das UML kann man dann nur verwenden wenn der Systemarchitekt selbst nicht die Schnittstellen programmiert.

Aber ich denke das hängt halt von der Struktur der Firma ab, wenn der Programmierer die Aufgaben von Systemarchitekt und (oder) Produktleiter übernimmt dann machen UML's schon ihren Sinn. Damit man das große ganze nicht aus den Augen verliert - aber eigentlich sollte das immer getrennt sein wie ich finde.

Hi,

Programmablaufplan

Also ich würde nie einen Programmablaufplan nehemen, bei dem gehen viel zu viele Informationen verloren! UML bietet da einen Diagrammtyp, der (meiner meinung nach) mehr Informationen auf gleichem Raum speicher und sogar noch einfacher zu zeichnen ist! (Sequenzdiagramm)

Aus sicht eines Programmierers ist es egal, ob man UML oder ein anderes (älteres) Diagramm nutzt. Nur sind die UML-Varianten der Diagramme meist Informativer und vor allem Kompartiebel mit allen anderen Diagrammen! (PS: Ich bin so zu sagen Systemdesigner)

@Khalid: Mhm. Und wie "verbindet" Ihr die Diagramme? Für UML gibts da ja "Regeln", aber bei den anderen Diagrammformen (ich hab was weis ich wie viele gelernt) kenn ich keine solchen Zusammenhänge zwischen Dynamischen und Statischen Diagrammen.

Gruß
Juy Juka

Und wie "verbindet" Ihr die Diagramme?

Ehrlich gesagt weis ich jetzt nicht genau, was du mit verbinden meinst. Meinst du, wenn z.B. ein Ablauf innerhalb eines Diagrammes zu komplex wird, das es auf ein zusätzliches Diagramm dargestellt werden soll? Wenn ja, dann ziemlich simpel über "Siehe Dokument XYZ".

Hallo zusammen,

irgendwie habe ich das Gefühl, dass nicht jedem bewusst ist, dass UML um einiges weitreichender als Softwaredokumentation ist. Es ist auch viel mehr als ein Klassendiagramm.

Mir ist klar, dass man aus Sicht des Programmierers am ehesten mit dem Erstellen eines Klassendiagramms konfrontiert wird, jedoch fängt UML doch viel eher an.

Nur mal, dass wir alle vom Gleichen reden, meiner Ansicht nach unterteilt sich UML in verchiedene Bereiche (angelehnt an MS Visio):
*Aktivitätsdiagramm *Kollaborationsdiagramm *Komponentendiagramm *Verteilungsdiagramm *Sequenzdiagramm *Zustandsdiagramm *Anwendungsfalldiagramm *Klassendiagramm

Ich möchte mir nun die Erklärungen im Detail ersparen. Ich möchte nur mal darauf hinweisen, wenn von UML gesprochen wird, dass hiermit alle Bereiche gemeint sein können.

UML ist meiner Meinung nach DAS Projektplanungswerkzeug. Es bietet eine allgemeine, leicht verständliche Sprache, die unmissverständlich klar ist. Ein z.B. Pflichtenheft in reiner Textform kann missinterpretiert werden und so zu einer falschen Umsetzung führen.

Je nach Einsatzgebiet sind Teilbereiche von UML interessant. Ein Softwareentwickler wird sich wohl mit Klassendiagrammen beschäftigen müssen, ein Projektleiter wohl nicht.

Anwendungsfälle werden wohl zwischen Vertrieb und Kunden ausgehandelt und müssen in eine Form gebracht werden, die auch ein Projektleiter und auch die Software-Entwickler verstehen.

Klar, ich lebe auch in der Realität. Vieles geschieht mundartlich, einiges eben Schriftlich. Aber das Ideal ist ganz klar UML.

@Golo:
was sind DSL's? Mit einer Suchmaschine wird man hier nicht glücklich, da nur Internetverbindungen zu finden sind.

Viele Grüße
Norman-Timo

Hallo norman_timo,

was sind DSL's? Mit einer Suchmaschine wird man hier nicht glücklich, da nur Internetverbindungen zu finden sind.

man wird glücklich, wenn man nach DSL vs UML sucht.

herbivore

UML ist meiner Meinung nach DAS Projektplanungswerkzeug.

Das ist bei mir Excel 😉

ich habe ehrlichgesagt noch kein pflichtenheft gesehen, das einmal ausgehandelt wurde und nicht mehr angefasst wurde.

softwareentwicklung ist ein prozess. wenn man nicht ständig mit dem kunden kommuniziert, geht es schief und das beste uml-diagramm kann einen davon nicht schützen.

klar könnte man vor der ersten zeile code alles schön planen und designen. sogar bis ins kleinste detail aber nachher reicht ein kleiner blick vom kunden und man kann den großen radiergummi nehmen.

von ein paar klassendiagrammen, sequenzdiagrammen die durch viele schichten gehen und die allerwichtigsten use-cases mal abgesehen, kann man meiner meinung nach uml in die tonne hauen.

des weiteren benutzt uml seine eigenen fremdwürter (aggregation usw...). gott wie ich diese überkomplexen ausdrücke gehasst habe. da wollte der erfinder mal wieder zeigen wieviele schalue fremdwörter er kennt.
(kommt jetzt ein bischen komisch rüber aber das ist meine meinung ^^)

ps: ich habe mal von einem konzern gehört, der alles richtig machen wollte und eine firma beauftragt hatte, vorher alles zu designen. als diese nach einem jahr ferig waren (nach angeblich einer million euro), kam während der implementierung heraus, das sie alles nochmal neu machen müssen, da sie bei der planung ein paar kleinigkeiten nicht bedacht haben.

pss: ich hasse excel^^

Hi,

@Golo Roden: Wir als Software-Entwikler sollten es besser wissen, als Excel zu verwenden. Wie oft werden wir gerufen, um ein Excel-Desaster zu retten?

@JAck30lena: Alles kann schief gehen, auch UML. OO ist ja auch nicht das all heilmittel. Natürlich muss man auch die UML-Diagramme im Entwicklungsprozess pfelgen, genauso wie alle anderen Arten der Dokumentation/Planung.... Das spricht weder für noch gegen UML.
@JAck30lena zum 2ten: Die Fremdwörter der UML sind leider nötig, da es Implementations-Unabhänig sein soll. Sonst könnte man stadt Assoziation ja Fremdschlüssel oder Property oder Referenz sagen. Die Fremdwörter muss ein Programmierer in seine "Sprache" übersetzen können. Leider. (Wobei das einige Tools ja selber können, Stichwort: Codegenerator.)

@norman_timo: Jetzt wo du es erwähnst. Es hört sich wirklich so an, als ob viele hier nur aus der sicht eines Code-Hackers (nicht beleidigend gemeint) bewerten. UML kann so viel mehr, woraus auch die meisten vorteile im gegenzug zu den anderen Arten der Dokumentation erwachsen.

Gruß
Juy Juka

Was spricht dagegen, zB Usecases oder Anforderungen in Excel abzulegen?

Hallo Golo Roden,

prinzipiell spricht da überhaupt nichts dagegen. Ich frage mich nur, warum ich mir die Mühe machen muss erst einmal Firmeninterne Excel-Vorlagen und Richtlinien zu erstellen, damit Anforderungen und Usecases in ein einheitliches Format zu bringen, wo doch UML schon als Standard benutzt werden kann.

Ich bin lediglich der Überzeugung, dass ein einheitliches und allen bekanntes Format verwendet werden soll. Ich sehe Excel in dieser Hinsicht als komplizierter, da für MSDN-Abonennten im Rahmen von Office auch Visio verfügbar ist, und damit dann ohne Zusatzbemühungen UML verwendet werden kann.

Es geht auch nicht darum alles bis ins kleinste Detail mit UML zu planen. Ich denke es herrscht hier zu sehr der Glauben, dass jeder der UML verwendet ein Planungsfetischist ist, der zunächst alles bis ins kleinste Detail planen muss, bevor er anfängt zu arbeiten.

Die Welt ist nicht schwarz oder weiß und meist fährt man am Besten, wenn man sich im Grau bewegt. Mit UML lässt sich genauso grob planen wie mündlich. Wie weit man eine Vorabplanung ausdehnt ist jedem selbst überlassen.

Meine Betonung in Sachen UML ist ziemlich schnell auf einen Punkt gebracht:
UML ist allgemein und unmissverständlich klar und kann von jedem schnell gelesen werden.

Viele Grüße
Norman-Timo

Es geht auch nicht darum alles bis ins kleinste Detail mit UML zu planen. Ich denke es herrscht hier zu sehr der Glauben, dass jeder der UML verwendet ein Planungsfetischist ist, der zunächst alles bis ins kleinste Detail planen muss, bevor er anfängt zu arbeiten.

Oh, ich glaub das nicht. Ich bin auch ein Planungsfetischist. Halt nur ohne UML.

Aber ich zitier mich nochmal selber:

Aber ich denke mal, das das ein Thema ist worüber man streiten kann. Jeder hat andere Erfahrungen gesammelt, ob positiv oder negativ. Der eine liebt UML, weil er es sein ganzes "Leben" gemacht hat. Der nächste schwört auf schriftliche Dokumentation, weil es so auch immer geklappt hat ohne Probleme.

Soll heißen, das das hier doch bitte nicht in ein Glaubenskrieg führt. 🙂

Oh, ich glaub das nicht. Ich bin auch ein Planungsfetischist. Halt nur ohne UML.

So seh ich das bei mir auch - Planung ist sehr, sehr wichtig, aber ich nehm eben ebenfalls kein UML dafür.

Ich denke, das hängt auch ein bisschen davon ab, mit wem man zusammenarbeitet - wenn man sich in einem Umfeld bewegt, das sich mit UML auskennt, why not?

Wenn man aber eh schon keinen Hang zu UML hat, und der Kunde mit UML auch nichts anfangen kann, und die persönliche, subjektive Erfahrung ist, dass man eher Storyboards runterschreibt statt Usecases zu malen - dann halt kein UML.

Wichtig ist IMHO, DASS man plant und nicht einfach drauf los legt, und nicht mit welchem Tool oder welcher Sprache man das macht. Ich schreib die Anforderungen ja auch nicht in englisch, bloß weil das im allgemeinen als sinnvoll erachtet wird 😉.

Hier stellt sich mir die Frage, wer von den Kritikern hat denn überhaupt schon mal UML WIRKLICH eingesetzt? Bzw. wer von den Kritikern kann eigentlich UML?

Alle die hier vorgebrachten Argumente habe ich schon gehört und zwar immer von Leuten die UML höchstens mal in der Schule oder im Studium hatten, aber in der Praxis nie wirklich verwendet haben.

So kann ich auch nur Argumente gegen UML von Personen gelten lassen die mit UML bereits aktiv modelliert haben - ich rede hier von Projekten und von Teams und nicht von Minitools von Einzelkämpfern, dass sich UML dafür nicht immer lohnt ist klar.

Weiterhin ist klar, dass man UML nicht exessiv nutzen brauch'. Die Detailtiefe ist völlig beliebig.

Auf meine Initiative hin wird in einigen Abteilungen meiner Firma UML eingeführt. Es ist schwer gewesen eine Akzeptanz und ein Verständnis für die Möglichkeiten von UML aufzubauen. Aber jeder den ich bisher schulen konnte ist von UML überzeugt und will es einsetzen, schon weil durch durchdachtes Modellieren Probleme und offene Fragen im Vorfeld erkannt werden und geklärt werden können.

[edit]

@Golo: Da stimme ich Dir zu, an diesem Punkt ist es egal wie, Hauptsache man tut es. Aber aus eigener Erfahrung kann ich Dir sagen, dass es mit UML leichter und schneller geht wenn man das richtige Tool hat und die Einarbeitungsphase überstanden hat. Auch lässt sich hier noch das Sprichwort anbringen: "Ein Bild sagt mehr als 1000 Worte" - das ist in diesem Zusammenhang keine leere Phrase.

Ich für meinen Teil habe knapp anderthalb Jahre UML anwenden müssen, für Klassendesign, Usecases, Activities und Sequenzdiagramme.

Ich hatte UML nicht nur im Studium, sondern auch im Rahmen dieser Firma eine einwöchige Schulung zu UML.

Von daher, ich denke, dass ich mir schon ein Urteil für mich selbst zu UML erlauben kann ...

Habe in meiner letzten Firma mit UML gearbeitet. War auch ein relativ großes Projekt.
Naja, deswegen kann ich von mir aus auch behaupten, das ich mit UML schon gearbeitet habe. Zwar nicht extrem und jeden Tag. Ich kenne die Grundlagen und könnte auch wieder UML verwenden (nach kurzer Einarbeitungszeit, da es schon etwas länger her ist).

"Ein Bild sagt mehr als 1000 Worte"

Dazu muss das Bild aber auch interpretiert werden können 🙂

Und Golos Argument, mit wem man zusammenarbeitet ist IMHO ziemlich ausschlaggebend. Wenn wir unseren Kunden ein Konzept vorlegen mit Diagrammen (Ablauf, Sequenzen, blabla) und dazu ein 10 Seiten Word-Dokument, versteht der Kunde das ziemlich schnell und kann sofort mit agieren.
Wenn wir unseren Kunden ein UML hinlegen würden, würde wahrscheinlich nur ein "Das sind aber hübsche Strichmännchen" bei raus kommen. Also völlig unbrauchbar.

[Edit] Und für Intern ein UML erstellen und für Extern eine Doku... Ich denk mal so viel Zeit hat keiner...

Meine Meinung dazu:

* MDA/UML ist schön, aber nicht zwingend notwendig, es gibt Alternativen wie DSL, die aber letztlich oft nur ein UML-Profil sind.
* ob sich UML auszahlt hängt stark vom Projekt und vom Prozess ab. Wenn es nur als Dokumentationswerkzeug dient ist der Nutzen fragwürdig, es sei denn, man fährt schwergewichtige Entwicklungsprozesse (hier muss man eh jeden Mist dokumentieren)
* MDA/UML ist gut für den internen Prozess. Als Kommunikationsmittel für den Kunden bringt es wenig, es sei denn es gibt jemand auf Kundenseite, der Use-Cases beherrscht und gleichzeitig (!) die Schittstelle zur Fachabteilung darstellt. Mir ist so ein Kunde noch nicht untergekommen... hier sollte man lieber mal an agile Methoden denken.
* MDA/UML steht und fällt mit den eingesetzten Tools
* MDA/UML braucht eine strategische Planung, insbesondere wenn eigene Codegeneratoren schreiben muss/will.
* man braucht eine gewisse Erfahrung damit, sonst wird es schnell frustrierend
* wer an Schulungen spart, wird das teuer bezahlen
* das ganze funzt nur mit einem geplanten bzw. erprobten Entwicklungsprozess
* es ist hilfreich, wenn man einen echten UML-Profi zur Hand hat, der auch das UML-Meta-Modell kennt um ggf. die fest eingebauten Codegeneratoren anpassen zu können. Oder man plant etwas Geld ein, um das vom Zulieferer machen zu lassen (fragen ob die das machen können oder wollen!)

"Jetzt-machen-wir-mal-UML"-Projekte scheitern meiner Erfahrung nach fast immer, weil eine oder mehrere dieser Vorraussetzungen nicht erfüllt sind.

Bei der Tool-Auswahl würde ich große Vorsicht walten lassen. Man sollte insbesondere beim Reverse- bzw. Roundtrip-Engineering genau hingucken (sich das vorführen lassen!) und auch die Integration ins Konfig-Management beachten. Viele Tools erwarten einen Rahmenprozess. Schauen ob der zum eigenen paßt! Gerade wenn man agil arbeitet kann das kritisch werden.

Oha! Eine Anti-UML-Fraktion? Hätte nicht gedacht, dass so etwas existiert.

Also ich habe festgestellt, das UML für kleinere Projekte nicht viel unterschied zu Textdokumenten macht. Je größer und komplexer ein Projekt jedoch wird, desto ehr war ich froh, ein Übersichtsdiagramm zu haben und/oder kleine Diagramme (eventuell begleitend zu einem Text).

Also ich würde schwören, dass man mehr Zeit verliert, wenn man einen Text liest (der ja irgend wie gestalltet ist) als wenn man die gleiche Information aus einem UML-Diagramm (besser gesagt mehreren, da in einem Text vermutlich alle UML-Sichten durcheinander gewirbelt sind) zu lesen.
Aber gut, darüber könnte man wirklich streiten. Vielleicht gibts ja eine Studie dazu oder so. Egal.

Nein nicht ganz, wenn man mit mehreren Team's arbeitet und dem Kunden was bei bringen will, ohne technisch zu werden, dann wird sicherlich auch der, der am wenigsten von IT eine Ahnung hat, ein Use-Case verstehen, darum gehts. Das eine oder andere Diagramm kann man je nach Bedarf ja weglassen, ich halte UML je nach Einsatzzweck ein sehr gutes Hilfsmittel.