UML - Buzzword für Manager?
-
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.
-
Prof84@work schrieb:
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.
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.
Klar, darf man alles hernehmen. Aber es ist Bullshit, zu glauben, dass man damit anderen etwas erklären kann. Wenn du für dich ein Diagramm (egal welcher Art) als Gedächtnisstütze machst, super! Dass es UML sein muss, ist schon die allererste Fehlannahme. Es ist völlig egal, ob es irgendeiner formalen Vorschrift genügt. Sobald man anderen was damit erklärt, muss man wieder was dazu erzählen und spätestens dabei wird jedes Wirtschaftler-Geblubber gnadenlos enttarnt.
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.
Nach dem, was du hier aufzählst, bist du ein Software-Entwickler. Die Putzfrau macht auch keine höhere Arbeit, wenn sie Sanitärbeauftragte heißt. Klar ist die Arbeit vielseitig und man sitzt nicht nur vor dem Computer und tippt. Dafür braucht man sich aber nicht für jede Tätigkeit einen neuen Buzz-Namen ausdenken, sonst bist du irgendwann Direct art and Production support and Product senior stylistic supervisor.
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.
Das hättest du auch mit weniger gebuzze sagen können, oder? Ist das eigentlich eine dumme Angewohnheit von dir? Redest du mit jedem so? Kann man sowas ernst nehmen? Hätte es das rein deutsche Äquivalent nicht getan? Hättest du nicht einfach schreiben können "Wie kann ich Zusammenhänge zwischen Code und einer CAD-Zeichnung nachvollziehen, überblicken und warten"? Oder ist die Entropie (Informationsgehalt pro Datenmenge) dieser Botschaft doch höher als angenommen?
Genau das ist der Vorteil von Visualisierungen!
Der Vorteil von Visualisierungen im Allgemeinen wird nicht abgestritten.
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 ...
Wir auch nicht. Wir verwenden Bugtracking-Systeme, Versionskontroll-Systeme, ja manchmal sogar mach ich einen Rechtsklick in Visual Studio und schau mir das Klassendiagramm (nicht UML-konform) an. Das kann man alles jeder für sich machen, da braucht man keinen Manager, der jetzt dick auflabert und sich auf UML was einbildet.
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 [tun?]. Das Du eine Codezeile schneller ändern kannst?!
Jetzt auf einmal wieder so pragmatisch? Du erinnerst mich die meiste Zeit eher an einen Manager, der seine Mitarbeiter anweist "mach' mir mal ein UML-Diagramm, damit ich ..Roundtrip-Engineering...Domainmodellen...Stakeholder...bidirektionale Traceability...remarks...Changemanagement ... kann." und danach wird es zu den Akten gelegt. Sowas ist einfach nur g'schaftlig.
UML kann man schon hernehmen, wenn man sich an der umständlichen Notation nicht stört aber gespickt mit Buzzwords und Wichtigtuerei kommt es zu oft in die Hände von Leuten, die glauben, dass es ohne gar nicht mehr geht. Und das ist das Problem bei UML. Die Idee, ein paar Notationen zu vereinheitlichen, mag ja nicht verkehrt sein (auch wenn ich mich Frage, zu welchem Problem das die Lösung ist). Aber die Wirtschaftler haben es schon für sich entdeckt und Marc++us sagte schon einmal treffend, dass du bereits die dunkle Seite betreten hast.
-
lucky_tux schrieb:
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.
Es ist fraglich, ob UML genau dieses Problem wirklich löst. Ist es wirklich das Problem, dass ich etwas nicht als Klasse verstehen kann, wenn du den Kasten eckig machst und ich rund?
Ich glaube, dass Kommunikationsprobleme mehr high-level sind, wenn man eine Lib für irgendwas plant, dass die Leute unterschiedliche Vorstellungen haben, wie man sowas benutzen soll, wenn es fertig ist. Solche Probleme löst UML nicht. Ein Klassendiagramm kann ich schon lesen und ich lache auch keinen aus, wenn er nicht weiß, dass '#' protected heißt, nur weil es unsinnigerweise Sprachneutral erzwungen wird.
-
Gerade als Programmierer verwendet man doch die ganze Zeit fachspezifische Fremdwörter die sonst niemand versteht. Erklärt seinem Chef warum das Projekt so toll ist indem man 10 neue Technologien, Design Pattern und sonstigen für den Chef absolut unwichtigen Unfug erzählt und regt sich im selben Satz darübe auf, dass der Chef seine eigene Fachsprache verwenet die man selbst nicht verstehen kann.
Wer es noch nicht gesehen hat: Die Abteilung der Programmierer ist in der Firma eindeutig das untere Ende der Nahrungskette. Hauptziel ist es nicht möglichst viele tolle und schöne Programme zu schreiben sondern dem Kunden die Software - so dämlich und buggy sie auch ist - zu verkaufen.
MfG SideWinder
-
Optimizer schrieb:
Es ist fraglich, ob UML genau dieses Problem wirklich löst. Ist es wirklich das Problem, dass ich etwas nicht als Klasse verstehen kann, wenn du den Kasten eckig machst und ich rund?
Ist es wirklich das Problem, dass jemand "void main()" schreibt und der andere "int main()" wenn der Compiler doch eh das gleiche draus macht? Nein? Richtig. Trotzdem hat man sich halt mit UML auf einen Visualisierungsstandard geeinigt. Was ist daran so schlimm?
MfG SideWinder
-
@SideWinder: Studierst du Wirtschaftsinformatik?
-
Nein.
MfG SideWinder
-
Sehe gerade, du bist noch Schüler. Was willst du mal studiern?