C/C++ Forum :: Umfrage: UML in der Praxis?

/rant/ Mitglied 00:40:44 01.02.2012 Titel:

Guten Abend liebe Liebende

Aus Interesse und aktuellem Anlass, hier mal eine Umfrage zum Einsatz von UML in der Praxis. Nicht zählen tut UML in der Ausbildung. Ich meine wirklich den Einsatz in Projekten im geschäftlichen Umfeld. Habt ihr das schon mal einsetzen können? Ich habe es noch nie brauchen können, weil selbst in grösseren Projekten genau solche Dinge niemand bezahlen will. Prototypen hingegen durfte ich immer basteln; die Leute wollen scheinbar lieber etwas zum spielen haben, als diese lustigen Diagramme (was ich gut nachvollziehen kann

).

MfG

C++ Forumbot Forumbot 00:43:19 01.02.2012 Titel:

Dieser Thread wurde von Moderator/in rüdiger aus dem Forum Neuigkeiten aus der realen Welt in das Forum Rund um die Programmierung verschoben.

Im Zweifelsfall bitte auch folgende Hinweise beachten:
C/C++ Forum :: FAQ - Sonstiges :: Wohin mit meiner Frage?

Dieses Posting wurde automatisch erzeugt.

KingKarl Mitglied 05:56:24 01.02.2012 Titel:

bis auf wenige kurze ausnahmen arbeite ich allein. daher werd ich mir kaum vorher ein uml zeichnen. allerdings schreibe ich manchmal funktionsköpfe, die ich mir dann zum ausfüllen aufheb. das zählt aber nicht, oder? :rolleyes:

Unregistrierter

Ja, Klassendiagramme schon, wenn vlt. auch nicht exakte UML Syntax. In Java oder anderen Sprachen, wo mehr http://de.wikipedia.org/wiki/Modellgetriebene_Softwareentwicklung gemacht wird, wird es wohl noch mehr verwendet.

Unregistrierter

/rant/ schrieb:

Ich habe es noch nie brauchen können, weil selbst in grösseren Projekten genau solche Dinge niemand bezahlen will.

Nicht nur das, ich würde sagen, daß in den meisten Fällen sogar bei Personal auch die Praxis und Erfahrung fehlt, um die UML Diagramme schnell, sinnvoll und effizient umzusetzen.

Und wofür man mangels Praxiserfahrung Tage braucht, wird man halt eher darauf verzichten.

Ich wette aber, daß ein eingespieltes Team mit Erfahrung in UML die UML ausgiebig und auch effizient, und damit dann auch gewinnbringend einsetzen können wird.

UML Diagramme bringen nämlich schon etwas, nur wird der Gewinn ad absurdum geführt, wenn der Weg ewig braucht, um die Diagramme zu erstellen.
Das dürfte das eigentlich Problem sein.

Und die hingefrickelte Software scheint wohl noch gut genug zu sein, so daß auch kein Zwang besteht, die UML wirklich einzusetzen.

Unregistrierter

ich halte nichts von uml diagrammen. musste es zum glück nur in der uni lernen/ anwenden.

uml diagramme wären imo nur dann zu gebrauchen, wenn sie sich automatisch mit dem code synchronisieren. das funktioniert aber afaik maximal für klassendiagramme. ich habe zumindest noch kein tool gesehen, das aus code sequenzdiagramme oder dergleichen generieren kann. klassendiagramme sind aber sehr schnell sehr uninteressant, weil sie bei geeignet großen projekten geeignet groß und somit unübersichtlich werden.

wenn sich die diagramme nicht automatisch synchronisieren, sind sie ab dem zeitpunkt obsolet, wo du mit der programmierung anfängst. oder hast du lust, während der programmierung ständig die diagramme manuell zu aktualisieren, weil sich wieder mal gezeigt hat, dass man vom plan abweichen musste, weil sich anforderungen geändert haben oder einfach mal wieder praxis != theorie war.

Unregistrierter

lolhehe schrieb:

