Übungsaufgaben zum Entwurfsmuster Beobachter (Observer)

Muster (1 Punkt): Beobachter (Observer), ein Verhaltensmuster.

Begründung (3 Punkte), z. B.:

• Es besteht eine 1-zu-n-Abhängigkeit: Ändert sich eine Aktivität (verschoben, abgesagt), müssen mehrere andere Objekte reagieren (Push-Hinweis, Kalender, später Chat und Warteliste).

• Das Muster sorgt dafür, dass alle angemeldeten Beobachter automatisch benachrichtigt werden, sobald Aktivitaet sich ändert.

• Aktivitaet kennt die Benachrichtigungsarten nur über ein gemeinsames Interface (lose Kopplung). Chat-Hinweis und Wartelisten-Anzeige können später als neue Beobachter ergänzt werden, ohne Aktivitaet zu ändern.

Je sinnvollem, auf das Beispiel bezogenem Argument 1 Punkt.

Je Zeile 0,5 Punkte:

Bewertung (5 Punkte):

• Aggregation zwischen Aktivitaet und Observer, hohle Raute an Aktivitaet (1 Punkt), Multiplizität 0..* beim Observer (0,5 Punkte), Multiplizität bei Aktivitaet (0..* oder 1, 0,5 Punkte); eine Komposition ist fachlich schwächer, wird aber noch mit 0,5 Punkten für das Symbol bewertet

• Aktivitaet: +addObserver(o: Observer), +removeObserver(o: Observer), +notifyObservers() je 0,5 Punkte (1,5 Punkte)

• PushHinweis und KalenderFeed: je +update() (2 × 0,75 Punkte)

Typische Fehler: Raute am Interface; update() nur im Interface, nicht in den realisierenden Klassen; die Methoden des Subjekt-Interfaces in Aktivitaet vergessen, weil die Klasse schon viele Einträge hat.

Es handelt sich um eine Realisierung (Schnittstellenimplementierung) (1 Punkt). Subject ist ein Interface: Es legt nur fest, welche Methoden es gibt, von ihm selbst können keine Objekte erzeugt werden. Aktivitaet verpflichtet sich, alle abstrakten Methoden des Interfaces – addObserver, removeObserver, notifyObservers – zu implementieren (1 Punkt). Aktivitäten können dadurch überall verwendet werden, wo ein Subject erwartet wird.

Erläuterung (2 Punkte): Realisierung bzw. Schnittstellenimplementierung. PushHinweis muss die abstrakte Methode update() des Interfaces Observer implementieren und übernimmt damit die Rolle eines Beobachters.

Begründung (2 Punkte): notifyObservers() in Aktivitaet ruft bei allen Objekten in der Liste observers die Methode update() auf, ohne deren Klasse zu kennen. Dank Polymorphie wird zur Laufzeit die jeweils passende Implementierung ausgeführt: PushHinweis verschickt einen Hinweis, KalenderFeed schreibt den Kalendereintrag. Weitere Beobachter wie ein Chat-Hinweis müssen nur Observer realisieren; Aktivitaet bleibt unverändert (lose Kopplung, Erweiterbarkeit).

Erläuterung (2 Punkte): Aggregation, eine Ganzes-Teile- bzw. „hat ein“-Beziehung: Eine Aktivität hält in ihrer Liste observers beliebig viele (auch keine) angemeldete Beobachter. Die Beziehung führt zum Interface, nicht zu den konkreten Klassen.

Begründung (1 Punkt): Die Beobachter existieren unabhängig von der Aktivität. Sie werden außerhalb erzeugt, melden sich an und ab und können mehrere Aktivitäten zugleich beobachten. Wird eine Aktivität gelöscht, müssen ihre Beobachter nicht mit gelöscht werden. Bei einer Komposition wären die Teile existenzabhängig vom Ganzen und gehörten nur zu genau einem Ganzen.

JANA Pseudo-Pascal Pseudo-Pascal (deutsch) Pseudo-Python all none

addObserver(Observer o) {
    observers.add(o)
}

removeObserver(Observer o) {
    observers.remove(o)
}

notifyObservers() {
    for (o ∈ observers) {
        o.update()
    }
}

PROCEDURE addObserver(o: Observer)
    observers.add(o)
END addObserver

