UML - Buzzword für Manager?
-
Mal ehrlich: Hat UML einen praktischen Zweck oder ist es nur dazu da, für begriffsstutzige Manager hübsche Bildchen zusammenzuklicken, damit man behaupten kann, man sei auf der Höhe der Zeit?
-
Mal ehrlich: Hat UML einen praktischen Zweck
Klassendiagramme verschaffen einen schnellen Überblick
Interaktionsdiagramme wie z. B. Sequenzdiagramm zeigen sehr schon auf wie Nachrichten zwischen Objekten ausgetauscht werden und was beim Aufruf einer Methode so alles passieren kann...in manchen Fällen habe ich anhand eines UML Diagramms wesentlich schneller die Funktionsweise eines Programms erkannt, als es nur anhand des Sourcecode möglich gewesen wäre
übertreiben mit der UML braucht man es natürlich auch nicht
UML zu lernen ist ziemlich trocken und langweilig, aber ich zeichne heute schon ab und zu erst mal 2 Stunden rum bevor ich mich an den Rechner hocke
-
Ich kann mich nur deiner Meinung anschließen. Durch die verwendung der uml wird die softwareentwicklung deutlich vereinfacht. die uml kann ein projekt durch die unterschiedlichen phasen begleiten - angefangen mit der analyse, design bishin zur umsetzung; wobei ein immer präzieseres bild von der Problemstellung entsteht.
Ein anderer wichtiger vorteil ist der standard. Programmierer die Kenntnisse in der UML haben können untereinander deutlich besser kommunizieren und so werden Missverständnisse und Fehlentscheidungen vorgebeugt.
Natürlich kann man es auch übertreiben mit dem einsatz der uml. Im endeffekt liegt es immer noch an den fähigkeiten des Programmierers...
Ich persönlich habe nur positive Erfahrungen mit dem einsatz der UML gemacht und mit der Meinung das sich es durchaus lohnt sich damit zu beschäftigen. Ich könnte mir vorstellen das es besonders Anfängern leichter fällt, ich nenne einfach mal ein Beispiel, die Vererbungshyrachie der Streams (ob in C++ oder Java oder schießmichtot welche sprache sei dahingestellt) als kompakte Graik zu verstehen als durch einen 3 seitigen text.
-
Use-Case-Diagramm und Klassendiagramm finde ich persönlich auch sehr interessant.
(Jede Funktion vorher mit UML und einem Aktivitätsdiagramm zu zeichnen ist hingegen dämlich).
MfG SideWinder
-
Use-Case-Diagramm und Klassendiagramm finde ich persönlich auch sehr interessant.
Genau. Jedes Diagramm hat seine genau Aufgabe und Bestimmung. Das Use-Case-Diagramm ist zum Beispiel sinnvoll, damit man eigentliche Aufgabe im Focus behällt und beugt vor sich in unnötigen Extras zu verzetteln.
(Jede Funktion vorher mit UML und einem Aktivitätsdiagramm zu zeichnen ist hingegen dämlich).
Dafür ist die UML auch nicht entworfen worden. Aktivitätsdiagramme sind gut anwendbar bei komplexen und anspruchsvollen Abläufen; es ist jedoch total sinlos, wie schon richtig gesagt wurde, jede Propertyprozedur als Aktivität darzustellen.
-
Gibt halt Leute die das als Gegenargument verwenden
MfG SideWinder
-
An der Uni wurde uns in einer Vorlesung eingeredet, dass es alles unverzichtbar für jeden Entwickler sei. Bis heute habe ich aber kein größeres Projekt gesehen, bei dem die ganze UML-Sache konsequent von Anfang bis Ende durchgezogen wurde. Hier und da mal ein Klassendiagramm oder bei sehr komplexen Abläufen ein Diagramm, sonst kenne ich UML nur aus der Theorie. Aber das ist auch gut so. Wenn Softwareentwicklung künftig so verBWLert wird, dann habe ich da auch keine rechte Lust drauf
.
-
umla schrieb:
... ist es nur dazu da, für begriffsstutzige Manager hübsche Bildchen zusammenzuklicken....
Für die macht man es eher nicht!
Auch ich habe einmal den Fehler gemacht mit UML Diagrammen ins Management zu laufen, um zu erheben wie die Ihre Software gestrickt haben wollen. Ist lang her.
Heute verwende ich UML-Diasgramme außerhalb der SW Domain nur in absoluter Notwehr.Ein bekanntes Logistik-Unternehmen arbeitet heute ständig so: Eine Stunde Modellierung und dann Stapplerfahrern drei Tage erklären, was das Modell bedeutet. Und das seit anderthalb Jahren in allen Teams.
Echte Profis hingegen betreiben seriös Anforderungsmanagement und -analyse.
-
Kommt das dann auch dem return on investment zugute?
-
UML hat imho in größeren Projekten eine Bedeutung, aber bei vereinzelten Programmierern und kleinen Programmen ist es einfach eine V2 die auf nen Spatzennest abgeschossen wird.
Im Endeffekt muss der Programmierer nur die Klassendiagramme verstehen. Use-Case-Diagramme, etc. sind für Analysten interessant, die eine gesamte Infrastruktur damit planen oder für die Designer, die dann Funktionalitäten in Komponenten zusammen fassen und die eigentliche Arbeit für den Programmierer aufbereiten, so dieser noch irgendwas zu tun hat. Der Optimalfall wäre der, dass der Pool an existierenden Komponenten ausreicht, um die Applikation am Reißbrett zusammen zu schrauben (wirds wahrscheinlich eher selten geben.)
Wenn ich mir hier ne kleine Datenbank stricke oder nen MP3-Player, dann mach ich mir da maximal nen Klassendiagramm, aber der Rest ist da echt übertrieben.
-
DocJunioR schrieb:
UML hat imho in größeren Projekten eine Bedeutung, aber bei vereinzelten Programmierern und kleinen Programmen ist es einfach eine V2 die auf nen Spatzennest abgeschossen wird....
Das ist nicht das entscheide Kriterium. Entscheidend ist der RE-USE außerhalb der Domain!
Auch als Spatz kannste eine kleine Entwicklung vorantreiben, die mehrfach wiederverwendet oder erweitert wird.Ich hoffe auch stark, Du unterscheidest in deinen Statement zwischen Entwicklern und Programmierern.
-
Wenn der Analyst erklärt, dass es diese und jene Prozesse gibt, der Designer dann sagt, zu diesen Prozessen gehören diese Komponente mit solchen Anwendungsfällen, ist der Programmierer auch wirklich "nur noch" Programmierer.
Programmierer führen aus, Entwickler sind Kreativ. Das mag vielen nicht gefallen, ist aber so.(Ich hab nie behauptet, dass meine Erkenntnisse euch oder mich glücklich machen ) Die Software wird immer komplexer und ein Einzelentwickler im freien Feld der irgendetwas bastelt ist- mal von Webportalen, etc. abgesehen- inzwischen eher der Sonderfall.
-
Prof84@work schrieb:
Ich hoffe auch stark, Du unterscheidest in deinen Statement zwischen Entwicklern und Programmierern.
und zwischen Programmierern und Codern. und zwischen Architekten und Entwicklern.
lucky tux schrieb:
Ich könnte mir vorstellen das es besonders Anfängern leichter fällt,
deswegen die verbreitung. nicht nur anfänger, sondern auch profis, die es nie lernen werden, gute software zu bauen. buzzwording und uml in der störenden form werden duchaus von den selben leuten vorangetrieben (bei uns Prof84@work).
wenn hingegen jemand mal einen amerikanismus verwendet, um besser zu verstehen zu sein statt schlechter, und wenn jemand mal uml verwendet, weil's als ergänzung das verstehen erleichtert http://www.c-plusplus.net/forum/viewtopic-var-t-is-155350-and-start-is-0.html, dann ist das die viel zu selten gesehene ausnahme.
-
DocJunioR schrieb:
Wenn der Analyst erklärt, dass es diese und jene Prozesse gibt, der Designer dann sagt, zu diesen Prozessen gehören diese Komponente mit solchen Anwendungsfällen, ist der Programmierer auch wirklich "nur noch" Programmierer.
zum glück klickt dieser Programmierer sich die software mit einem CASE-tool zurecht und muß nur selten code sehen.
-
volkard schrieb:
...
und wenn jemand mal uml verwendet, weil's als ergänzung das verstehen erleichtert http://www.c-plusplus.net/forum/viewtopic-var-t-is-155350-and-start-is-0.html, dann ist das die viel zu selten gesehene ausnahme.Wenn es in diesem Forum UML tags gäbe, würden es sicher auch mehr Leute verwenden :p
Ich mach mir für meine kleinen Hobbyprojekte nur Klassendiagramme (nicht nach UML Norm) auf Papier. Mir persönlich hilft das, um zu verstehen was ich will.
-
UML ist etwas, das die Welt nur zum rumwirtschaftlern braucht. Da gehen wertvolle Arbeitsstunden drauf, um Manager und Wirtschaftsinformatiker vom Konzept zu überzeugen, oder wenn vom Auftraggeber eine Dokumentation gefordert ist, generiert man halt ein Klassendiagramm raus.
Ich verstehe auch gar nicht, warum man auf UML so abgehen muss. Wahrscheinlich niemand bestreitet, dass es gut ist, einen Stift und Papier zur Hand zu haben. Seit Jahren zeichen Entwickler (und architects, programmers, coders, consultants, ...) Klassendiagramme, Flußdiagramme und Sequenzdiagramme. In manchen Fällen sicherlich äußerst nützlich, aber wer mein Klassendiagramm nicht versteht, weil ich jetzt einen einfachen Pfeil anstatt eines mit einer dreieckigen Pfeilspitze gemalt habe, der sollte das Programmieren lieber bleiben lassen.
Jedes Diagramm benötigt sowieso eine Erklärung von jemandem der im Projekt drin ist, damit man die ganze Idee rüberbringen kann. Ein Haufen Klassen mit Pfeilen darin erklärt nie, wie das jetzt alles auszusehen und zu funktionieren hat. Wie eine Klasse im Diagramm auszusehen hat, da kann man improvisieren, das ist nicht das schwierigste, rauszulesen. UML will die Entwickler in ein Korsett zwingen, nicht mehr frei improvisieren und das Wesentliche hinkritzeln zu können, dabei muss es gar nicht sein, dass ein UML-Sequenzdiagramm gerade die beste Darstellungsform ist. Wir haben bei einem Studienprojekt den Schmarrn schon mal weggeworfen, was anderes hingekritzelt, dem Prof erklärt und die beste Arbeit abgegeben. Wie gesagt, nichts gegen Stift und Papier.
-
volkard schrieb:
....
lucky tux schrieb:
Ich könnte mir vorstellen das es besonders Anfängern leichter fällt,
deswegen die verbreitung. nicht nur anfänger, sondern auch profis, die es nie lernen werden, gute software zu bauen. buzzwording und uml in der störenden form werden duchaus von den selben leuten vorangetrieben (bei uns Prof84@work).
@Outsider:
Volkard und ich lieferten uns in der Vergangenheit so manchen Flame...
Optimizer schrieb:
Jedes Diagramm benötigt sowieso eine Erklärung von jemandem der im Projekt drin ist, damit man die ganze Idee rüberbringen kann. Ein Haufen Klassen mit Pfeilen darin erklärt nie, wie das jetzt alles auszusehen und zu funktionieren hat. Wie eine Klasse im Diagramm auszusehen hat, da kann man improvisieren, das ist nicht das schwierigste, rauszulesen. UML will die Entwickler in ein Korsett zwingen, nicht mehr frei improvisieren und das Wesentliche hinkritzeln zu können, dabei muss es gar nicht sein, dass ein UML-Sequenzdiagramm gerade die beste Darstellungsform ist. Wir haben bei einem Studienprojekt den Schmarrn schon mal weggeworfen, was anderes hingekritzelt, dem Prof erklärt und die beste Arbeit abgegeben. Wie gesagt, nichts gegen Stift und Papier.
Genau das ist der Punkt, der hier einfach nicht verstanden wird:
UML ist kein 'Goldener Hammer' (siehe Antipatterns).
Wenn ein Manager mit Hilfe von Umsatz-Charts über seine Anforderungen, Ziele und Konzepte für SW sprechen möchte, darf er das! Der Elektroingeieur mit seinen Schaltplan, der Lagerist mit seinen Bestandslisten, der Kraftwerksleiter mit seinem Power-Grid Plan etc. Und der SW- Éntwickler mit UML. Meine Aufgabe als Analyst, Architekt, Entwickler oder Anforderungsmanger ist es Roundtrip-Engineering zwischen den Domainmodellen der Stakeholder und meiner SW zu betreiben - ich bin der Analytiker. So, jetzt versuch mal eine bidirektionale Traceability zwischen Code und z.B. einer CAD Zeichung herzustellen. Klar kannst Du remarks reinschreiben, aber versuch mal das System zu warten und zu überblicken. Genau das ist der Vorteil von Visualisierungen! In der Konzeptentwicklung werden aber nicht nur zwei sondern sehr viele Aspekte von unterschiedlichen Domainen aufeinandergestellt - HW, SW, Management, Testen, Wartung, Operationen, Prozesse etc. und die kannst Du ja gerne direkt im Code warten fürs Changemanagement. Wir Profis machen es nicht so ...Genau deshalb betreibt man Abstraktion und Modellierung. Das ist nicht nur in der SW-Entwicklung so, dass ist in faßt allen Fachbereichen so. Und was soll jetzt hier die Ausrede sein es nicht zu tunen. Das Du eine Codezeile schneller ändern kannst?!
-
volkard schrieb:
buzzwording und uml in der störenden form werden duchaus von den selben leuten vorangetrieben (bei uns Prof84@work)
Prof84@work schrieb:
Und der SW- Éntwickler mit UML.
ich habs doch gesagt, gell?
Prof84@work schrieb:
...Roundtrip-Engineering...Domainmodellen...Stakeholder...bidirektionale Traceability...remarks...Changemanagement
bingo!
-
ich persönlich bin von UML auch nicht besonders angetan...es ist sicherlich ein nettes Werkzeug, aber man kann sich auch tot-UMLen, wenn man wirklich alles nur nach diesem Standard planen und formulieren möchte. Ich fand es sehr amüsant, als bei uns an der FH mal ein Vortrag zweier Leute von BlueByte stattfand, die über die Siedler-Reihe sprachen. In der Hörerschaft saß auch unsere Software Engineering-Prof'in, die dann irgendwann gegen Ende fragte, wie denn die ganze Planung und Kommunikation zwischen den einzelnen Teams wohl aussehe...tja, kurz gesagt, der erste Satz, der als Antwort kam, war: "Wir machen keine UML-Diagramme oder so!"...die war nicht gerade zufrieden...
-
Mit Sicherheit ist die UML nicht das "Ein und Alles", das ist richtig. Aber sie _kann_ sich in Projekten als nützlich erweisen. Und das ist glaube ich der Punkt an dem wir die ganze Zeit festhengen und uns uneinig sind. Die Betonung liegt auf kann. Ich finde man sollte die UML auch nur dann einsetzen, wenn es Sinn machen würde und nicht um irgendwelche Manager zu beeindrucken oder gar den Klienten durch schöne Bildchen in den (falschen) Glauben zu versetzen, wie weit das Projekt schon ist... Das klingt ein wenig übertrieben, aber in einigen Betrieben ist dies gang und gebe. Sinnvoll erweißt sich jedoch die Verbesserung der Kommunikation zwischen Analysten, Designern und Programmierern. Es ist wie schon gesagt einfacher wenn alle Beteiligten eine Sprache sprechen. Ein wenig abstrakt gesehen: Wohin soll es führen, wenn der Analyst deutsch, der Designer englisch und der programmierer französisch spricht; es würde keine gelungene kommunikation zu stande kommen.