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
_________________ MCPD, MCTS and more! | "It's 7:05am. I have not slept." | www.google.com
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.
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.
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.
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.
Zuletzt bearbeitet von Walli am 15:53:40 10.02.2012, insgesamt 2-mal bearbeitet
C Progger
Unregistrierter
C Progger Unregistrierter
16:20:39 10.02.2012 Titel:
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?
Nächstes Thema anzeigen Vorheriges Thema anzeigen
Sie können Beiträge in dieses Forum schreiben. Sie können auf Beiträge in diesem Forum antworten. Sie können Ihre Beiträge in diesem Forum nicht bearbeiten. Sie können Ihre Beiträge in diesem Forum nicht löschen. Sie können an Umfragen in diesem Forum nicht mitmachen.
c++.de ist Teilnehmer des Partnerprogramms von Amazon Europe S.à.r.l. und Partner des Werbeprogramms, das zur Bereitstellung eines Mediums
für Websites konzipiert wurde, mittels dessen durch die Platzierung von Werbeanzeigen und Links zu amazon.de
Werbekostenerstattung verdient werden kann.
Die Vervielfältigung der auf den Seiten www.c-plusplus.de, www.c-plusplus.info, www.c-sar.de, www.c-plusplus.net und www.baeckmann.de
enthaltenen Informationen ohne eine schriftliche Genehmigung des Seitenbetreibers ist untersagt
(vgl. §4 Urheberrechtsgesetz). Die Nutzung und Änderung der vorgestellten Strukturen und Verfahren in
privaten und kommerziellen Softwareanwendungen ist ausdrücklich erlaubt, soweit keine Rechte Dritter verletzt werden.
Der Seitenbetreiber übernimmt keine Gewähr für die Funktion einzelner Beiträge oder Programmfragmente, insbesondere
übernimmt er keine Haftung für eventuelle aus dem Gebrauch entstehenden Folgeschäden.