PROCEDURE removeObserver(o: Observer)
    observers.remove(o)
END removeObserver

PROCEDURE notifyObservers()
    foreach o in observers
        o.update()
    next o
END notifyObservers

Prozedur addObserver(o: Observer)
    observers.hinzufuegen(o)
Ende addObserver

Prozedur removeObserver(o: Observer)
    observers.entfernen(o)
Ende removeObserver

Prozedur notifyObservers()
    für jedes o in observers
        o.update()
    Ende für
Ende notifyObservers

def addObserver(self, o):
    self.observers.append(o)
# Ende addObserver

def removeObserver(self, o):
    self.observers.remove(o)
# Ende removeObserver

def notifyObservers(self):
    for o in self.observers:
        o.update()
    # Ende for
# Ende notifyObservers

Bewertung: addObserver 1 Punkt, removeObserver 1 Punkt (je 0,5 Methodenkopf, 0,5 Hinzufügen bzw. Entfernen); notifyObservers 3 Punkte (0,5 Methodenkopf, 1,5 Schleife über alle Beobachter als For-each-Schleife oder als Zählschleife von Index 0 bis Anzahl − 1, 1 Aufruf update() am jeweiligen Element).

JANA Pseudo-Pascal Pseudo-Pascal (deutsch) Pseudo-Python all none

PushHinweis(Aktivitaet a) {
    this.aktivitaet = a
    a.addObserver(this)
}

CONSTRUCTOR PushHinweis(a: Aktivitaet)
    this.aktivitaet := a
    a.addObserver(this)
END PushHinweis

Konstruktor PushHinweis(a: Aktivitaet)
    this.aktivitaet := a
    a.addObserver(this)
Ende PushHinweis

def __init__(self, a):
    self.aktivitaet = a
    a.addObserver(self)
# Ende __init__

Bewertung: 1 Punkt Zuweisung der Referenz an das Attribut, 2 Punkte Anmeldung mit addObserver am übergebenen Objekt und Übergabe des eigenen Objekts mit this (in Pseudo-Python self). Der Methodenkopf ist vorgegeben; ohne ihn kein Abzug.

JANA Pseudo-Pascal Pseudo-Pascal (deutsch) Pseudo-Python all none

update() {
    String text = aktivitaet.getTitel()
    if (aktivitaet.getStatus() == "abgesagt") {
        text = text + " wurde abgesagt."
    } else {
        text = text + ": neuer Beginn " + aktivitaet.getBeginn()
    }
    sende(text)
}

PROCEDURE update()
    text: String := aktivitaet.getTitel()
    if (aktivitaet.getStatus() = "abgesagt") then
        text := text & " wurde abgesagt."
    else
        text := text & ": neuer Beginn " & aktivitaet.getBeginn()
    end if
    sende(text)
END update

Prozedur update()
    text: string := aktivitaet.getTitel()
    wenn aktivitaet.getStatus() = "abgesagt" dann
        text := text & " wurde abgesagt."
    sonst
        text := text & ": neuer Beginn " & aktivitaet.getBeginn()
    Ende wenn
    sende(text)
Ende update

def update(self):
    text = self.aktivitaet.getTitel()
    if self.aktivitaet.getStatus() == "abgesagt":
        text = text + " wurde abgesagt."
    else:
        text = text + ": neuer Beginn " + str(self.aktivitaet.getBeginn())
    # Ende if
    self.sende(text)
# Ende update

Bewertung: 1 Punkt Abruf der Daten über Getter an der gespeicherten Referenz aktivitaet (Pull-Modell), 1 Punkt Bedingung über den Status, 1 Punkt beide Texte, 1 Punkt Aufruf sende(text).

Beispiel: Wird der „Fotospaziergang Sparrenburg“ vom 31.10.2026 auf 16:00 Uhr verschoben, lautet der Text „Fotospaziergang Sparrenburg: neuer Beginn 31.10.2026 16:00“.

Bewertung (11 Punkte):

• je Nachricht mit zugehöriger Antwort und richtiger Beschriftung 1 Punkt: addObserver(push), verschieben(…), notifyObservers(), update(), getTitel(), getStatus(), getBeginn(), sende(text) (8 Punkte); Rückgabewerte an den Getter-Antworten sind erwünscht

