Abänderung eines UML-Klassendiagramms für das Spiel Pong?
Hallo an alle,
könnte mir jemand erklären wie ich eines der folgenden Klassendiagramme abändern muss, wenn ich die Farbe des Spielschlägers in dem Spiel Pong auf Blau geändert habe?
Ich habe dafür ein Konzept- und ein Implementierungsklassendiagramm, aber weis nicht welches der beiden ich wie ändern muss. Anbei beide als Bild.
Nr.1 Konzeptklassendiagramm
Nr.2 Implementierungsklassendiagramm
Vielen dank:)
1 Antwort
Die konkrete Farbdefinition stellt einen Programmzustand dar, der in einem Klassendiagramm normalerweise nicht eingebaut wird, denn er ist doch nicht implementierungsentscheidend. Das Programm funktioniert doch auch, wenn der Schläger grün, rot oder gelb ist.
Wenn man Felder mit einem Startwert auszeichnen möchte, dann kann man eine einfache Zuweisung verwenden:
Beispiel:
# height: int = 100
Wenn man nun eine Eigenschaft, wie den Wert eines Attributs in einer Subklasse überschreiben möchte, dann braucht man sie lediglich noch einmal aufführen.
Beispiel:
----------------- -----------------------
| Shape | | Rectangle |
-----------------<|------------------------------
| # height: int | | # height: int = 100 |
----------------- -----------------------
Hier erbt die Klasse Rectangle zwar die Eigenschaft height von der Basisklasse Shape, definiert aber auch einen neuen Startwert (100).
Im UML-Kontext redet man bei einer Eigenschaftsänderung von einer Redefinition. So kann ein Attribut neu definiert werden, wenn es in der Subklasse ihren Typ, ihren Namen, ihren Startwert oder ihre Sichtbarkeit ändert. Diesen Umstand kann man explizit mit angeben.
Beispiel:
----------------- ---------------------------------------
| Shape | | Rectangle |
-----------------<|------------------------------------------
| # height: int | | # height: double {redefines height} |
----------------- ---------------------------------------
Die Subklasse definiert hier den Datentyp für das height-Attribut neu.
Bei deinen Diagrammen solltest du übrigens noch einmal genauer drüberschauen.
- Die Assoziationspfeile sehen nicht richtig aus. Wenn ein Typ ein anderes Element besitzt oder nutzt, geht der Pfeil in die Richtung des verwendeten Typs. Wenn ein Typ ein Attribut des Typs XY hat, ist ein weiterer Assoziationspfeil zu XY redundant.
Beispiel:
----------- -------
| PetOwner |--- has --->| Dog |
------------ -------
Oder:
-------------- -------
| PetOwner | | Dog |
-------------- -------
| - dog: Dog |
--------------
Eine Faustregel, an der du dich hierbei orientieren kannst: Für komplexe Typen (wie in diesem Fall) wird der Assoziationspfeil bevorzugt. Für primitive/vordefinierte Typen (String, int, ...) nutzt man Attribute.
- Vererbungsbeziehungen werden mit einem unausgefüllten Dreieckspfeil angegeben. Bei den Typen Rectangle und Circle kann man davon ausgehen, dass sie Subtypen von Form (Shape wäre der passendere Name) sind.
- Form sollte abstrakt sein. Es ist ein Typ, von dem keine Objekte erzeugt werden können. Von dessen Subtypen (wie Rectangle) hingegen schon.
- Die draw-Methode sollte in Form deklariert werden, immerhin ist das doch eine Gemeinsamkeit aller deiner Subtypen.
- Das Attribut breite hat keinen Typ
- Mische bei den Bezeichnern nicht Deutsch und Englisch. Nutze nur eine Sprache. Für den Typ Pong wäre es gut, einen passenderen Namen (wie Game) zu finden.
- Die Box für den Typ Einstellungen ist nicht richtig gezeichnet. Ich würde dir an der Stelle das Programm NClass empfehlen.
- Das zweite Diagramm unterscheidet sich eklatant zum ersten. Verschiedene Beziehungen erscheinen unlogisch (Bsp.: Der Schläger des Spielers steht in keiner Verbindung zum Typ Schlaeger. Man hat den Eindruck, dass das zweite Diagramm nicht die konkrete Code-Implementation vorgegeben hat, sondern deine (wohl wirre) Code-Implementation das Diagramm. Das darf nicht sein. Die Planung kommt immer vor der Implementation.