UML Diagramme

[guesst]

Hi,

ich möchte mich mit Klassendiagrammen (UML) beschäftigen, hab aber noch einige Probleme damit.

Daher möchte ich euch eine Aufgabe stellen und euch fragen, ob ihr ein passendes Klassendiagramm entwerfen und zeigen könntet, so dass ich mir die Lösung anschauen kann, um sie zu verstehen.

Bsp.:

In einer Videothek möchte ein Kunde einen bestimmten Film ausleiehen. Daher benutzt er den Kunden-Computer, in dem er nach dem Film suchen kann. Ist dieser Film vorhanden, so braucht er nur noch zur Abnahmestelle gehen und ihn abholen.
Ist der Film nicht vorhanden, so kann er aber ihn reservieren und dann abholen, wenn der Film wieder vorhanden ist.

Wie sieht ein Klassendiagramm für dieses Schema aus ?

Und wie sieht das Use-Case- und Objektdiagramm dazu aus ?

Ist wirklich wichtig.

VIELEN DANK im Voraus

[volkard]

guesst schrieb:

Hi,
ich möchte mich mit Klassendiagrammen (UML) beschäftigen,

du tust dir keinen gefallen damit. uml ist leider untauglich, sehr gute programme zu planen. (ok, use cases aufzuschreibseln ist ganz sinnig.)
warte mit uml am besten, bis du in der sprache deiner wahl sehr gute programme bauen kannst. dan brauchtse ein uml-buch oder -tutorial nur mal schief anzugucken und kannst es.

[jumli]

für so simple Abläufe benötigst du kein UML, da kannst du direkt coden.

[Prof84]

volkard schrieb:

guesst schrieb:

Hi,
ich möchte mich mit Klassendiagrammen (UML) beschäftigen,

du tust dir keinen gefallen damit. uml ist leider untauglich, sehr gute programme zu planen. (ok, use cases aufzuschreibseln ist ganz sinnig.)

What´s ... ?!?

Volkard, Volkard. mein Jung! Jetzt bisse aber ne herbe Enttäuschung für mich ...

Vor Kurzem noch ein Vertriebsgespräch mit ein Rudel Dipl.-Ing.´s bei einen Technologie-Konzern gehabt. Die legten mir Ihre Anforderungsbeschreibung sofort in UML 2 vor und wollten mit mir in medias res diskutieren.
(Pattern-Mal-Stunde)

Solche Kunden sind einfach nur geil!
Wenn Du nicht nur Pinkelprojekte machst, ist UML in der OO MUST-HAVE !!!

[*freu*]

Oh ja, das gibt bestimmt wieder einen feinen Flame.

[lach_mich_kaputt]

Volkard beherrscht nicht einmal die Rechtschreibung, kann keinen Satz im Forum schriftlich sauber zu Ende formulieren. Wie soll er da für UML eintreten? Er ist halt ein echtes Genie!

[otze]

lach_mich_kaputt schrieb:

Volkard beherrscht nicht einmal die Rechtschreibung fehlende konjunktion kann keinen Satz im Forum schriftlich sauber zu Ende formulieren. Wie soll er da für UML eintreten? Er ist halt ein echtes Genie!

[volkard]

Prof84 schrieb:

What´s ... ?!?

hab ich dich aufgeschreckt? falls ja, dann benutze die kurzzeitige wachheit.

Volkard, Volkard. mein Jung! Jetzt bisse aber ne herbe Enttäuschung für mich ...

du mich auch.

Vor Kurzem noch ein Vertriebsgespräch mit ein Rudel Dipl.-Ing.´s bei einen Technologie-Konzern gehabt. Die legten mir Ihre Anforderungsbeschreibung sofort in UML 2 vor und wollten mit mir in medias res diskutieren.
(Pattern-Mal-Stunde)
Solche Kunden sind einfach nur geil!

natürlich sind kunden geil, die ihr problem spezifizieren können. und natürlich ist ein rudel dipl.-ing.s dazu in der lage.
spezifizieren ist aber nicht automatisch bildhaftes formalisieren und vor allem nicht automatisch umlisieren.

Wenn Du nicht nur Pinkelprojekte machst, ist UML in der OO MUST-HAVE !!

falsch.

es tut mir leid, daß sogar kompetenzversammlungen wie dipl.-ing.-rudel auf uml abfahren. und es ist schmerzlich, in so einem durchaus nicht ganz unwichtigen punkt der geschätzten mehrheit so viele jahre voraus zu sein. eure argumente sind exakt die gleichen, wie sie damals für struktogramme oder für UN sprachen. bla bla bla bei wirklich großen projekten super bla bla bla wer's nicht macht, ist ein keliner dummer fisch bla bla bla.
ich hab schon zu viel mist gesehen, um auf so nen mist reinzufallen. ihr betreibt da doch mystizismus. ich würde einem furzig kleinen argument glauben, wo jemals ein programm durch uml gut wurde und ein kompetenter entwickler ohne uml was schlechteres gebaut hätte. gibts aber nicht. es gibt nur bla-bla-argumente, die eines bwl-ers würdig wären.

aber sei's drum. kommuniziert meinetwegen in uml, statt in deutsch. werft euch geenseitig rechtecke statt inhalten an den kopf.

ich sage: uml macht keine sehr guten programme. das ist ja wohl mal fakt.
du sagst: uml macht feine kommunikation. das ist zur zeit auch fakt.
was du nicht raffst, ist der darin einiliegende zielkonflikt. hast du eigentlich mal versucht, irgend ein programm sehr gut zu machen? damit meine ich top-lesbarkeit des codes (ne selbstverständlichkeit, daß man in 5 jahren unmittelbar wieder in den code einsteigen kann) und top-performance (zero abstraction overhead, stets gute algos und datenstruturen gewählt, lustigerweise sind die hälfte der datenstrukturen nicht in der stl). ich würde sagen: offensichtlich nicht.
du würdest bemerkt haben, daß man in unterschiedlichen sprachen unterschiedlich herangehen muss. es gibt nicht die OO-Programmerweise, in der man in OO ein prog entwirft und dann in eine beliebige sprache übersetzt.
deine formulierung