• loop-Fragment mit Bedingung um update() und die Rückrufe (1 Punkt)

• Aktivierungsbalken: Konstruktor von push bis zur Rückkehr an den Client, geschachtelte Balken für die Selbstaufrufe notifyObservers() und sende(text), kurze Balken auf akt für die Getter (2 Punkte)

Typische Fehler: addObserver geht vom Client statt vom Beobachter aus; die Getter werden von akt an push geschickt (Richtung vertauscht); Antworten fehlen; der Rückweg endet nicht beim Client.

Je Fehler 1 Punkt Beschreibung, 1 Punkt Korrektur:

1. Reihenfolge in verschieben (Zeilen 2 und 3): Die Beobachter werden benachrichtigt, bevor der neue Beginn gespeichert ist. Sie holen sich in update() noch den alten Wert. Erst ändern, dann benachrichtigen.

2. Schleifengrenze (Zeile 7): Mit Index ab 0 ist die Anzahl der Beobachter minus 1 der letzte gültige Index. Die Schleife läuft einen Durchlauf zu weit bis zur Anzahl selbst und greift auf ein nicht vorhandenes Element zu (Indexfehler).

3. Aufruf am Interface (Zeile 8): Observer.update() ruft die Methode am Interface-Typ auf, nicht am jeweiligen Beobachter-Objekt. Richtig ist der Aufruf am Element der Liste: observers[i].update().

JANA Pseudo-Pascal Pseudo-Pascal (deutsch) Pseudo-Python all none

verschieben(DateTime neuerBeginn) {
    beginn = neuerBeginn
    notifyObservers()
}

notifyObservers() {
    for (int i = 0 … length(observers)-1) {
        observers[i].update()
    }
}

PROCEDURE verschieben(neuerBeginn: DateTime)
    beginn := neuerBeginn
    notifyObservers()
END verschieben

PROCEDURE notifyObservers()
    for i := 0 to length(observers) - 1 do
        observers[i].update()
    end for
END notifyObservers

Prozedur verschieben(neuerBeginn: DateTime)
    beginn := neuerBeginn
    notifyObservers()
Ende verschieben

Prozedur notifyObservers()
    zähle i von 0 bis laenge(observers) - 1
        observers[i].update()
    Ende zähle
Ende notifyObservers

def verschieben(self, neuerBeginn):
    self.beginn = neuerBeginn
    self.notifyObservers()
# Ende verschieben

def notifyObservers(self):
    for i in range(len(self.observers)):
        self.observers[i].update()
    # Ende for
# Ende notifyObservers

Eine For-each-Schleife, die für jedes Element o der Liste o.update() aufruft (wie in Teilaufgabe g), ist ebenfalls richtig und vermeidet den Grenzfehler.

Verhaltensmuster (behavioral pattern) (1 Punkt). Weitere Verhaltensmuster (1 Punkt), z. B. Strategie, Zustand, Schablonenmethode, Befehl (Command), Iterator.

Bewertung (8 Punkte):

• Generalisierung Fertigungsauftrag → StatusQuelle (durchgezogen, hohles Dreieck an StatusQuelle): 1 Punkt

• Aggregation StatusQuelle (Raute) – StatusListener mit 0..* an beiden Enden (an der StatusQuelle ist auch 1 vertretbar): 2 Punkte

• Realisierungen Kundenkonto und Werkstattplan → StatusListener (gestrichelt, hohles Dreieck): je 1 Punkt (2 Punkte)

• Fertigungsauftrag: Überschreiben der drei abstrakten Methoden +setStatus(neuerStatus: String), +getStatus(): String, +getBezeichnung(): String: je 0,5 Punkte (1,5 Punkte)

• Kundenkonto und Werkstattplan: je +statusGeaendert(q: StatusQuelle): je 0,75 Punkte (1,5 Punkte)

Hinweis: addListener, removeListener und informiereListener werden nicht in Fertigungsauftrag wiederholt. Sie sind in der Oberklasse bereits implementiert und werden geerbt.

• Fertigungsauftrag – StatusQuelle: Generalisierung/Vererbung (2 Punkte). Ein Fertigungsauftrag „ist eine“ Statusquelle. Er erbt das Attribut listener und die fertig implementierten Methoden addListener, removeListener und informiereListener und muss nur die abstrakten Methoden überschreiben. Von der abstrakten Klasse selbst können keine Objekte erzeugt werden.

