Arbeitsblatt: Das UFO-Spiel

EF-VI-A1
„kennt“-Beziehung (Assoziation)
Seite 1 von 4
„Widerstand ist zwecklos – wir werden assoziiert!“ – Die
„kennt“-Beziehung (Assoziation)
Das Projekt „UFO-Spiel“ – Teil 1: Vorbereitung
Dieses Projekt folgt einer ganz einfachen Spielidee. Ein kleines Ufo soll mit den Pfeiltasten der Tastatur über
den Bildschirm gesteuert werden und dabei heranfliegenden Asteroiden ausweichen. Wird das Ufo von
einem Asteroid getroffen, explodiert es und das Spiel ist beendet.
Aus Zeitgründen sind im Prototyp „EF-VI-P1-Ufospiel-Prototyp“ das Ufo und die Asteroiden zum Großteil
bereits fertig implementiert. Unten abgebildet siehst du das ausführliche UML-Klassen und
Beziehungsdiagramm mit allen Diensten, Parametern, verwendeten Klassen und „hat“-Beziehungen.
Wie man sieht ist der „zuruecksetzen()“-Dienst des
Asteroiden ein privater Dienst, da er nur vom Asteroiden
innerhalb des „bewege()“-Dienstes aufgerufen wird.
Aufgabe
1. Importiere das Projekt „EF-VI-P1-Ufospiel-Prototyp“.
2. Implementiere die Steuerung des Ufos innerhalb des „fuehreAus()“-Dienstes der Ufoszene.
3. Implementiere den „bewege(int pZiel, int pStart)“-Dienst der Klasse Asteroid. Weitere Hinweise
findest du als Kommentar im entsprechenden Dienst. Binde die Bewegung der Asteroiden in den
„fuehreAus()“-Dienst der Ufoszene ein.
4. Für schnelle Programmierer: Modifiziere das Ufo nach deinen Vorstellungen.
EF-VI-A1
„kennt“-Beziehung (Assoziation)
Seite 2 von 4
Definition „Assoziation“
In unseren bisherigen Projekten hatten Objekte immer nur Zugriff auf die Dienste eines anderen Objektes,
wenn sie dieses selbst erstellt hat. Realisiert wurde dies über die „hat“-Beziehung
(Komposition/Aggregation). Für komplexere Problemstellung genügt dieses Entwurfsschema aber nicht
mehr. Wir stoßen beispielsweise an eine Grenze, wenn mehrere Objekte unterschiedlichen Typs auf ein und
dasselbe andere Objekte zugreifen müssen: Ein Objekt kann ja nicht zwei anderen gehören!
Um dieses Problem zu lösen gibt es in der OOP die sogenannte „kennt“-Beziehung, auch Assoziation. Ein
Objekt A, welches ein Objekt B kennt, kann auf dessen öffentliche (public) Dienste zugreifen und so
Anfragen an das Objekt B stellen oder Aufträge erteilen.
Assoziation werden in einem UML-Diagramm durch normale Pfeile (  ) dargestellt. Häufig werden die Pfeile
mit der sogenannten Kardinalität beschriftet. Kennt ein Objekt vom Typ A zum Beispiel drei Objekte vom Typ
B, so wäre die Kardinalität 3. Ebenso werden häufig die Namen der Objekte an die Pfeile geschrieben. Unten
ist ein Beispiel dazu abgebildet.
In diesem Beispiel gibt es also eine Disco und diese kennt insgesamt drei DJs: Hans, Klaus und Annette. Die
Kardinalität ist also 3. In diesem einfachen Beispiel erkennt man auch bereits, wie eine Assoziation
programmiertechnisch umgesetzt werden kann: Die Objekte vom Typ DJ werden zunächst irgendwo erzeugt,
aber nicht von der Klasse Disco. Anschließend werden die DJs dem Objekt vom Typ Disco als Referenz
übergeben. Dies geschieht z. B. im Konstruktor der Klasse Disco.
[…]
//Deklaration der Objekte
DJ hans;
DJ klaus;
DJ anette;
Disco b52;
[…]
//Initialisierung der Objekte
hans = new DJ();
klaus = new DJ();
anette = new DJ();
b52 = new Disco(hans, klaus, annette);
Ab diesem Zeitpunkt kann das Objekt vom Typ Disco dann auf die öffentlichen Dienste der jeweiligen DJ’s
zugreifen, genau wie bei einer „hat“-Beziehung. Wird die Disco jedoch gelöscht, bleiben die DJ’s bestehen,
im Gegensatz zu einer „hat“-Beziehung.
EF-VI-A1
„kennt“-Beziehung (Assoziation)
Seite 3 von 4
Der Konstruktor der Disco sähe in diesem Falle vielleicht so aus:
public Disco
this.dj1
this.dj2
this.dj3
}
(DJ pDj1; DJ pDj2; DJ pDj3){
= pDj1;
= pDj2;
= pDj3;
Das Projekt „UFO-Spiel“ – Teil 2: Kollisionserkennung
Mit Hilfe des Wissens über die Assoziation möchten wir nun unser Spiel fertigstellen – noch fehlt die
Kollisionserkennung. Um eine Kollision erkennen zu können muss jeder Asteroid in der Lage sein die Position
des Ufos zu erfragen. Das Ufo gehört jedoch („hat“-Beziehung) genau wie die Asteroiden direkt zur
Ufoszene. Genau in dieser Konstellation können wir die „kennt“-Beziehung (Assoziation) nutzen. Der
Asteroid muss das Ufo ja nicht besitzen, sondern lediglich Anfragen stellen („Gib deine Position) und
Aufträge erteilen („Kollision: Explodiere!“) können. Die um diese Beziehung erweiterte und modifizierte
Version unseres UML-Diagramms sieht dann wie folgt aus:
EF-VI-A1
„kennt“-Beziehung (Assoziation)
Seite 4 von 4
Aufgaben
1. Implementiere die „kennt“-Beziehung zwischen den Asteroiden und dem Ufo. Dazu musst du:
 Ein Objekt vom Typ Ufo (mit Namen „dasUfo“) innerhalb der Klasse Asteroid deklarieren
 Die Übergabeparameter des Konstruktors der Klasse Asteroid um „Ufo pUfo“ erweitern.
 Innerhalb des Konstruktors der Klasse Asteroid die Übergabereferenz verwenden um die
Ufovariable zu initialisieren: this.dasUfo = pUfo;
2. Implementiere die Kollisionserkennung. Beachte dabei die unten abgebildeten Hinweise.
3. Passe den „bewege()“-Dienst der Asteroiden so an, dass nach jeder Bewegung die Kollision mit dem
Ufo überprüft wird und, falls das Ufo getroffen wurde, dem Ufo der Auftrag „explodiere()“ erteilt
wird.
4. Für schnelle Programmierer: Implementiere eine schöne Explosion des Ufos, indem du den
„explodiere()“-Dienst nach deinen Ideen modifizierst.
Hinweise



Ob der Ball die Zielscheibe beim Ballwurfspiel getroffen hat, war im Prinzip auch eine
Kollisionserkennung.
Eine Wurzel zieht man in Java mit Hilfe der Klasse Math : √𝑥 
Math.sqrt(x);
𝑎
Eine Potenz berechnen man in Java mit der Klasse Math: 𝑥 
Math.pow(x,a);