Umfrage: UML in der Praxis?
-
Danke für das reichliche Feedback für die Umfrage, mein Bild bestätigt sich mehr oder weniger.
Intern sitzen wir geschäftlich oft vor einem grossen Whiteboard und zeichnen schematisch Dinge auf: Datenbanken, Klassen, Deployment. Aber auf Dinge wie UML haben wir niemals geachtet. Es muss alles schnell gehen, und es geht darum, bei den anderen Teilnehmern auf einfachste Weise ein Verständnis für die Problemstellung zu erzeugen. Für das sind einfache Zeichnungen, gepaart mit einer Legende viel effizienter, als irgend eine Konvention, die alle zuerst noch lernen müssen.
Jedesmal wenn wir im Rahmen des Studiums mit UML zu tun hatten (und haben) endet es in einem massiven Clusterfuck, weil man sich nicht mehr auf Inhalte, sondern nur noch auf Formalismen konzentrieren muss. Das trägt nicht zur Motivation für eine spätere Verwendung bei
-
UML ist irgenwie so unintuitiv zu Verwenden wie Whitespace. So viele wichtige Sachen werden durch so unklare und kleine Unterschiede dargestellt, wie z.B. geschlossener oder offener Pfeil.
-
@Shade: Wie unterscheiden sich die Use Cases, die du meinst, von denen, die UML mitbringt?
-
Ich benutze es schon ewig. Da ich nicht so viel Overhead durchs Zeichnen haben will, achte ich sehr darauf, dass ich dann auch gleich Code aus dem Tool erzeugen kann. Da es lange Zeit kaum brauchbare freie Tools gab, hab ich eine ganze Weile an ArgoUML mitgearbeitet und da u.a. am Java Reverse Engineering mitgearbeitet. Ebenso hab ich mehrere Code-Generatoren (mit-)entwickelt. Von XSL-Transformierungen bis zu Velocity-Templates.
Interessanterweise stoss ich mit Diagrammen sehr oft auf positive Resonanz, wo ich mit Source-Code niemals landen könnte. Also bei Marketing-Leuten, grafischen Designern usw. Da kann man sehr schnell gewisse Zusammenhänge zwischen Komponenten erklären, was anders kaum ginge, weil die Leute in der Regel einfach nicht bereit sind, sich durch paar Hundert Zeilen Sources zu quälen, um dann zu sehen, wie welche Daten im System herumgereicht werden.
-
Ich sehe das so:
Es gibt zwei Arten von Software.
Die erste Sorte ist die "Alltagssoftware" die muss irgendwie funktionieren viele hübsche und unsinnige Sachen haben, wird bei Otto Normalverbraucher verwendet und ist in kurzer Zeit wieder out. Dementsprechend wird sie auch entwickelt ;). Hier kommt es darauf an schnell zu entwickeln und Fehler so weit zu verstecken, dass sie nicht alzusehr auffallen. => Kein UML
Die zweite Art von Software sind Kernkomponenten die lange Bestand haben und deren Richtigkeit und Wartbarkeit wichtig sind. Sowas wie TCP/IP Implementation, Schnittstellen usw. => UML ist hier sinvoll.
Meistens wird aber Software von der ersten Sorte produziert. Quick & Dirty, eben ohne UML.
-
Prof84 schrieb:
Um UML effektiv und sinnvoll einzusetzen sind Skills nötig, die IMAO bei den meisten Informatikern nicht vorliegen.
Oder es mit Erik Evans zu sagen: "4 von 5 SW Entwickler können nicht vernünftig abstrahieren."
Wer vernünftig abstrahieren kann, der braucht meiner Meinung nach auch kein UML. Ich habe eher den Eindruck, dass es in der Praxis oft eher als gemeinsamer Nenner zur Kommunikation verwendet wird, wenn die Entwickler keine Ahnung von dem haben, was sie da entwickeln sollen, und die Leute mit Ahnung es nicht selber programmieren können. Um in Teams ein wenig grafische Schieberei in der Planungsphase zu machen und Schnittstellen zu definieren, ist das sicherlich geeignet, aber wer UML in all seinen Facetten bis zum Ende durchzieht, der hat entweder zu viele BWLer in der Firma oder zuviel Zeit für die Projekte. Das meiste muss doch in der Regel bereits gestern fertig gewesen sein.
-
Andreas XXL schrieb:
Die zweite Art von Software sind Kernkomponenten die lange Bestand haben und deren Richtigkeit und Wartbarkeit wichtig sind. Sowas wie TCP/IP Implementation, Schnittstellen usw. => UML ist hier sinvoll.
Solche Sachen werden in der Regel in C realisiert und dann wird für so etwas oft auch kein OOP verwendet (z.b. TCP/IP würde ich nicht in OOP machen), wo willst du da noch UML gebrauchen?