ist UML in der OO MUST-HAVE

läßt mich vermuten, daß deine denke aber in dieser richtung geht.
in jeder sprache sehen die lösungen anders aus, und wenn kompetent veranstaltet, schlägt sich das signifikant auf den entwurf nieder. der architekt muß ein echter fachmann in der zielsprache sein. einer, der weiss, wie das team jenes oder solches verwirklichen sollte.
er fragt sich zum beispiel, ob objekte mutieren können. sagen wir mal, die außenwelt kennt sowas wie mitabrbeiter und vorgesetze, denen weitere mitarbeiter zugrordent sind, wobei vorgesetze auch mitarbeiter sind.
im falle der ersten beförderung, wenn ein bisheriger mitarbeiter zum vorgesetzen wird, was passiert mit dem objekt? es kriegt ein attribut dazu und ändert seinen typ. in vielen sprachen läßt sich das nicht zufriedenstellend implementieren. wie soll man vorgehen?
- problem ignorieren? die häufigste antwort.
- verlangen, daß mutieren geht? über zwischenzeiger in ner proxy-klasse, durch harte tricks wie austauschen des (geheimen) zeigers auf die vtbl und vorheriges allokieren auf die maximalgröße? aber was, wenn transaktionssicherheit gefordert ist? atomare operationen selbst bei stromausfällen sind nicht einfach zu implementieren, weshalb man sich entscheidet, ne datenbank drunterzulegen, die das anbietet. also proxies in den code, die datenbankzeilen darstellen und wieder ist das mutieren weg, weil man ne normale relationale datenbank wählt.
- mutieren weglassen? jetzt muss das model weiter von der außenwelt wegrücken.
ähnlichen konflikt hat man bei der frage, ob die zielsprache sofort zuschlagende destruktoren kennt.
ein sehr guter entwurf kann nur geschehen, wenn man die zielsprache vor augen hat.
um genau zu sein, ist die auswahl der zielsprache ne wichtige entwurfs-entscheidung und in einer idealen welt könnte man stets die angemessenste sprache wählen, faktisch ist man natürlich an die mitarbeter gebunden, wenn die allesamt sehr gut mit vb jonglieren können, aber in java nichts auf der pfanne haben, dann kann es ja sein, daß das projekt in vb geschehen sollte. schreckliche vorstellung? nicht wirklich. aber diese entscheidung hätte weitestreichende folgen bis in die kleinsten kästchen von diagrammen hinein.

naja, jeder hat seine erfahrungen, der eine mehr, der andere weniger. das macht aber nix. kommt ja noch.

aus

ich möchte mich mit Klassendiagrammen (UML) beschäftigen, hab aber noch einige Probleme damit.

schloss, ich, daß er es "möchte" und freiwillig tut, nicht "muss" oder "soll" für ne gute note in ner vorlesung wie "software engeneering" (ich hab da natürlich ne 1 gebaut, obwohl ich bereits damals dem prof. gegenüber uml anzweifelte.)
übrigens mal strupis literaturempfehlungen gelesen? er scheint auch in meiner richtung zu denken.

In einer Videothek möchte ein Kunde einen bestimmten Film ausleiehen. Daher benutzt er den Kunden-Computer, in dem er nach dem Film suchen kann. Ist dieser Film vorhanden, so braucht er nur noch zur Abnahmestelle gehen und ihn abholen.
Ist der Film nicht vorhanden, so kann er aber ihn reservieren und dann abholen, wenn der Film wieder vorhanden ist.
Wie sieht ein Klassendiagramm für dieses Schema aus ?

typische schul- oder hochschul-aufgabe von der richtung her. aber es fehlen ja die begriffe, die zu klassen runterabstrahiert werden sollen. also vermutlich selbst gestellt. und offensichtlich muß man guesst als novizen im programmiergeschägt einschätzen. und da überlege ich mir, welchen einfluss es auf diesen menschen, deutschland und die ganze welt hat, wenn er zuerst uml lernt, und dann erst programmieren.
der einfluss auf die welt ist irrelevant. der auf deutschland und ihn ist aber als durchaus negativ zu bewerten, und deshalb rate ich ihm, nicht freiwillig uml zu betreiben.
aber es ist nur ein rat von mir. so, wie ich anfängern auch rate, nicht mit java anzufangen. was er dann letztendlich macht, ist seine entscheidung.
dass du mir widersprichst, ist auch gut. guesst muss selber entscheiden. was ihm hilft, ist viel text, in dem wir uns gegenseitig anpflaumen.

lmk schrieb:

Volkard beherrscht nicht einmal die Rechtschreibung, kann keinen Satz im Forum schriftlich sauber zu Ende formulieren.

das tue ich wohl können und ich mache fast nur gute sätze. und wenn das einer nicht glauben mag und wenn mich deswegen einer für doof halten tut, dann ist es auch nicht schlimm. er soll ja nicht mir glauben tun, sondern mein geschreibsel nur mal lesen und dann, wenn auch andere meinungen geäußert wurden, dann selber entscheidungen machen.

[Helium]

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.

[HumeSikkins]

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

[Prof84]

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!

[Dezipaitor]

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

[Online]

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

[Gast]

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.

[Dezipaitor]

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.

[Gast]

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

[Dezipaitor]

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.

[Prof84]

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