UML - Buzzword für Manager?

SideWinder

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

Marc++us

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?

volkard

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.

SideWinder

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

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.

SideWinder

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.

finix

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

Gregor

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.

Marc++us

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.

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.