UML - Buzzword für Manager?

SideWinder

Den Vergleich mit den Maurern habe ich gebracht als es um die BWL-Fachsprache von prof84 ging.

MfG SideWinder

the_menace

ich persönlich fände die Idee einer vereinheitlichten Sprache schon ganz gut, um Software(-Module) abstrakt zu beschreiben. Aber da gibt es ein paar Dinge, die mich furchtbar ankotzen.
1. für mich ist UML noch weit von einem stringentem Standard entfernt. Es wird ja auch immer weiter dazugepappt. Als ich Softwaretechnik belegt hab, vor ein paar Semestern, gabs schon UML 2, und das wurde dann auch mal erörtert ..
Manche machen jetzt das eine UML, andere das andere. Was ich für ebenso gefährlich halte, weil man denkt, man hat die gleiche sprache, die es ja dohc nicht ist.

2. abstraktion macht nur bis zu einem gewissen grad sinn. das merkt man manchmal auch bei pseudocode. da schreibt man manchmal nen code hin, der in der abstraktion super elegant aussieht, und sinn macht, aber dann in der wirklichen programmierung total sperrig ist, und sich schlecht "auf den Maschinencode abbilden" lässt, oder realiter ziemlich ineffizient ist.

Ich glaube, bis eine wirklich vereinheitliche Abstraktionssprache verwendbar ist, müssen noch 10-15 jahre in der software entwicklung ins land gehen, damit man die schwächen und stärken der Abstraktionen wirklich erkennt..

jm2c

ps: ich hab auch noch nie UML anfassen muessen, ausser in software technik. da haben wir es gelernt, und im vortrag wurden wir vom prof angeschissen, weil wir das angeblich falsch gemacht hatten. nunja... es war nicht sein lieblingsbuch, wo wir die uml-sachen raus hatten.

Gregor schrieb:

BTW: Wenn man sich mal den Inhalt von Hochschulstudien ansieht, stellt man fest, dass ein erheblicher Bestandteil davon das Lernen der Fachsprache(n) des jeweiligen Gebiets darstellt. Wenn man irgendwann mal ne mündliche Prüfung hat, dann fragt der Prüfer meistens genau das ab: Er versucht herauszufinden, ob sich der Prüfling in der entsprechenden Begriffswelt zurechtfindet, ob er mit den Begriffen etwas anfangen kann und ob er sich mit diesen Begriffen ausdrücken kann.

Nee, so entschärfst Du den Sinn der Fachsprache:
An jeden Fachbegriff sind feste Modelle und ein Konzept geknüpft. Du hast den Bachman/Levesque selber im Regal stehen. Überfliege Kapitel 2 - "The Language for First-Order Logic" und Kapitel 3 - "Expressing Knowledge". Aber noch besser gefiel mir
Conceptual Spaces | ISBN: 0262572192
zu diesen Thema. Der Prüfer fragt die Fachsprache ab, weil der Kandidat so Kenntnisse von Modelle und Konzepte bestätigt und der Prof so schnell ein Konzept für Aufgabenstellung und Problembeschreibung bauen kann.

Aber schalten wir die Abstraktionsstufe einen Gang runter in die Domain UML:
Deshalb räume ich Erik Evans -
Domain-driven Design | ISBN: 0321125215
so einen Stellenwert in der Literatur im SW-Engineering ein. Sein Konzept eine "Ubiquitious Language" einzuführen, die das Model-Driven Design mit den der gemeinsam genutzen Sprache zu verbinden, um ein Konzept von Patterns für Large-Scale-Structure, Context, Destillation, Supple-Design und Building Blocks zu entwickeln, kommt für mich gleich nach Design-Patterns oder POSA 1.

Gregor schrieb:

Wenn man sich nur schnell mal eine Skizze machen möchte, um sich selbst etwas zu visualisieren, braucht man sicherlich kein UML. ...sofern die Skizze danach dann auch im Mülleimer landet und nicht in irgendweiner Art von Dokumentation. Aber als Kommunikationsmittel sind solche individuellen Skizzen IMHO eher weniger geeignet.

Nee, genau das ist die falsche Einstellung:

