Umfrage: UML in der Praxis?
-
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."
Das viele Entwickler nicht vernünftig abstrahieren können, stimmt wohl, auch wenn es vielleicht nicht 4 von 5 sind. Aber, dass UML deswegen wenig eingesetzt wird ist zusammenhangslos. Es gibt einfach keine effiziente und flexible Möglichkeit UML und Code zu verbinden, vorallem im C++ Bereich und da will man nicht alles in UML malen und dann nochmal in Code tippen.
-
Die Kommentare verwundern mich jetzt etwas, weil sie OOA/OOD völlig ausblenden. Dass man sich UML sparen kann, wenn man damit sowieso nur den Code 1:1 abbildet versteht sich ja ohnehin.
-
Bashar schrieb:
Die Kommentare verwundern mich jetzt etwas, weil sie OOA/OOD völlig ausblenden.
Was willst du da jetzt mit UML? Willst du UML konforme Use-Cases zeichnen? Die hab ich doch lieber als Text.
-
Bashar schrieb:
Die Kommentare verwundern mich jetzt etwas, weil sie OOA/OOD völlig ausblenden. Dass man sich UML sparen kann, wenn man damit sowieso nur den Code 1:1 abbildet versteht sich ja ohnehin.
Um ein Domain Model bildlich darzustellen, ist UML natürlich ein gutes Werkzeug. Aber ich bilde damit letztlich eh nur das grobe Modell ab. Denn die Details muß ich eh schriftlich erfassen, weil ich mit dem Fachbereich Interviews führen muß.
Und Usecases schreibe ich auch lieber als Prosa nieder. Man kann immer natürlich ein nettes Bild dazu machen, weil Bilder schneller erfasst werden können. Aber Text überwiegt meistens.Und dem Klassen-Code erzeuge ich nicht aus den UMLs. Weil sich sowas eh im Laufe der Entwicklung ändert. Also müsste ich immer die UMLs zuerst ändern, was mir meinen bestehen Code kaputt machen würde.
Und ich halte es imme rnoch so: Code ist auch eine Beschreibung. Nur halt nicht für den Fachbereich/Fachkunden lesbar. Aber der bekommt einfache UML Diagramme von mir vorgelegt. Ja, manchmal kruitzel ich auch lieber nur mal schnell was auf das Flipchart, geht schneller und der Kunde kann mitmachen.
-
Ich arbeite seit 1999 als Webentwickler mit Schwerpunkt PHP/Linux und in den drei Firmen, in denen ich bis jetzt war, habe ich zwar schon mal UML-Diagramme gesehen, aber dass was wir sonst so zum Verständnis an den Flipchart oder aufs Blatt kritzeln, hat nur wirklich sehr entfernt was mit UML zu tun.
Ich habe aber auch nie wirklich große Projekte mitgemacht und in Zukunft wird es bei uns auch nicht dazu kommen, da wir nur noch interne Tools entwickeln und nicht wirklich mit Kunden was zu besprechen haben, für mich ein Traumjob mit viel Zeit zum weiterbilden.
-
asc schrieb:
Da gibt es eigentlich noch mindestens einen fehlenden Punkt:
- Ja, aber nur sehr selten.Genau das hab ich auch gedacht. UML (oder zumindest etwas, was dem ähnlich sieht) benutz ich nur recht selten. Dann meist um mir selbst oder einem Kollegen irgendwas klar zu machen.
Edit: Und dann auch nicht hübsch mit ArgoUML und co. sondern nur kurz auf Papier gekritzelt.
-
Ich habe es lieber, mir das System, das entwickelt werden soll im Kopf durchzugehen. Und anschließend die Entwicklung zu beginnen.
Bei UML-Diagrammen halt ich mich immer zu lang auf. - Oft, weil ich selbst nicht zufrieden bin aber auch weil andere nicht zufrieden sind mit dem Diagramm.
Einer meiner Kollegen, der schon länger im Unternehmen ist, versucht jedoch zunehmend UML zum Einsatz zu bringen. - Deshalb sitze ich beim aktuellen Projekt schon wieder den 3. Tag an UML-Diagrammen...
Wenn in der Ausbildung UML dran war, hab ich das meist so gehandhabt, dass ich die Aufgabe in Code gelöst habe und anhand des fertigen Codes die Diagramme erstellt habe. Fand ich immer einfacher, damit war ich meist der erste der nach Haus konnte.
-
Artchi schrieb:
Aber Text überwiegt meistens.
Exakt das.
UML ist praktisch wenn man eine Idee erklären will, aber auch da reichen eigentlich Design Pattern (die aber wiederum per UML erklärt werden können) als gemeinsame Sprache.
Generell sehe ich keinen wirklichen Sinn in UML. Manchmal hilft es eine gemeinsame Sprache zu haben beim Beschreiben eines Problems - aber in den meisten Situationen sind Use Cases in Text besser (vorallem weil dann die Domain Spezialisten mitreden können - UML ist eine Sprache nur zwischen den Programmieren).
-
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?
