UML <--> Operatoren, Konstruktoren, etc...
-
volkard schrieb:
Redhead schrieb:
Das ist eine persönliche Meinung und keine Tatsache, daher sollte man es auch als solche "kennzeichnen".
guter einwand. da das eigentlich immer gilt, hab ich's in meine sig getan.
Wer liest sowas schon.
-
Also zur Zeit ist es mein Auftrag die Entwicklungen von 1.800 Softwareentwicklungen unter einen Hut zu bringen. Und diese verwenden nicht nur UML in allen Formen und Tools, sondern u.a. auch mathematische Modelle.
Was glaubst Du wieviel Hochsprachen und (RT)OS die hier verwenden ...
Und trotzdem haben wir hier auch Code-Generatoren im Einsatz für die Industrialisierung ...
-
EDIT: 1.800 Entwicklern, nicht Entwicklungen.
-
daß uml noch eingesetzt wird, ist doch kein argument dafür, daß es irgendwas bringt. uml wird genauso in die geschichte der informatik-witze eingehen wier ungarische notation und wie struktogramme.
damals schreib man übrigensAlso zur Zeit ist es mein Auftrag die Entwicklungen von 1.800 Softwareentwicklungen unter einen Hut zu bringen. Und diese verwenden nicht nur STRUKTOGRAMME in allen Formen und Tools, sondern u.a. auch mathematische Modelle.
ich kann nicht nachvollziehen, warum solche massen den buzzwords hinterherlaufen und manche verstehen nicht, warum ich nicht davon wenigstes begeistert bin. naja, macht nix. ich hab halt nen schweren stand. was mich aber immer aufregt, ist wenn 5 oder 8 jahre später auf einmal alle es schon immer gewußt haben.
-
volkard schrieb:
für die kommunikation zwischen entwircklern isses auch nicht gut.
Naja, um mal eben jemand 'ne vorhandene Struktur zu erklären ist das eigentlich gar nicht so schlecht. Man zeichnet mal eben auf, wie der Teil, den man ihm erklären will, in etwa aussieht.
Oder hast du bessere Variante?
-
*kopfschüttel*
... und da nach all der Zeit beim volkard immer noch keine Erkenntnis für die Modelling vorliegt, werde ich das auch nicht mehr ändern.
Völlig unfähig einen neuen View zu setzen.
Ach ja, wie auch ohne Modellbetrachtung! Mentale Selbststerilisation ...
Helium schrieb:
volkard schrieb:
für die kommunikation zwischen entwircklern isses auch nicht gut.
Naja, um mal eben jemand 'ne vorhandene Struktur zu erklären ist das eigentlich gar nicht so schlecht. Man zeichnet mal eben auf, wie der Teil, den man ihm erklären will, in etwa aussieht.
Oder hast du bessere Variante?
Psst!... Re-use, Abstraktion, Domain Modelle, Dokumentation, Destillation, Transformation, Konfiguration, Analyse, Requirements Engineering, Software Design ...Um dein Domain Model ein wenig zu erweitern ...
Domain-driven Design | ISBN: 0321125215"If you don't think you getting value from your investment in OO programming, this book will tell you what you 've forgotten to do."
- Ward Cunningham
-
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!