Es existieren auch noch andere Modellstandards außer UML. Denk an die Mathlab/Simulink Entwicklung, ARIS, ER-Diagramme, SADT oder Petri-Netze.
Die konzeptionelle Modelle, die Du erstellst sind in lesbarer oder E-Form sogar wertvoll, wenn Du Dich außerhalb der SW-Domain bwegen mußt. Problem - der E-Techniker kommt Dir mit einen Schaltplan und Ihm mit einen UML Diagramm und man will jetzt ein gemeinsames Konzept entwickeln => Konzeptionelle Modellierung, Requirements Engineering. Deshalb verwandt ich bisher in meinen Reports außerhalb der SW-Domain Visio Illustrationen und kein UML. Klappt sehr gut.
Der aktuelle Trend - bei der sogenannten Domain-Spezific Modeling (DSM) ist es das Modelling an die Problem-Domain heranzuziehen. Die Modelle wird über die Modellierung eines Jargons oder Domain-Specific Language (DSL) standardisiert
http://en.wikipedia.org/wiki/Domain-specific_modelling
http://www.sigs.de/publications/os/2004/04/tolvanen_kelly_OS_04_04.pdf#search="Domain Specific Modelling"
Ich habe selbst Hrn. Dr. Tolvanen aus Finnland kommen lassen und bei Siemens eingeführt.

the_menace schrieb:

1. für mich ist UML noch weit von einem stringentem Standard entfernt. Es wird ja auch immer weiter dazugepappt. Als ich Softwaretechnik belegt hab, vor ein paar Semestern, gabs schon UML 2, und das wurde dann auch mal erörtert ..
Manche machen jetzt das eine UML, andere das andere. Was ich für ebenso gefährlich halte, weil man denkt, man hat die gleiche sprache, die es ja dohc nicht ist.
...
Ich glaube, bis eine wirklich vereinheitliche Abstraktionssprache verwendbar ist, müssen noch 10-15 jahre in der software entwicklung ins land gehen, damit man die schwächen und stärken der Abstraktionen wirklich erkennt..

Mit der UML2 kannst mit Hilfe des Profiling Features ausblenden oder erweitern im Metamodell, um den Standard gefügig zu machen zu Tools oder Vorgängerversionen.
UML stellt auch nicht den Anspruch für alles gewappnet zu sein. Ein typisches Beispiel ist die Einführung des neuen SysML Standards http://sysml.org/ .
Warum gibt es unzahlige ISO und IEEE Standards und nicht einen Zusammenfassenden?! Aus dem selben Grund wird es nie einen alles umfassenden Modellierungsstandard geben, sondern immer ein Bestreben sehr viele Standards frei aber systematisch zu verbinden.

Marc++us schrieb:

Und da regen sich natürlich all die Personen auf, die hier a) bewußt aus dem Kreis ausgeschlossen werden sollen und b) die die Begriffe verstehen und erkennen, daß für dieses Themengebiet - anders als bei etwas Neuem - gar keine zusätzlichen Begriffe hätten eingeführt werden müssen, daß es eine reine modisch klingende Umbenennung ist.

A ist aber genau meine Absicht!
Ich will nicht, dass Member die den entsprechenden Horiziont zum Thema meines Posts nicht besitzen Ihren Senff dazugeben und so ist auch meine Sprache ausgelegt. Meine Posts sind nicht für volkard oder Optimizer gedacht. Nicht meine Zielgruppe. Das ist das Gute an einen Board - Jeder kann auf alles antworten, aber keiner muss. Ich bin hier auch kein Coach, Dozent oder Trainer, der tagelang jeden Idiot alles erklärt. Also: Ist der Kommunikationskanal zu hoch - Ignorieren! Ist der Kommunikationskanal zu niedrig - Ignorieren!

Mit B habe ich wohl nichts zu tunen. Denn ich verwende nur Begriffe des gängen Jargons und die im Netz bzw. Literatur nachschlagbar sind!

In diesem Forum gibt es keinen einzigen der deiner Zielgruppe angehört.

Ich habe den Thread mal gelesen und muss sagen, dass keins der Argumente wirklich gegen die UML spricht, viele jedoch dafür. Vielleicht sollten jene, die UML für Unnütz und Zeitverschwendung halten, die Sprache mal nicht nur auf Klassendiagramme beschränken.

DocJunioR

Das ist nicht mal das Problem. Trollbeitrag oder nicht, j2mc hat irgendwie recht.
Der Entwickler, wie die meisten Programmierer aus diesem Board welche sind, fühlt sich mehr oder weniger vom UML in seinem Lebensraum bedroht.
UML stellt eben nicht nur irgendetwas dar, es trennt auch Rollen.
Der normale Programmierer meint, gar keine Zeit zur Nutzung von UML zu haben und hat damit eigentlich sogar recht. Ihm wird durch UML die Zeit allerdings nicht gestohlen, sondern geschenkt. Diese Diagramme sollen nämlich garnicht von ihm erstellt, sondern nur von ihm interpretiert und umgesetzt werden.
Die kreative Arbeit liegt bei einer ganz anderen Rolle. Dem Desginer.
Genau das ist widerum ein Problem.. Wie soll ein Programmierer mit seinem Können glänzen, wenn das Programm eigentlich schon auf Papier steht?
Die Möglichkeit zu kreativem Ausdruck wird dem Programmierer offensichtlich entzogen.
Naajaaa.. eigentlich eher verlagert, weil ein richtiges PAP ist in UML nicht drin- und wirds auch nicht. Der Programmierer darf also mit seinem Können glänzen "Hier hab ich 12 Zeilen Code eingespart und da gleich ganze 2.325 Sekunden"

