UML <--> Operatoren, Konstruktoren, etc...
-
zusammenhangloses gebrabbel voller anglizismen überzeugt mich nicht. aber ich sagte ja, daß ich auf buzz-words nicht reinfalle.
-
p84 du bist schrecklich.
-
warum soll da uml nicht gut sein? selbstverständlich kann man mit uml sprachunabhängig sachen erklären1 es kommt drauf an in welcher ebene und mit welchem diagramm!
-
warum sollen da struktogramme und programmablaufpläne nicht gut sein? selbstverständlich kann man mit struktogrammen und programmablaufplänen sprachunabhängig sachen erklären1 es kommt drauf an in welcher ebene und mit welchem diagramm!
(nur als ergänzung, damit klar ist, daß das alleinige benutzen-können nicht für die sinnhaftigkeit spricht.)
-
UML ist Müll für dumme Masochisten.
-
volkard schrieb:
zusammenhangloses gebrabbel voller anglizismen überzeugt mich nicht. aber ich sagte ja, daß ich auf buzz-words nicht reinfalle.
Trollversuch eines Moderators dem die (sachlichen) Argumente ausgehen.
-
Redhead schrieb:
volkard schrieb:
zusammenhangloses gebrabbel voller anglizismen überzeugt mich nicht. aber ich sagte ja, daß ich auf buzz-words nicht reinfalle.
Trollversuch eines Moderators dem die (sachlichen) Argumente ausgehen.
schau einfach mal den beitrag davor an. es ist echt nur ein anhäufung von anglizismen. ist dir das nicht störend aufgefallen?
-
Ich habe den bewussten Beitrag, auch jetzt zu diesem Zeitpunkt, nicht gelesen.
Mich stört, wie angegeben, die Formulierung, und nicht deine ablehnende Haltung.
Aus dem Kindergarten bzw. Script-Kiddie Alter sind wir wohl beide schon deutlich
raus. Etwas mehr Souvernität und weniger Pöbelei, wäre dir bestimmt nicht schwer
gefallen.
PS.: Der Beitrag ist eine Schlagwortansammlung ohne Inhalt und direkten Bezug
zur Originalfrage, warum überhaupt kommentieren ?
-
Redhead schrieb:
, warum überhaupt kommentieren ?
um den einsteigern ein wenig schmerz zu nehmen. wenn sie wissen, daß sie nur uml betreiben, weil der prof es benotet, dann können sie das durchaus mal betreiben und nach der klausur entsorgen. sie können zum beispiel guten gewissens erst die softare bauen und nachher so tun, als hätten sie vorher uml-diagramme gemalt. wenn sie aber annehmen müssen, uml sei das eigentlich wichtige und sie es einfach nicht hinkriegen, in uml gescheite software zu bauen (oder bemerken, daß ihr uml gar nicht half), ist das wesentlich gemeiner. also hab ich klargestellt, was ich von dem beitrag halte.
PS.: Der Beitrag ist eine Schlagwortansammlung ohne Inhalt und direkten Bezug zur Originalfrage
oh. das ist natürlich eine feine ausdrucksweise, zu der ich zwar fähig wäre, aber irgenwie habe ich dabei das gefühl, nicht ehrlich zu sein und nicht in den himmel zu kommen.
-
P84@work schrieb:
Psst!... Re-use, Abstraktion, Domain Modelle, Dokumentation, Destillation, Transformation, Konfiguration, Analyse, Requirements Engineering, Software Design ...Ich war heute auf der Systems und habe ein Grundprinzip der Informationstheorie verifiziert: Der Informationsgehalt einer Eingabe steigt mit ihrer Unerwartetheit. Anders rum: Mir sind Wörter wie total cost of ownership, Geschäftsprozess-Optimierung, business plan, Solution, xxxxxxxx-Management nur so um die Ohren geflogen. Entsprechend war der Informationsgehalt.
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. Buzzword
-
-
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!