• Kundenkonto – StatusListener: Realisierung (2 Punkte). StatusListener ist ein Interface ohne Implementierung. Kundenkonto verpflichtet sich, die Methode statusGeaendert selbst zu implementieren, und kann dadurch überall eingesetzt werden, wo ein StatusListener erwartet wird. Es erbt keinen Code. Eine Klasse kann viele Interfaces realisieren, aber (in Java) nur von einer Klasse erben.

• #informiereListener() (1,5 Punkte): Nur die Statusquelle selbst und ihre Unterklassen sollen die Listener informieren – genau dann, wenn sich ihr Status tatsächlich geändert hat. Fremde Klassen sollen keine Benachrichtigungen ohne Änderung auslösen können. Unterklassen wie Fertigungsauftrag müssen die Methode aber aufrufen können; deshalb protected und nicht private.

• setStatus(…) abstrakt (1,5 Punkte): Jede Art von Statusquelle (Fertigungsauftrag, später Bestellung oder Sendung) hat eigene Statuswerte und eigene Regeln für eine Statusänderung. Die abstrakte Oberklasse legt nur fest, dass es die Methode gibt, und zwingt jede Unterklasse, sie zu implementieren. Eine Unterklasse, die sie nicht überschreibt, ist selbst abstrakt; von ihr können keine Objekte erzeugt werden.

JANA Pseudo-Pascal Pseudo-Pascal (deutsch) Pseudo-Python all none

setStatus(String neuerStatus) {
    if (neuerStatus != status) {
        status = neuerStatus
        informiereListener()
    }
}

PROCEDURE setStatus(neuerStatus: String)
    if (neuerStatus <> status) then
        status := neuerStatus
        informiereListener()
    end if
END setStatus

Prozedur setStatus(neuerStatus: string)
    wenn neuerStatus <> status dann
        status := neuerStatus
        informiereListener()
    Ende wenn
Ende setStatus

def setStatus(self, neuerStatus):
    if neuerStatus != self.status:
        self.status = neuerStatus
        self.informiereListener()
    # Ende if
# Ende setStatus

Bewertung: 1 Punkt Bedingung (Vergleich mit dem bisherigen Status), 1 Punkt Zuweisung, 1 Punkt Aufruf von informiereListener() nach der Zuweisung.

JANA Pseudo-Pascal Pseudo-Pascal (deutsch) Pseudo-Python all none

protected informiereListener() {
    for (int i = 0 … length(listener)-1) {
        listener[i].statusGeaendert(this)
    }
}

protected PROCEDURE informiereListener()
    for i := 0 to length(listener) - 1 do
        listener[i].statusGeaendert(this)
    end for
END informiereListener

geschützt Prozedur informiereListener()
    zähle i von 0 bis laenge(listener) - 1
        listener[i].statusGeaendert(this)
    Ende zähle
Ende informiereListener

def informiereListener(self):  # geschützt
    for i in range(len(self.listener)):
        self.listener[i].statusGeaendert(self)
    # Ende for
# Ende informiereListener

Bewertung: 0,5 Punkte Methodenkopf, 1 Punkt Zählschleife mit richtigen Grenzen, 1 Punkt Aufruf am jeweiligen Element, 0,5 Punkte Übergabe der eigenen Instanz mit this (in Pseudo-Python self).

JANA Pseudo-Pascal Pseudo-Pascal (deutsch) Pseudo-Python all none

statusGeaendert(StatusQuelle q) {
    String status = q.getStatus()
    if (status == "versandbereit") {
        montageliste.add(q.getBezeichnung())
    } else if (status == "fehler") {
        if (montageliste.contains(q.getBezeichnung())) {
            montageliste.remove(q.getBezeichnung())
        }
    }
}

PROCEDURE statusGeaendert(q: StatusQuelle)
    status: String := q.getStatus()
    if (status = "versandbereit") then
        montageliste.add(q.getBezeichnung())
    else if (status = "fehler") then
        if (montageliste.contains(q.getBezeichnung())) then
            montageliste.remove(q.getBezeichnung())
        end if
    end if
END statusGeaendert

