UML Diagramme
-
Klassendiagramme zum Planen? Halte ich für sinnlos. Aber zum anschließenden darstellen ist es praktisch. Wenn du bereits eine Hierarchie hast und jemand neu einsteigt kannst du ihm mit solchen Diagrammen schnell das Modell erklären.
-
Helium schrieb:
Klassendiagramme zum Planen? Halte ich für sinnlos.
...und geht imo von der falschen Seite (der statischen) an die Sache ran.
Zum Planen scheinen mir so einfache Sachen wie CRCs doch besser geeignet. Auch wenn das dann nicht UML ist
der architekt muß ein echter fachmann in der zielsprache sein.
Ob er ein "echter Fachmann" sein muss, weiß ich nicht. Imo muss er aber die Zielsprache auf jeden Fall beherrschen (besonders ihre "design features") und berücksichtigen.
James Coplien z.B. begründet dies sehr ausführlich in seinem Buch "Multi-Paradigm Design for C++". Dort wird neben der klassischen "Application Domain Analysis" auch eine "Solution Domain Analysis" diskutiert.
Wie heißt es dort in Kapitel 6 so schön:If we view design as the activity that derives a solution structure from a problem structure, it isn't enough just to understand the problem - we must understand the solution domain as well[...] It is the structure of the programming language - or, more precisely, the way in which a programming language expresses commonality and variability - that determines the "shape" of the solution domain
-
Ja, volkard hat so viel geschrieben, dass ich nicht ganz so detailiert eingehen möchte.
Du implizierst bei mir einen Dokmatismus zur UML ...
Klar - zur Beschreibung der Idiome ist wohl nichts besser geeignet als die Programmiersprache selbst. Zwar sind mir Vergleiche zur VB und Delphi nicht so willkommen, da es nur semi-oo Hochsprachen sind, aber ich will durchaus einräumen, dass Sprachmittel wie z.B. generische Programmierung mit Sicherheit Einfluss auf die Gesamtarchitektur der Software haben. Aber irgendwie betrachtest Du UML nur als Top-Down Technik. Du kannst deine Idiome und Optimierungen durch reverse-engineering (Bottom-UP) in UML wieder abbilden, also sehe ich so kein Argument gegen UML. Ich betreibe während des OODs nur Tune-In Entwicklungen.Aber deine Aussage war das UML nicht zur Planung sehr guter Programme taugt.
Ich sage - vielleicht liegt es auch am Architekten und nicht an UML.
Bei der Planung beginnst Du mit einer opaken, präformalen und individuellen Lösungsansatz und strebst zu einen vollständigen, formalen und globen Ansatz entgegen. Dabei ist IMHO UML besser geeignet als Code.
Unter den Gesichtspunkten eine Verbindungsbrücke zwischen den Anforderungen und Prozessen und des Designs einer Entwicklung zu schlagen (z.B. BWL und Entwicklung) , visualisieren, spezifizieren, dokumentieren und standardisieren hat sich die UML durchgesetzt. Wir erinnern uns - ein Standard macht eine Anwendung für den Durchschnitt und der Mehrzahl der Nutzer erst praktikabel. Er stellt nicht für alle Ansprüche eine optimale Lösung dar. Ich sage - für 95% der technischen Ansprüche genügt die UML zur "Planung" völlig. Außerdem beschränkt sich der Einsatz auf dem OO Bereich, also z.B. bei C API Coding von Betriebssystemen(POSIX/win32) kann man demnach UML knicken.Durch diesen Standard war erst die effektive Integration von
- Projektmanagement
- Produktmanagement
- Changemamagement
- Konfigurationsmanagement
- Testsystemen
- Dokumentationssytemen
zu UML in einer Einheit möglich.Mag sein das Du z.B. im C++ keine 100% codetechnische Optimierung erreichst - refactoring ist aber auch nicht verboten. Aber die Vorteil für den Qualitätsgewinn in der Gesamtbilanz überwiegen. Sonst hätte sich die UML auch nicht durchgesetzt.
Du bist selbst Freiberufler. Versuch doch einmal heute eine C++ Entwicklung zu akquirieren als Teammember über 3MM+. Stehen, sofern der Autraggeber selber hinreichende softwaretechnische Kompetenz besitzt, immer sofort die zugehörigen OOT und Tools dabei. Es sei denn Du hast in Wirklichkeit wieder nur ne C Programmierung.
Ich bleibe dabei - UML ist heute MUST-HAVE.
Andernfalls bist Du nur ein Hinterbank-Klopper, der nur seine API vogegeben bekommt und vor sich hinbrödeln darf. Dann hat mit Planung nicht viel am Hut.
<ot>... doch Flame Thread!
</ot>
@hume:
Klar! - Einfache Anfordungsnotationen wie Snowcards, CRC´s, Problem Frames, QFD´s, Prüflisten, Glossen und Nomenklaturen, Tracetabellen, Domänanalysen, Bedeutungsanalysen oder einfache Use Cases kommen vor der UML und der OOAD.Fazit: Satz und Sieg - Hume!
-
ich finde UML ganz nützlich, besonders wenn es um Thread- und Netzwerk-Geschichten geht, wo eine komplexere Kommunikation stattfindet.
Im Code blickt keiner durch, obwohl alle Maßnahmen dagegen ergriffen wurden. Aber als schönes Sequenzdiagramm lässt sich der Code schön illustrieren.
Kann es sein, dass manche sich dagegen so sträuben, weil sie Angst haben, UML könnte zu einem Werkzeug führen, dass die Programmierung im heute üblichen Sinne ersetzt?
Man könnte ja jetzt schon mit viel Genie, einen abstrakten Programmcode in UML ersinnen, den man "nur" noch in eine Programmiersprache übersetzen müsste. Ich kann mich daran erinnern, dass solche Programme auf dem Weg sind : Steht in einer C't vom letzten Monat, soweit ich weiß.
-
Dezipaitor schrieb:
...
Kann es sein, dass manche sich dagegen so sträuben, weil sie Angst haben, UML könnte zu einem Werkzeug führen, dass die Programmierung im heute üblichen Sinne ersetzt?
Man könnte ja jetzt schon mit viel Genie, einen abstrakten Programmcode in UML ersinnen, den man "nur" noch in eine Programmiersprache übersetzen müsste. Ich kann mich daran erinnern, dass solche Programme auf dem Weg sind : Steht in einer C't vom letzten Monat, soweit ich weiß.Ja, das stand da drin...zwar nicht direkt von Programmiersprachen aber von einem "zusammenklickbaren" Layout des Microprzessors, über Befehlssatz zum passenden Compiler alles in einem Rutsch Softwaretechnisch realiesiert. Das einzige was du noch machen musst ist Prozessor auf Platine bringen und ein Programm schreiben. Vielleicht schreiben bald Programme Programme
-
Mit den GUI-Designern ist das ja zumindest ein Ansatz. Aber code generieren, was ist das schon? Ein Programm wird niemals selber Algorithmen entwickeln können, genauso wenig, wie GUIs zu designen, die richtig cool benutzbar sind.
Code generieren, auf unterster Ebene können das Programme heute eh schon besser als die meisten Menschen, na und? Das ist gar nicht so toll. Das heißt, es ist schon toll, aber es ist nicht die eigentliche Arbeit.
-
Warum sollen Programme nicht die Fähigkeit bekommen eigene Programme zu schreiben? Man soll ja bekanntlich niemals nie sagen. Aber wir werden es wohl höchstwahrscheinlich nicht erleben dürfen. Insofern hast du Recht.
-
Deine Frage hätte jetzt lauten müssen "warum sollten Programme nicht die Fähigkeit bekommen, dem menschlichen Geschmack entsprechende GUIs zu designen oder eigene Algorithmen zu entwerfen?"
Tja, ich kann es dir nicht wirklcih sagen, aber ich kann es mir halt nicht wirklich vorstellen.
Wie gesagt, Codegenerierung ist nicht Programmierung. Das können sie ja jetzt schon, aber das ist halt nichts...
-
naja
wir reden ja nicht über Code-Generierung sondern über Code-Entwurf.
Was eben noch einem Computer, Programm - oder wem du das auch immer in die Schuhe schieben willst - fehlt, ist es eine Intention (Was will ich machen und wie mache ich das am besten) zu haben.
-
Online schrieb:
Dezipaitor schrieb:
...
Kann es sein, dass manche sich dagegen so sträuben, weil sie Angst haben, UML könnte zu einem Werkzeug führen, dass die Programmierung im heute üblichen Sinne ersetzt?
Man könnte ja jetzt schon mit viel Genie, einen abstrakten Programmcode in UML ersinnen, den man "nur" noch in eine Programmiersprache übersetzen müsste. Ich kann mich daran erinnern, dass solche Programme auf dem Weg sind : Steht in einer C't vom letzten Monat, soweit ich weiß.Ja, das stand da drin...zwar nicht direkt von Programmiersprachen aber von einem "zusammenklickbaren" Layout des Microprzessors, über Befehlssatz zum passenden Compiler alles in einem Rutsch Softwaretechnisch realiesiert. Das einzige was du noch machen musst ist Prozessor auf Platine bringen und ein Programm schreiben. Vielleicht schreiben bald Programme Programme
Wie?!? Bald?!?
http://www.c-plusplus.net/forum/viewtopic.php?t=89555
Im Prinzip sitze ich schon über fünf Jahre an dem Thema.
Bin gerade dabei aus dem Wasserstoff die ersten Sterne zu bilden ...Ich finde es auch wieder interessant, dass es gerade letzten Monat in der c´t stand..