Trotzdem- es bedarf in dieser Hinsicht eines Umdenkens oder Umorientierens der Programmierer.
Außerdem kann UML nur "gelebt" werden, wenn das Projekt auch eine solche Trennung vorsieht. Ein Programmierer, der sich auch noch mit bunten Bildchen auseinandersetzen soll ist wirklich arm dran, weil er eigentlich besseres zu tun hat.

Genau das ist widerum ein Problem.. Wie soll ein Programmierer mit seinem Können glänzen, wenn das Programm eigentlich schon auf Papier steht?

Das ist ein guter Punkt, und es geht ja noch weiter. Denn es existieren ja längst Programme, die daraus Code erzeugen. Ich persönlich kenne zwar nur Rhapsody, aber da hat das damals schon ziemlich gut geklappt. Rhapsody erzeugt aus Klassen-/ Objektdiagrammen und Statecharts bei Bedarf C++ oder Java Code.

DocJunioR

Was aber eigentlich auch wieder eine Funktion ist, die das Rollenkonzept der J2EE- was ja mehr oder weniger auch Anlaß zur Forcierung von UML war- untergräbt..
Der Designer hat gefälligst die Pfoten von der Generierung des Quellcodes zu lassen. Dafür gibts Programmierer.

http://www.thedailywtf.com/images/200608/stateModel.gif

DocJunioR

Ich denke, das ist entweder das Ergebnis eines reverse engineering oder die Arbeit eines ziemlich unfähigen Designers ^^

byto

Oder etwas ganz anderes, denn erkennen kann man nix und im übrigen stammt der Reply auch nicht von mir.

Hmm - ich finde eigentlich nicht, dass dadurch das Rollenkonzept verletzt wird. Für mich macht UML eigentlich sogar hauptsächlich dann Sinn, wenn auch Code daraus generiert werden kann bzw. wenn Modelltransformationen möglich sind, die für mich produktiv auch was nutzen. UML-Diagramme nur für die Dokumentation ist imho strunzig... davon hab ich nix. Wenn ich hingegen per Roundtrip Engineering Klassendiagramme erstelle bzw. sich daraus meine Klassenrümpfe erstellen lassen, dann ist das nen erheblicher Vorteil gegenüber manuellem Gemale, ausdrucken und dem Programmierer vorbeibringen ... genauso bei Statecharts oder Entwicklungen im Bereich Avionik (Flugzeugelektronik) oder Autobau... dort muss man allein aus sicherheitsaspekten formaler entwickeln. Und ein formal stimmiges Modell (Diagramm) nutzt mir dann nicht, wenn ein Programmierer es nur halb formal umsetzt, sprich er interpretiert es falsch, weil er eben auch nur nen Mensch ist... schwupp sind Modell und Realität nicht mehr konform und ich hab abstürzende Flugzeuge, weil die Stewardess bei einem Neigungswinkel von 23° die Mikrowelle geöffnet hat (wie konnte sie nur!)

Mir wird das hier alles ein wenig zu bunt. Ich habe den Eindruck das die Personen, die eher zu einer positiven Einstellung im Bezug auf die UML neigen, die Anderen zu belehren versuchen wie wichtig und unersetzbar diese Sprache ist. Und das gleiche vice versa. Es gibt keine korrekte und präzise Antwort auf die Frage ob die Verwendung dieser Analyse- und Designsprache sich als sinnvoll erweist oder nicht. Auch ob es Nutzen in einem Unternehmen macht lässt sich nicht Veralgemeinern. Genauso schaut es aus mit dem persönlichen Nutzen. Ich finde, dass wenn einen die UML für persönliche Aufgaben (auch kleinere Blöcke eines großen Projekts in Unternehmen) weitbring, warum sollte dann etwas dagegen gesagt werden. Alles andere und weitere unqualifizierte Äußerungen bedürfen keine weiteren Kommentare. Im Endeffekt würde diese Diskussion eh keinen eingefleischten UML-Nutzer davon abhalten diese Sprache zu verwenden.

Ich denke die Diskusion sollte nun langsam gegen Ende zugehen, da nun etliche wichtige Aspekte genannt wurden und wir uns nicht mehr weiter bewegen.

SideWinder

@lucky_tux: Die Frage bekommt eben langsam aber sicher den Status einer "Java vs. C++"-Frage *g*

MfG SideWinder

