UML - Buzzword für Manager?
-
SideWinder schrieb:
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.
Da bricht jetzt glatt ne Welt für mich zusammen. Und die Leute, die Mikrowellenessen produzieren wollen garnicht total leckeres und hochwertiges Essen produzieren sondern nur Geld verdienen? Das ist aber gemein!
So funktioniert *jede* Firma.
-
hmmm... Ich schließe mich mal grob den Sichtweisen von SideWinder und Prof84 an.
1. Ich halte UML für wichtig und gut. Und zwar immer dann, wenn es darum geht, bestimmte Strukturen oder Abläufe zu dokumentieren oder darüber mit irgendwem zu kommunizieren. Es ist wichtig, dafür eine standardisierte Sprache zu haben. Das beugt Missverständnissen vor (die Voraussetzung ist natürlich, dass alle Beteiligten diese Sprache sprechen). Es geht dabei nicht so sehr darum, ob UML nun die absolut beste Sprache für diesen Zweck ist, es geht mehr um die Standardisierung. UML ist anderen gleichwertigen Sprachen vorzuziehen, weil sie sich einfach durchgesetzt hat. Es sprechen nunmal sehr viele Leute UML, UML ist gut dokumentiert und UML wird in den Hochschulen gelehrt. 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.
BTW: Es gibt ja auch in anderen Bereichen standardisierte Sprachen und das aus gutem Grund. Man stelle sich vor, im Flugverkehr kommt es zu irgendeinem Missverständnis. Soetwas kann ganz schnell zu einer Katastrophe führen. Und deshalb ist auch dort der Ablauf des Funkverkehrs sehr genau standardisiert. Ähnliches gilt für das Militär: Auch da ist die Kommunikation standardisiert.
2. Ich halte Fachsprachen und die Beherrschung dieser generell für wichtig und gut. Die Gründe sind praktisch genau die gleichen wie bei der UML. Mit einer passenden Fachsprache kann man sich unmissverständlich ausdrücken. Begriffe sind eindeutig definiert und müssen nicht immer wieder bei jedem Gespräch neu erarbeitet werden. Wie will man halbwegs effizient - in einem Team - arbeiten, wenn man keine Sprache hat, die dafür geeignet ist? Wie will man zu sinnvollen Gedanken in einem Gebiet kommen, wenn einem dafür die Sprache fehlt? Dumm ist es nur, wenn einem diese Fachsprache so sehr in Fleisch und Blut übergeht, dass man sie auch in anderen Zusammenhängen verwendet. Oder auch bei der Kommunikation mit Leuten, die diese Sprache nicht sprechen. Die würden das dann wohl nur als so eine Art Buzzword-Geplapper auffassen. Es kommt also immer auf den Zusammenhang an. Wenn Prof84 von "Profis" oder ähnlichem spricht, dann kann man aber davon ausgehen, dass jeder, der in diesem Zusammenhang gemeint ist, die entsprechende Sprache, sei es nun die UML oder eine andere Fachsprache, sprechen können sollte. Unter Profis ist das deshalb eindeutig auch die passende Kommunikationsgrundlage.
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.
-
First-Class-Posting
<OT>
Edit:Jester schrieb:
So funktioniert *jede* Firma.
Ich verstehe dann aber nicht wieso in der Baubranche die Maurer nie am Design des Gebäudes rütteln wollen sondern strikt die Mauer bauen die ihnen aufgetragen wurde? Die Programmierer sind die einzigen Handwerker die rund um die Uhr in der Planung herumpfuschen wollen "weil es so ja viel besser geht" *g*
</OT>MfG SideWinder
-
Gregor schrieb:
2. Ich halte Fachsprachen und die Beherrschung dieser generell für wichtig und gut. ... Oder auch bei der Kommunikation mit Leuten, die diese Sprache nicht sprechen. Die würden das dann wohl nur als so eine Art Buzzword-Geplapper auffassen. Es kommt also immer auf den Zusammenhang an.
Da wäre ich vorsichtig.
Du gehst davon aus, daß erst das Fach da war, und danach die standardisierte Sprache eingeführt wurde, damit man sich über Fachspezifika in eindeutig definierten Begriffen unterhalten kann.
Inzwischen wird aber auch eine andere Form der Fachsprache gepflegt, die dadurch entsteht, daß man eine Sprache schafft, um ein Gebiet zu "emanzipieren" oder eben auch um durch eine Fachsprache die eigene Kommunikation für Außenstehende unverständlich zu machen, oder auch um Inhalte zu verschleiern. Hier wird die auf technischem Gebiet teilweise notwendige Fachsprache dazu benutzt, um eine neue Ebene zu schaffen, die sachlich gar nicht existiert. Es ist mehr eine Formalsprache.
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.
-
SideWinder schrieb:
Ich verstehe dann aber nicht wieso in der Baubranche die Maurer nie am Design des Gebäudes rütteln wollen sondern strikt die Mauer bauen die ihnen aufgetragen wurde? Die Programmierer sind die einzigen Handwerker die rund um die Uhr in der Planung herumpfuschen wollen "weil es so ja viel besser geht" *g*
Wir haben festgestellt, dass du Schüler bist, also arbeitest du nicht in einer Firma, in der die einen Planen und die anderen programmieren.
Arbeitet irgendwer in einer Firma, in der es Leute gibt, die wirklich nur zum Schreiben von Code da sind und andere die wirklich nur die SW planen?
-
SideWinder schrieb:
Ich verstehe dann aber nicht wieso in der Baubranche die Maurer nie am Design des Gebäudes rütteln wollen sondern strikt die Mauer bauen die ihnen aufgetragen wurde? Die Programmierer sind die einzigen Handwerker die rund um die Uhr in der Planung herumpfuschen wollen "weil es so ja viel besser geht" *g*
niemals würde ein wirtschaftler dort sagen "diese talbrücke arbeiten wir als hängebrücke aus, sie hat drei stützen dort, dort und dort..." oder wie ein hochhaus gebaut wird. nein, er trägt das fachleuten (architekten und statikern) auf. er verwirft viele vorschläge, versucht auch zu ändern, aber doch in grenzen. bei der software ist es so, daß die wirtschaftler selber sich ahnung zumuten und bis ins detail planen, was welches modul machen soll. das kommt noch von der killerapplikation dazumal, der lohnbuchhaltung, die zur massiven einführung von computern geführt hat.
-
JetztMalKlartext schrieb:
Wir haben festgestellt, dass du Schüler bist, also arbeitest du nicht in einer Firma, in der die einen Planen und die anderen programmieren.
Wie kommst du zu deinem "also"-Entschluss?
Arbeitet irgendwer in einer Firma, in der es Leute gibt, die wirklich nur zum Schreiben von Code da sind und andere die wirklich nur die SW planen?
Ja. Jedes Jahr 1 Monat Vollzeit in den Ferien und neben der Schule mehr "freie Mitarbeit" je nach Zeit.
MfG SideWinder
-
Damit das jetzt nicht falsch verstanden wird: Die Planen dort aber nicht im Detail sondern eher Dinge wie Feature-Anforderungen, etc. übernehmen dann auch gleich den Kundensupport und stehen somit fachlich mit dem Programm in Verbindung. Die Programmierer sind für die technische Seite zuständig.
UML kommt allerdings nur selten vor (Klassendiagramme, kurze grobe Ablaufsdiagramme, etc.)
MfG SideWinder
-
Na als Schüler "zählst" du nicht als "richtiger Mitarbeiter" der dazu geeignet ist irgenwelche (Teil)Projekte zu planen. Solchen werden meistens nur kleine Teilaufgaben geben.
SideWinder schrieb:
Damit das jetzt nicht falsch verstanden wird: Die Planen dort aber nicht im Detail sondern eher Dinge wie Feature-Anforderungen, etc. übernehmen dann auch gleich den Kundensupport und stehen somit fachlich mit dem Programm in Verbindung. Die Programmierer sind für die technische Seite zuständig.
Das meine ich ja. Ich glaube nicht, dass es möglich ist, dass irgendwelche Informatiker ein geniales UML-Diagramm mit ca. über 200++ Seiten erstellen, das dann an die dummen Programmierer gegeben wird und die den Code tippen.
-
Dafür ist UML imho auch nicht gemacht:
Seite 1, Antwort #3:
SideWinder schrieb:
(Jede Funktion vorher mit UML und einem Aktivitätsdiagramm zu zeichnen ist hingegen dämlich).
Aber was spricht dagegen ein Klassendiagramm in einem standardisierten Visualisierungsformat zu zeichnen?
MfG SideWinder
-
Gar nichts, ich wüsste auch nicht, wer sich dagegen geäußert hat.
Das negativste dazu war möglicherweise von mir mit (sinngemäß) "naja nett, aber welches Problem löst es?".Wir wollen nur feststellen, ob UML zuviel von Wirtschaftlern benutzt wird um dick auflabern zu können. Da muss ich dann eigentlich nur die Posts von Prof84 lesen und für mich ist die Antwort schon mal klar.
-
Marc++us schrieb:
Inzwischen wird aber auch eine andere Form der Fachsprache gepflegt, die dadurch entsteht, daß man eine Sprache schafft, um ein Gebiet zu "emanzipieren" oder eben auch um durch eine Fachsprache die eigene Kommunikation für Außenstehende unverständlich zu machen, oder auch um Inhalte zu verschleiern. Hier wird die auf technischem Gebiet teilweise notwendige Fachsprache dazu benutzt, um eine neue Ebene zu schaffen, die sachlich gar nicht existiert. Es ist mehr eine Formalsprache.
Definiere 'sachlich existent'.
-
Optimizer schrieb:
Wir wollen nur feststellen, ob UML zuviel von Wirtschaftlern benutzt wird um dick auflabern zu können. Da muss ich dann eigentlich nur die Posts von Prof84 lesen und für mich ist die Antwort schon mal klar.
Ich glaube, wenn Du Prof84 als Wirtschaftler abstempelst, dann tust Du ihm Unrecht.
-
SideWinder schrieb:
Aber was spricht dagegen ein Klassendiagramm in einem standardisierten Visualisierungsformat zu zeichnen?
Hängt davon ab.
Unter Umständen viel, wenn es keine zusätzlichen Informationen enthält. Oftmals wird UML mittels Tool dazu eingesetzt, am Ende das Projekt "zu dokumentieren". Das ist völliger Unfug, da auf diese Weise die Existenz einer Dokumentation nur simuliert wird und bzgl des Informationsgehalts zwischen der Darstellung als Code und der Darstellung als Grafik kein Unterschied besteht.
-
Gregor schrieb:
Optimizer schrieb:
Wir wollen nur feststellen, ob UML zuviel von Wirtschaftlern benutzt wird um dick auflabern zu können. Da muss ich dann eigentlich nur die Posts von Prof84 lesen und für mich ist die Antwort schon mal klar.
Ich glaube, wenn Du Prof84 als Wirtschaftler abstempelst, dann tust Du ihm Unrecht.
Jo, ich glaube auch und möchte das ein bisschen zurücknehmen. Aber dick auflabern tut er ja schon.
-
Optimizer schrieb:
Aber dick auflabern tut er ja schon.
Allerdings. Und für einen BWL-Hasser wie mich (oder jede andere kluge Person) liest sich das einfach nur noch peinlich
-
SideWinder schrieb:
Dafür ist UML imho auch nicht gemacht:
Dafür meinst du
Ich glaube nicht, dass es möglich ist, dass irgendwelche Informatiker ein geniales UML-Diagramm mit ca. über 200++ Seiten erstellen, das dann an die dummen Programmierer gegeben wird und die den Code tippen.
Aber du hast doch diesen Vergleich mit den Maurern gebracht und damit der funktionieren kann müsste UML doch sowas wie der Bauplan für die Softwaremaurer sein.
-
Den Vergleich mit den Maurern habe ich gebracht als es um die BWL-Fachsprache von prof84 ging.
MfG SideWinder
-
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!