Prozedur statusGeaendert(q: StatusQuelle)
    status: string := q.getStatus()
    wenn status = "versandbereit" dann
        montageliste.hinzufuegen(q.getBezeichnung())
    sonst wenn status = "fehler" dann
        wenn montageliste.enthaelt(q.getBezeichnung()) dann
            montageliste.entfernen(q.getBezeichnung())
        Ende wenn
    Ende wenn
Ende statusGeaendert

def statusGeaendert(self, q):
    status = q.getStatus()
    if status == "versandbereit":
        self.montageliste.append(q.getBezeichnung())
    elif status == "fehler":
        if q.getBezeichnung() in self.montageliste:
            self.montageliste.remove(q.getBezeichnung())
        # Ende if
    # Ende if
# Ende statusGeaendert

Bewertung: 1 Punkt Abfrage des Status über die übergebene Referenz q, 1 Punkt Fall versandbereit mit Hinzufügen, 1 Punkt Fall fehler mit Entfernen, 1 Punkt Verwendung von getBezeichnung() und schlüssige Kontrollstruktur. Die Prüfung, ob die Bezeichnung in der Montageliste enthalten ist, ist erwünscht, aber nicht zwingend, wenn entfernen bei fehlendem Element nichts tut.

Erläuterung (2 Punkte):

• Pull-Modell: Das Subjekt teilt nur mit, dass sich etwas geändert hat (update() bzw. hier statusGeaendert(q) mit der Quelle). Jeder Beobachter holt sich über Getter selbst die Daten, die er braucht.

• Push-Modell: Das Subjekt schickt die geänderten Daten als Parameter gleich mit. Die Beobachter müssen nicht zurückfragen.

Der Entwurf ist eine Mischform: Übergeben wird die Quelle, die Daten werden per Pull geholt.

Stellungnahme (2 Punkte), z. B.: Jonas’ Vorschlag ist abzulehnen. Kundenname, E-Mail-Adresse und Lieferadresse sind personenbezogene Daten. Beim Push gingen sie an alle Listener, auch an den Werkstattplan, der sie nicht braucht – das widerspricht der Datenminimierung (Art. 5 Abs. 1 lit. c DSGVO). Außerdem müsste bei jedem neuen Datum die Schnittstelle aller Listener geändert werden, und StatusListener passt dann nicht mehr für Bestellungen oder Sendungen mit anderen Daten. Besser: beim Pull bleiben und KundenMail die nötigen Kontaktdaten selbst über die Bestellung abrufen lassen. Andere begründete Stellungnahmen (z. B. ein schmaler Push nur mit auftragNr und status) sind ebenfalls richtig.

1,5 Punkte je Argument, z. B.:

• Aktualität: Beim Beobachter wird der Werkstattplan sofort bei der Statusänderung informiert. Beim regelmäßigen Nachfragen (Polling) vergehen bis zu 30 Sekunden.

• Last: Polling fragt auch dann ständig nach, wenn sich nichts geändert hat – bei vielen Aufträgen und mehreren Anzeigen unnötige Datenbankabfragen. Der Beobachter arbeitet nur bei tatsächlichen Änderungen.

• Einheitlicher Ablauf und Erweiterbarkeit: Alle Interessenten (Kundenkonto, Werkstattplan, später KundenMail) werden auf dieselbe Weise informiert; neue Listener kommen ohne eigene Abfragelogik hinzu.

Reihenfolge (3 Punkte, je richtiger Position 0,75 Punkte):

Rollen (1 Punkt): Kundenkonto ist die View (Beobachter); das Objekt mit den Auftragsdaten – hier der Fertigungsauftrag bzw. die Bestellung – ist das Model (Subjekt). Schritt 3 und 4 sind genau das Beobachter-Muster im Pull-Modell.

Bei der Datenbindung wird eine Eigenschaft eines Datenobjekts mit einem Element der Benutzeroberfläche verknüpft (1 Punkt). Ändert sich der Wert im Datenobjekt (z. B. der Fertigungsstatus), zeigt das Oberflächenelement ihn automatisch an; bei einer Zwei-Wege-Bindung gelangen Eingaben (z. B. der Wunschtermin) auch automatisch zurück ins Datenobjekt (1 Punkt). Das Framework übernimmt dabei die Benachrichtigung, die sonst mit dem Beobachter-Muster selbst programmiert wird.