volkard

SideWinder schrieb:

@lucky_tux: Die Frage bekommt eben langsam aber sicher den Status einer "Java vs. C++"-Frage *g*
MfG SideWinder

ich halte java für langlebiger als uml. die frage bekommt langsam den status von "soll man ungarische notation benutzen?". die argumente für UN ähneln denen für UML übrigens enorm.

Gregor

jm2c schrieb:

In diesem Forum gibt es keinen einzigen der deiner Zielgruppe angehört.

Also ich finde es interessant, was Prof84 zu sagen hat.

...und es wäre doch auch äußerst langweilig, wenn in diesem Forum nur eine Einheitsmeinung vertreten werden würde, findest Du nicht? Es ist wichtig, sich auch anderen Sichtweisen gegenüber offen zu zeigen, sonst kommt man in seiner Entwicklung zu einem Stillstand.

Mir kommt es hier irgendwie so vor, als ob viele hier eine Ideologie vertreten, die ähnlich wie z.B. Dijkstras Brandmauer der Informatik ihren eigenen Wirkungskreis komplett eingrenzt und große Barrieren zu allem zieht, was links und rechts davon liegt. Es wirkt so, als ob hier einige einen totalen Tunnelblick auf die Domäne haben, in der sie sich beheimatet fühlen.

@Gregor: Das ist aber sehr undifferenziert, was du schreibst. Es geht doch nicht darum, alle fremden Ideen abzulehnen, sondern nur darum, unsinnige herauszufiltern.

volkard

tunnelblick? so kann mans's auch nennen, wenn jemand nicht an homöopathie, alchemie, wünschelruten und astrologie glaubt.

lucky_tux schrieb:

Es gibt keine korrekte und präzise Antwort auf die Frage ob die Verwendung dieser Analyse- und Designsprache sich als sinnvoll erweist oder nicht.

Find ich schon. Ich kann mir persönlich nicht vorstellen, dass ich den Überblick über ein Framework mit >100 Klassen halten kann, wenn ich kein Klassendiagramm dazu hab, bzw. ob ich dann noch Aussagen treffen kann, ob das Produkt vom Design her vernünftig ist oder nicht. Plus ich kann mir nicht vorstellen, dass das ne Firma heute noch ohne zulässt, aber trotzdem ne QS Abteilung besitzt ;).
UML ist ein Hilfsmittel zum Entwerfen von Software - aber auch keine eierlegende Wollmilchsau... neben der UML gibts sicherlich auch noch weitere DSLs die für die ein oder andere Situation geeignet erscheinen - daher finde ich persönlich den MDA Ansatz zur Modelltransformation auch am schickesten. Egal wer jetzt mit wem in welcher Sprache redet, man kann mit Hilfe geeigneter Transformationen in beliebige andere Sprachen übersetzen, sprich - meinetwegen können die Manager in BPEL sprechen, ich muss es nicht mehr unbedingt verstehen, bzw. zumindest "meine" Programmierer müssen den Mist nicht auch noch lernen

Gregor

volkard schrieb:

tunnelblick? so kann mans's auch nennen, wenn jemand nicht an homöopathie, alchemie, wünschelruten und astrologie glaubt.

Das hat hier nichts mit Glauben zu tun. Es geht hier mehr darum, dass ein Programmierer eben auch in einer gewissen Umgebung existiert. Und in dieser Umgebung existieren auch Nicht-Programmierer. Zum Beispiel auch BWLer und alle anderen Arten von Menschen, die hier verabscheut werden. Es ist IMHO eine Fehlannahme, dass sich ein Programmierer nicht auf diese Leute einlassen muss, mit Ihnen kommunizieren muss usw.. Diese Leute haben massiven Einfluss auf die Arbeit des Programmierers und deshalb wäre es besser, sich als Programmierer nicht völlig von dieser "Außenwelt" abzukapseln. Das bedeutet auch, dass man ein Interesse daran haben muss, den anderen zu verstehen.

Mir kommt es hier allerdings eher so vor, als ob dieses Interesse bei vielen nicht da ist. Da zieht man jede Art von "Buzzword-Bashing" einem Versuch vor, sich auf die Begriffswelten des Gegenübers einzulassen. Der BWLer wird hier als Feind wahrgenommen oder zumindest dargestellt. Das ist doch keine Basis für eine Zusammenarbeit.

@volkard: Ich weiß nicht, ob Du dich durch meine Tunnelblick-Äußerung angesprochen gefühlt hast. Ich hatte dabei eigentlich keine Einzelperson dieses Forums im Auge. Das war lediglich eine Art Gesamteindruck, den ich in Buzzword-BWL-sonstwas-Diskussionen wie dieser hier immer wieder bekomme.