UML-Diagram - Richtig so/Verbesserungsvorschläge?

Volvagia

Ich habe versucht, ein Klassendiagram für ein Spiel zu bauen. Jetzt würde mich interessieren, ob es so richtig ist. Alle Tutorials die ich gefunden habe fand ich sehr verwirrend, ich verstehe ab und zu gar nicht, was der Unterschied zwischen 2 Dingen ist. (z. B. Use Cases und Informationsflüsse)

http://666kb.com/i/bkj6l5jg8usr59mwi.jpg

Mich würde echt interessieren, ob das so richtig ist. Das Game existiert derzeit nur in meinen Kopf. Ich will es machen, da ich oft wärend dem Coden Dinge wenn ich etwas nicht sofort eingeplant/bedacht habe umschreiben muss, und so auf Dauer die Lust verliere. Natürlich würden mich auch Verbesserungsvorschläge für das allgemeine Klassendesign freuen. Ist zwar Java, aber ich denke da gibt es keinen Unterschied. Ich beschreibe jetzt nicht, was die Klassen so machen und wie das Projekt im allgemeinen aufgebaut ist, da sonst warscheinlich das Bewerten, ob das Diagram klar zu verstehen ist sehr schwierig wird.

Zeus

Ach du heiliges UML.

Kann kein andere dir sagen, ob es richtig oder flasch ist, weil wir nicht wissen was du in deinem Kopf hast bezüglich deines Games.
UI Code wird generell nicht modelliert, weil man sehr stark an die Gegenheiten des Framework orientieren würde.
Arbeite dich erstaml in das Klassendiagramm ein und seine Idee. Versuch die Menge an Typen herauszufinden - Wo sind gemeinsamkeiten. Welches Abhänigkeiten. Welche Eigenschaften,... und modelliere mit den Use Case die Komponenten und ihre Schnittstellen, die Datenstruktur mit Klassendiagramme, den Ablauf mit Aktivitätsdiagramm. IMO sollte das ausreichen.

Volvagia

Danke.
Wie lässt man den UI-Code weg? In dem Beispiel ruft die das Applet nach der Initialisation BuildLogin auf, welche die Labels, Textfields, Animation, den Thread und den Button erstellt und hinzufügt. Wird der Button gedrückt wird der Thread gestartet, dieser wiederrum startet die Animation kommuniziert mit dem Server (Login), stopt sie wieder und ruft BuildLoad im nächsten package auf.
Falls ich die Labels/Buttons ect. weglasse, würde doch ein großer Teil fehlen, oder?

Was meinst du mit Schnittstellen? Methodenaufrufe? Die habe ich eigendlich per Association festgelegt.

Womit hast du das gezeichnet?

Volvagia

StarUML und als Bild exportiert.

volkard

Ich werde das Bildchen aufheben und als Argumentationshilfe benutzen, wie man durch UML in der Planungsphase viel mehr übersicht bekommt, und welche Arbeitserleichterung und später auch bessere Codequalität eine ordentliche Planung mit so angemessenen formalen Mitteln (was nicht zwingend UML sein muß) mitsichbringt.

Zeus

Volvagia schrieb:

Danke.
Wie lässt man den UI-Code weg? In dem Beispiel ruft die das Applet nach der Initialisation BuildLogin auf, welche die Labels, Textfields, Animation, den Thread und den Button erstellt und hinzufügt. Wird der Button gedrückt wird der Thread gestartet, dieser wiederrum startet die Animation kommuniziert mit dem Server (Login), stopt sie wieder und ruft BuildLoad im nächsten package auf.
Falls ich die Labels/Buttons ect. weglasse, würde doch ein großer Teil fehlen, oder?

Was meinst du mit Schnittstellen? Methodenaufrufe? Die habe ich eigendlich per Association festgelegt.

Kleines Beispiel in Pseudo Java in Deutsch!

public class Spieler
{
}

public class Spiel {
   public boolean rateMal(Spieler spieler, int eineZahl);
   public Punktetafel zeigeSpielstatus()
   private Spieler[4] spieler
}

Kannst du wunder paar in Use-Case und Klassendiagramm darstellen.

Use-Case:
System Spiel
Akteur: Spieler
Fall1: rateMal
Fall2: zeigeSpielstatus

Spieler hat eine Assoziation zu jeweils einen Fall.

Klassendiagram
Klasse Spieler

Klasse Spiel
Öffentliche Method (aka Schnittstelle): ratemal und zeigeSpielstatus

Eine Assoziation 1:4 zwischen Spiel und Spieler

asc

Zeus schrieb:

UI Code wird generell nicht modelliert, weil man sehr stark an die Gegenheiten des Framework orientieren würde.

So allgemein würde ich das nicht sagen, aber wenn man UI-Code mit berücksichtigt, in der Regel nur auf einer sehr abstrakten Ebene, wo man mehr oder weniger festlegt was es für Eingabemasken etc. wohl geben wird, nicht aber wie die konkrete Umsetzung (Menüs, Grids...) erfolgt.

Davon abgesehen: Wenn ein Diagramm zu unübersichtlich ist, sollte man es teilen...

Auch bei UML gilt, "Teile und Herrsche".

SideWinder

volkard schrieb:

Ich werde das Bildchen aufheben und als Argumentationshilfe benutzen, wie man durch UML in der Planungsphase viel mehr übersicht bekommt, und welche Arbeitserleichterung und später auch bessere Codequalität eine ordentliche Planung mit so angemessenen formalen Mitteln (was nicht zwingend UML sein muß) mitsichbringt.

Erspar' dir besser derlei Peinlichkeiten, dir ist bestimmt aufgefallen, dass diese Art von Grafik nicht Ziel des UML-Einsatzes war/ist.

MfG SideWinder

volkard schrieb:

Ich werde das Bildchen aufheben und als Argumentationshilfe benutzen, wie man durch UML in der Planungsphase viel mehr übersicht bekommt, und welche Arbeitserleichterung und später auch bessere Codequalität eine ordentliche Planung mit so angemessenen formalen Mitteln (was nicht zwingend UML sein muß) mitsichbringt.

Hast Du die Ironie-Tags vergessen? :p

Volvagia

Danke, mit den Tips werde ich warscheinlich etwas brauchbares hinbekommen.