uml diagramme wären imo nur dann zu gebrauchen, wenn sie sich automatisch mit dem code synchronisieren. das funktioniert aber afaik maximal für klassendiagramme. ich habe zumindest noch kein tool gesehen, das aus code sequenzdiagramme oder dergleichen generieren kann.

Die brauchbaren UML Tools die mehr können als nur Klassendiagramme zu zeichnen kosten alle Geld.

Zitat:

klassendiagramme sind aber sehr schnell sehr uninteressant, weil sie bei geeignet großen projekten geeignet groß und somit unübersichtlich werden.

Deswegen gibt's ja auch Paketdiagramme, da kann man mehrere Klassen zu Modulen zusammenfassen.
Sinnvoll wäre es allerdings, wenn die Sprache Module unterstützen würde. C++ tut das nicht, Java schon.

Zitat:

wenn sich die diagramme nicht automatisch synchronisieren, sind sie ab dem zeitpunkt obsolet, wo du mit der programmierung anfängst.

UML Diagramme sind meiner Meinung nach in erster Linie auch dazu da, die Software erstmal zu designen bzw. zu modelieren.

asc Mitglied 13:23:04 01.02.2012 Titel:

Da gibt es eigentlich noch mindestens einen fehlenden Punkt:
- Ja, aber nur sehr selten.

Ich habe mit Nein abgestimmt, da ich zwar mit UML zu tun hatte, dies aber nur sehr, sehr selten (In einen Projekt innerhalb meiner bisherigen Arbeitswelt wurde UML intensiv benutzt, aber sonst in der Regel überhaupt nicht, höchstens um für einen relativ kleinen Themenbereich eine grobe Übersicht zu haben über die man Diskutieren kann).

Prof84 Mitglied 14:30:33 01.02.2012 Titel:

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."

Der größte Treppenwitz zum UML habe ich bei der Dt. Post erlebt: Dort haben sie jeden Stapplerfahrer gezwungen UML zu lernen, damit die SW Entwicker ihre SW validieren konnten. Für einen Umsatzbereich von 11 Stellen. :o)

*tätätäät*

Unregistrierter

dich kann man echt nich ernst nehmen :o)

this->that Mitglied 16:17:53 01.02.2012 Titel:

Seit der Uni hab ich es nicht einmal mehr benutzt. Was aber nicht heisst, dass ich es jetzt unnuetz finde. Bei grossen Projekten mit vielen Schnittstellen etc. kann UML durchaus Sinn machen.

Artchi Autor 16:41:37 01.02.2012 Titel:

Ich lasse lediglich aus bestehendem Code UML-Diagramme erzeugen. Entweder um selber einen Überblick zu erhalten, oder es Kollegen und Kunden zu zeigen. Denn nicht immer ist Code interessant.

Aber im Prinzip nutze ich es nicht. Denn ich kann Klassen, Komponenten und Module auch direkt in Code beschreiben. UML ist schließlich auch nur eine Sprache. Und man kommuniziert mit der Sprache, die man selber und andere verstehen. Und da ich Java und C++ verstehe, kann ich das auch gleich so niederschreiben.

Unregistrierter

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.

Bashar Mitglied 22:54:20 01.02.2012 Titel:

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.

Unregistrierter

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.

Artchi Autor 00:03:23 02.02.2012 Titel:

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.

Unregistrierter 10:21:52 02.02.2012 Titel:

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.

Dobi Mitglied 10:46:45 02.02.2012 Titel:

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.

inflames2k Mitglied 12:52:49 02.02.2012 Titel:

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. :o)

Shade Of Mine Moderator 13:16:36 02.02.2012 Titel:

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).

/rant/ Mitglied 14:20:51 02.02.2012 Titel:

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

Unregistrierter

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.

Unregistrierter

@Shade: Wie unterscheiden sich die Use Cases, die du meinst, von denen, die UML mitbringt?

daybyter Mitglied 02:11:34 10.02.2012 Titel:

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.

Andreas XXL Mitglied 13:08:59 10.02.2012 Titel:

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.

Walli Mitglied 15:50:19 10.02.2012 Titel:

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.

Unregistrierter

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?