Hiho Flash,

also erstmal eine wirklich gelungene, verständlichen Zusammenfassung.
Das einzige was mir beim ersten Lesen fehlt, wäre bei den Klassenbeziehungen noch die Komposition der Vollständigkeit halber.

_________________
__________
"C++ is the best language for garbage collection principally because it creates less garbage." Bjarne Stroustrup

Den Begriff habe ich in diesem Zusammenhang noch nicht gehört, und auch noch nie in einem UML-Editor gesehen. Was soll das sein?

_________________
Blog: kevin-fleischer.de und fbaingermany.com

Doch er hat absolut Recht. Wurde bei uns auch im Zusammenhang mit UML durchgenommen. http://de.wikipedia.org/wiki/Komposition_%28UML%29 Gibt ganz unten eine kleinen Absatz... . Sollte aber eigentlich auch in jedem UML-Buch vorkommen.

_________________
"Light travels faster than sound. This is why some people appear bright, before you can hear them speak..."

Diese Tutorialreihe von Flash ist natuerlich toll, denn es liegt wohl nicht am technischen Wissen, dass soviele Projekte nicht abgeschlossen werden, sondern tatsaechlich eher an der Planung.

Nachdem ich das erste Tutorial gelesen hatte war ich begeistert und liess es dann auch erstmal dabei. Nachdem ich nun aber auch das zweite gelesen habe (das erste hab ich auch nochmal gelesen) war mir alles nicht mehr so klar -> ich war verwirrt Also versuchte ich, was sonst immer bei so etwas funktioniert:

Das Problem selbst versuchen praktisch zu loesen. Diesmal hat es aber leider nicht geholfen, ich wusste schon beim ersten Tut nicht wie ich die UseCases einteilen sollte (dabei dachte ich es damals verstanden zu haben).

Deswegen mein Vorschlag> Wie waers mit einer Demodokumentation (z.B. die ein ganz einfaches Rennspiel oder so beschreibt) die man sich dann parallel zu der Tutorialreihe anschauen kann? Halt wie der Quellcode zu den anderen Tuts zum nachvollziehen

_________________
Flummi: Projektseite und Projektthread

Kann ich verstehen. Schließlich ist der Inhalt vergleichbar mit dem Buch.

Meine Zeit ist halt nur sehr begrenzt. Eventuell hilft es dir wenn du dir das Buch mal in ner Bibliothek ausleihst. Es ist zwar in Englisch aber es hangelt sich an einem praktischen Beispiel entlang (Universitäts Verwaltungssoftware).

_________________
Blog: kevin-fleischer.de und fbaingermany.com

Das kann ich wiederum gut verstehen Sieht bei allen wohl aehnlich aus.

Vielleicht kann ich mich ja langsam in kleinen Schritten durcharbeiten und die Zwischenergebnisse in einem Thread posten, wo dann jeder diskutieren kann, was man noch verbessern veraendern sollte.
Ich hatte nun zuerst an ein Rennspiel gedacht, auch wenn ich gar nicht vorhabe das dann tatsaechlich zu programmieren, ich wills erstmal nur planen

_________________
Flummi: Projektseite und Projektthread

Bei nem Managementspiel ist ein Usecase z.B. "Spieler baut Gebäude neu", "Spieler baut Gebäude um", "Spieler kauf XYZ", "Spieler Verkauft XYZ", "Spieler verhandelt über abc", ....

Das kann relativ schnell, relativ viel werden. Beim Designen der GUI Elemente muss man dann sehn ob man die Bedienung der einzelnen Usecases nicht vielleicht in ein paar wenigen Formularen zusammenfassen kann.

_________________
Blog: kevin-fleischer.de und fbaingermany.com

100% meine Meinung! Genau so ging es mir auch.

Jedoch muss es nicht gleich eine ganze Demodokumentation sein, sondern man könnte sowas auch in kleine Stückchen aufteilen. Z.B. wäre selbst die Planung des Menüs eines Spieles eine große Hilfe für mich!

MFG
Maximus

Bei derOberfläche helfen UseCasesschon. Schreib einfach mal verschiedene "Aktionen" auf, die der User machen können soll. Das sind deine UseCases.

Dann überlegst du dir was innerhalb eines UseCases nacheinander gemacht werden muss. Das sind dann Szenarios.
Dann vergleichst du was bei ähnlichen UseCases alles Identisch ist. So kannst du schonmal Klassen zusammenlegen.

Wenn du von vornherein erstmal weißt was deine Anwendung alles kann, ist das ein riesen Vorteil. Viele Probleme mit dem Code entstehen weil immer mehrdazugebaut wurde, und beim ranbasteln nicht mehr auf die Struktur geachtet wurde.

_________________
Blog: kevin-fleischer.de und fbaingermany.com

Sagen wir ich will ein Menü das folgendermaßen aussieht:
-Optionen
---Namenseinstellung
-Einzelspieler
---Spiel starten

D.h. der User kann a) einen Menüpunkt auswählen b) Namenseinstellung ändern c) Spiel starten. Sind diese drei Teile dann auch meine UCs?

Und der genaue Ablauf der UCs wird dann durch die Aktivitätsdiagramme beschrieben?

Allerdings wäre die Gliederung des Menüs in keinem Diagramm vermekt, also nicht in die Planung einbezogen, oder habe ich irgendetwas vergessen?

MFG
Maximus

Nein das Design der Oberfläche (Gleiderung) erfolgt nach Softwareergonomischen standpunkten, und ist dem Code unten drunter ziemlich egal. Es geht ja gerade darum diese Teile von einander zu trennen.

Ich sehe in deinem Beispiel 2 UC:

- Spielereinstellungen (Name) ändern
- Neues Spiel starten.

Beim 2. gehört alles dazu was gemacht werden muss um das Spiel zu starten. z.B. eine Karte auswählen, anzahl Gegner festlegen, Schwierigkeitsgrad etc.
Sollte einer der Unterpunkte selbst recht komplex werden kann man daraus so einen SubUC machen wie im Tutorial 1 beschrieben.

Bevor ihr anfangt zu Coden solltet ihr bereits (möglichst) komplett wissen was das Programm machen kann und das in Diagramme pressen. Wenn das erstmal vernünftig gemacht wurde, kann man relativ leicht daraus gut strukturierten Code ableiten.

_________________
Blog: kevin-fleischer.de und fbaingermany.com

Ich schließe mich dem Bitten und Betteln um eine "Demo"-Dokumentation an, schlicht und ergreifend, weil ich keine UML-Seminare besucht habe.

Ich würde vorschlagen, Du (Flash) veröffentlichst die Dokumentation zu PBall Manager 2, ich gehe mal davon aus, dass sie existiert. Wäre das eine Option? Es würde das Tutorial bestimmt arg aufwerten.

Zu PBM existiert keine Doku. Das Problem an diem Projekt hat mich erst auf das Thema hingewiesen. Ich gebe allerdings zu, dass ich schonmal angefangen hatte ein kleines Demoprojekt zu schreiben. Bin aber noch nicht wieder dazu gekommen. Vorallem auch weil ich noch den 3. Teil schreiben müsste und weil ich momentan noch in einem Praktikum bin. Nach 8h arbeit is man meistens wenig kreativ.

_________________
Blog: kevin-fleischer.de und fbaingermany.com