UML <--> Operatoren, Konstruktoren, etc...
-
-
Hi Volkard,
zurück zum Ausgangspunkt. Ich bekenne, ich bin, kein Fan, aber regelmässiger
"Anwender" von UML. Ich habe damit gute Erfahrungen gemacht. Wie das? Nun es
wird bei uns keine Software durch UML erstellt. Aber UML ist ein Kommunikationsmittel.
Auf der "einen" Seite Entwickler + Projektleiter(Entwicklung) auf der "anderen"
Seite der Kunde bzw sein Projektleiter und der "Projektverantwortliche" aus
unserem Haus. Das heisst die eine Seite ist mit "Wirtschaftlern" besetzt die
mehr oder weniger genauer Vorstellungen haben was sie wollen, und die andere
Seite mit Technikern die das Ganze implementieren sollen. Und UML hat sich nach
meinen Erfahrungen als adäquate Form der Kommunikation herausgestellt. Ich
(Entwickler) bin dadurch in der Lage meine Ideen dem Kunden oder zumindest
"unserem Mann" beim Kunden verständlich zu machen. Und umgekehrt ist diese
formaler Methode auch geeignet damit ich möglichst eindeutig die Anforderungsspezifkation,
in UML-Form präsentiert, "rauslesen" kann. Die Modellierung erfolgt bei uns nicht
bis zur Codegenerierung sondern bis "knapp" davor. Sicherlich entstehen Methoden
die nicht vorgesehen waren und auch ganze Klassen, das vorgegebene Gesamtbild
bleibt jedoch durchaus erhalten.Der Vorteil von UML gegenüber anderen Methoden ist meines Erachtens:
- UML ist allgemein anerkannt, Jeder der im Rahmen des Studiums mit Software
zu tun hat , "lernt" die Grundbegriffe. Aufgrund des "Hype" sind viele
Firmen auch bereit fehlendes Wissen ihrer Mitarbeiter nachzuschulen.
- UML kann Beziehungen verschiedenster Art ausdrücken. Ob "Use cases" oder
Sequenzdiagramme oder Klassendiagramme und damit ein weites Spektrum
innerhalb der Projektentwicklung visualisieren.Um es nochmals deutlich zu machen. UML implementiert NICHT aus ein paar
"Use cases" oder "Klassendiagrammen" die fertige Software. Das Wissen über
UML ersetzt auch KEINE Programmiersprache. Es dient lediglich zur Kommunikation
und erfüllt diesen Zweck leidlich gut, das heisst eine bessere Alternative
habe ICH für mich bislang nicht gefunden.
-
Ich finde UML ist toll für die Planung und für die Dokumentation.
Für Details taugt sie nix. Dafür hat man sie aber auch nicht erfunden.
Wenn man eine Software plant, finde ich es einfach nett, wenn man
sich einfach die Klassen erstellen kann, abhängigkeiten einzeichnen,
und dann sieht ob das ganze Sinn macht. Methoden und Variablen
sind dann für die Doku nett, aber da ist eine gute DoxyGen Doku
um längen besser.
-
Optimizer schrieb:
Mit sowas gewinnst du aber in einem Forum voller Techniker keinen Blumentopf. Wir wollen Informationen, in kompakter Form, am besten mit Entropie = 1. Die von mir zitierte Aussage hat eine Entropie von 0 gehabt. Wie man leicht feststellen kann, wenn man Software Engineering Vorlesungen besucht, kann man jeden Begriff völlig unterschiedlich definieren und jeder tut es auch.
Wieso glaubt die ganze Welt man könne jeden Zusammenhang erklären, wenn nur 2-3 Disziplinen aufeinander stellt?
Ich habe jeden Tag mit dem Problem zu kämpfen:In jeden Meeting bestehend aus hochintelligenten Leuten - Technikern, Ingenieuren, Wissenschaftern, Managern und viele mit Promotion - geht nur etwas durch den Inputfilter, wenn ich es auf einer einzigen "VKLF - Folie" (" Vorstand, Kinder, Land, Frauen") packen kann. D.h. wenn Du in der Entscheidungshierachie nicht weit oben stehst, hast Du sofort verloren.
Deshalb hat es keinen Sinn einzelne Einflussvektoren zu diskutieren, wenn man sich noch nicht einmal über die Basics verständigen kann. Dann muss ich ein 30-Seiten-Report schreiben. Und wenn in diesem in der Taxonomie dann oben nicht die "Buzzwords" stehen die sie kennen, die in Wirklichkeit nur ein Jargon einer anderen Domaine sind, landet der nach der ersten Seite in den Reißwolf. Erkenntnis muss halt unter Aufwand erarbeitet werden.
Das ist der Unterschied zwischen Wissen und Weisheit!
-
Prof84 schrieb:
Und wenn in diesem in der Taxonomie dann oben nicht die "Buzzwords" stehen die sie kennen, die in Wirklichkeit nur ein Jargon einer anderen Domaine sind, landet der nach der ersten Seite in den Reißwolf.
du sollst nicht von dir auf andere schließen.
die echten techniker und wissenschaftler schmeißen deinen müll weg, weil ganz oben buzz-words stehen. aber ich vermute, ihr habt die hochkompetenten leute schon längst aus dem unternehmen vertieben.
-
phlox81 schrieb:
Ich finde UML ist toll für die Planung und
wenn man erstmal kapiert hat, daß bei guten entwicklern die architektur sehr stark von der implemetierungssprache abhängt, wird man uml nur noch mit der kneifzange anfassen, wenn es um planung geht.
das argument, man könne doch in uml planen und immer in hinterkopf denken, wie man es implemetieren würde, ist ungut. man tut's nämlich nicht.mit ReadHead könnte ich ja fast konform gehen, wenn er öfters mal "selten" oder "später" einstreuen würde.
Wenn man eine Software plant, finde ich es einfach nett, wenn man
sich einfach die Klassen erstellen kann, abhängigkeiten einzeichnen,
und dann sieht ob das ganze Sinn macht.klar ist das "ganz nett". aber was schützt einen vor der zweitklassigkeit? oder ist das egal, wenn man uml einsetzt?
übrigens hatten struktogramme genau das gleiche problem. man entfernte sich vom ziel, unterstellte, man würde in jeder sprache alles auf die gleiche weise machen und schön war es nachher nie.
-
volkard schrieb:
Prof84 schrieb:
Und wenn in diesem in der Taxonomie dann oben nicht die "Buzzwords" stehen die sie kennen, die in Wirklichkeit nur ein Jargon einer anderen Domaine sind, landet der nach der ersten Seite in den Reißwolf.
du sollst nicht von dir auf andere schließen.
die echten techniker und wissenschaftler schmeißen deinen müll weg, weil ganz oben buzz-words stehen. aber ich vermute, ihr habt die hochkompetenten leute schon längst aus dem unternehmen vertieben.
1 zu 0 für volkard !
Auf zur nächsten schlammschlacht runde!