UML Klassen- und Objektdiagramme überprüfen?
Hallo zusammen, ich habe bald eine Präsentationsprüfung im Fach Informatik, bei der ich mein mit Greenfoot selbst programmiertes Spiel (Ping-Pong) vorstelle. Dazu soll ich auch etwas zu Klassen- und Objektdiagrammen erklären und das natürlich anhand von meinem eigenen Programm. Leider haben wir das in der Schule nicht so ausführlich behandelt, weswegen ich jetzt (trotz Internetrecherche) nicht so ganz durchblicke... Kann das vielleicht jemand kontrollieren, ob das in etwa so stimmt?
Vor allem bei den Objektdiagrammen gibt man ja normalerweise "objektname:Klassenname" an, aber wenn ich (abgesehen von den Schlägern) gar keine weiteren Objekte habe, sondern nur die Klasse selbst das Objekt im Spiel ist, kann ich das dann einfach so angeben? Und muss ich dort auch noch Verbindungen machen?
1 Antwort
Also zunächst einmal ist die Reihenfolge im Ablauf deines Projekts wohl falsch. Erst werden Diagramme gemalt, danach folgt die direkte Umsetzung. Es danach zu machen, bringt dem Programm nichts mehr, denn gerade durch die Diagramme soll über ein gutes Design überlegt werden.
Zum Klassendiagramm:
- Was soll denn PongWelt sein? Ist das das Spielfeld, welches eine bestimmte Farbe hat? Dann müsste diese doch die Spielelemente besitzen und zeichnen, oder nicht?
- Der Typ string beginnt mit einem Großbuchstaben.
- Wieso hat denn die Methode setText keinen Parameter definiert?
- Alle Attribute beginnen mit einem Kleinbuchstaben, sofern es nicht Konstanten sind.
- Bezeichner wie velX, velY oder deltaT sind nicht so eindeutig / aussagekräftig und sollten gerade in einem UML-Diagramm nicht vorkommen.
- Umlaute solltest du ebenso meiden und stattdessen ersetzen (ß > ss, ü > ue, ...)
- Mit setLocation oder setText wechselst du im Vergleich zu allen anderen Bezeichnern die Sprache. Bei isKeyDown ist das vermutlich nicht so vermeidbar, weshalb die grundsätzliche Wahl auf die englische Sprache fallen sollte.
- Spieler1 und Spieler2 sollen tatsächlich eigene Klassen sein? Ich sehe zwischen ihnen keinen Unterschied.
- Der Text erbt von ist unnötig. Die Pfeilspitzen verraten bereits die Beziehung.
- Gib void-Methoden den Rückgabetyp void.
- Wer ruft denn Methoden wie wandBerührung auf und wieso geben sie kein Ergebnis zurück?
- Der Schläger könnte vermutlich abstrakt sein (dann hätte er auch einen Sinn im Diagramm). Deswegen würde ich ihn im Spiel auch als abstrakt definieren und im Diagramm würde der Name dann mit einer kursiven Schriftart gekennzeichnet werden. Er sollte zudem die isKeyDown-Methode und alle Attribute vorgeben (bestenfalls protected, also mit # als Zugriffslevel), die bei den Subtypen hingegen herausgeworfen werden.
- Der Ball zählt die Punkte? Das ist unlogisch.
Zum Objektdiagramm:
- Sofern das Programm das zulässt, solltest du die unnötigen Leerzeilen entfernen und die Namen zentrieren.
- Vor den Typnamen wird der Name der Instanz gehängt. Also z.B. ball:Ball.
- Hast du noch keine Beziehungen zwischen den Objekten gefunden?
(...) aber wenn ich (...) gar keine weiteren Objekte habe, sondern nur die Klasse selbst das Objekt im Spiel ist, (...)
Soll das heißen, dass bei dir alle Komponenten, mit Ausnahme der Schläger, statisch sind? Das wäre eine äußerst unschöne Umsetzung.
Die Diagramme dienen, wie gesagt, erst einmal nur der Ausarbeitung einer Programmstruktur. Normalerweise (bzw. es ist zumindest ein guter Tipp) beschreibt man erst das Programm mit eigenen Worten und streicht daraus dann die Substantive, beschreibenden Adjektive und Verben, um zum einen die notwendigen Objekte ausfindig zu machen sowie deren Eigenschaften, Verhalten und Verhältnis zueinander. Soweit sind noch keine Klassen bekannt (das wäre an dieser Stelle schon viel zu konkret), die kann man im nächsten Schritt ausarbeiten.
Ah nein beim dritten Punkt müsste es dann setText(spieler1:String, spieler2:String) heißen
Ergänze ich noch durch die Methode addObject(), oder?
Wenn so die Methode heißt, ja.
(...) was genau Konstanten sind... (...)
Konstanten stellen Werte dar, die nur einmal gesetzt werden (wenn die Konstante erstellt wird), sich danach aber nicht mehr ändern. Dafür wird ihnen das Schlüsselwort final vorangestellt.
final int a = 2;
Wenn eine Konstante als statisches Attribut definiert wird, schreibt man sie nach Konvention in Großbuchstaben. Wenn sie aus mehreren Wörtern bestehen, trennt man diese mit Unterstrich. Lies dazu hier (und ignoriere den Begriff ANSII-Constants, denn damit bezieht man sich wohl noch auf die Programmiersprache C).
Ein praktisches Beispiel wäre die Konstante PI in der Klasse Math.
(...) diese in dem Fall einfach weglassen?
Das habe ich missverständlich formuliert. Nicht-aussagekräftige Bezeichner sollten nicht vorkommen. Die Variablen (mit guten Bezeichnern) hingegen schon.
Umlaute spielen bei Greenfoot doch eigentlich keine Rolle (...)
Da hast du Recht, in Greenfoot selbst wird das egal sein. Sieh diesen Tipp vielleicht für später (Programmierung ohne Greenfoot), denn die Umlaute können tatsächlich auch zu Problemen bei der Kompilierung führen.
Diese Methode dient nur dazu, dass der Ball seine Richtung ändert, (...)
Nenne die Methode dann doch handleSideCollision o.ä.. Funktionen werden bestenfalls mit einem Tätigkeitswort / einer Tätigkeit benannt, damit schnell klar wird, welchem Zweck sie dienen und da sie ja ein Verhalten beschreiben.
Wenn die Methoden von Ball nicht von anderen Objekten (wie PongWelt, Anzeigetafel, ...) aufgerufen werden, können sie als private (-) deklariert werden.
Das sind tatsächlich keine Klassen, sondern wirklich nur Objekte der Klasse Schläger (...)
In dieser Hinsicht hat sich das Thema abstrakter Schläger eigentlich schon erledigt. In deinem Diagramm werden Spieler1 und Spieler2 entfernt. Die Attribute und Methoden von Spieler1 werden in die Schläger-Klasse verschoben.
Zur Erklärung:
class Racket {
private Color color;
/* ... */
public Racket(Color color) {
this.color = color;
}
}
// somewhere else ...
Racket racketOne = new Racket(Color.red);
Racket racketTwo = new Racket(Color.green);
Die beiden Variablen racketOne und racketTwo zeigen auf Instanzen / konkrete Objekte des Typs Racket. Wenn sie sich unterscheiden, dann durch ihre Eigenschaften (im Fachjargon Zustände). Diese Eigenschaften beeinflussen logischerweise auch das Verhalten. Eine Methode draw bspw., die das Objekt zeichnen soll, würde den Schläger entweder rot oder grün zeichnen.
Gäbe es nun aber einen größeren Unterschied (Schläger 1 kann Feuer spucken und Schläger 2 hat Zacken in der Form), würde eine Vererbung Sinn machen. Die Basisklasse wäre Racket, die Subklassen SpicyRacket und ToothedRacket. Die Basisklasse würde dann die gemeinsamen Attribute und Methoden auflisten (color, size, isKeyDown, ...) - die Subklassen erben diese.
Racket
----------------
# color: Color
# size: Size
----------------
# isKeyDown
Die Subklassen selbst führen nur noch ihre individuellen Eigenschaften und Methoden auf.
SpicyRacket TootheredRacket
--------------------- -----------------------
# spitFire(): void # drawTooths(): void
Nun könnte man noch einen Schritt weitergehen und sich fragen, ob die Basisklasse überhaupt im Programm als konkrete Instanz vorkommen könnte / sollte oder ob es nur die Ableger (Spicy, Toothered) geben soll. Wenn es sie nicht gibt, kann sie als abstrakt markiert werden.
Um noch ein besseres Beispiel einer abstrakten Klasse zu geben: Es gibt kein Lebewesen das konkret nur ein Kamel ist. Es gibt aber Arten (Dromedar, Alpaka, Trampeltier), die zur Familie der Kamele gezählt werden. Kamel ist nur ein vom Mensch geschaffener abstrakter Überbegriff, um mehrere konkrete Typen unter eine Gruppe einordnen zu können. Ein anderes Beispiel ist der Begriff Mensch. Es gibt keinen Mensch selbst, nur konkrete Typen (Mann, Frau).
In meinem Fall ist es tatsächlich der Ball, der immer 1 hinzufügt, (...)
Wie gesagt, dass ist nicht logisch. Wenn ich so überlege, müsste es eher so laufen: Das Spielfeld zeichnet das Feld und besitzt eine Anzeigetafel, zwei Schläger und einen Ball. Wenn der Ball vermeldet, dass er auf eine der vertikalen Seiten getroffen ist, gibt das Spielfeld diese Information an die Anzeigetafel weiter und zeichnet sie aktualisiert neu.
(...) aber sonst mache ich sie vielleicht einfach in Word (...)
Vielleicht findest du auch hier eine gute Alternative.
Naja die Beziehungen wären in meinem Fall ja genau gleich wie zwischen den Klassen...
Und wieso wäre das schlimm? UML-Diagramme dienen wie gesagt einem Prozess, von der Analyse zum konkreten Plan. Die Erkenntnisse von Schritt 1 können in Schritt 2 weiterverwendet werden.
Und ja genau das würde es dann heißen...
Lies bitte einmal hier. Als Einstiegserklärung: Dort wurden alle Variablen in eine Klasse Var gepfeffert und statisch deklariert.
Okay soweit so gut. Vielen lieben Dank für die ausführlichen Erklärungen! Hätte nicht gedacht, dass ich hier so gute Hilfe bekomme. Ich werde jetzt alles nochmal überarbeiten und dann reicht es hoffentlich für die 10 Punkte in der Präsentation, mit denen ich gerade noch so eine 1,9 im Abischnitt schaffen würde :'D
Vielen Dank für die ausführliche Antwort! Hat mir schon sehr weitergeholfen! Einige Sachen sind mir jetzt klar, andere sorgen bei mir immer noch für Verwirrung... Bin auch totaler Programmieranfänger...
Ich weiß, dass die Reihenfolge eigentlich falsch ist, aber da ich 4 Themen einreichen musste und erst 1 Woche vorher dann mein eines Thema bekommen habe, habe ich das Spiel da davor schon programmiert, weil ich dachte das dauert am längsten und dann muss ich das nicht mehr in der einen Woche machen...
Klassendiagramm:
Objektdiagramm:
Und ja genau das würde es dann heißen... Aber es ist ja auch wirklich ein simples Spiel und auch Greenfoot macht einem das Programmieren relativ leicht... vielleicht ist es zu sehr vereinfacht für dich :'D
Und danke für den Tipp ! Das werde ich auf jeden Fall mal noch ausformulieren, vielleicht blicke ich dann in der Programmstruktur wieder mehr durch. :D