Softwaretechnik

Softwaretechnik
Zusammenfassung der Methodik der Vorlesung im Wintersemester 2010/2011
INHALT
1 Objektorientierte Analyse ............................................................................................................... 3
1.1 Use Case – Modell ................................................................................................................... 3
1.1.1 Aktoren bestimmen ......................................................................................................... 3
1.1.2 Anwendungsfälle bestimmen .......................................................................................... 3
1.1.3 Diagramm erstellen ......................................................................................................... 3
1.1.4 Beschreibungen anfertigen ............................................................................................. 3
1.2 Statisches Modell .................................................................................................................... 4
1.2.1 Klassen identifizieren ....................................................................................................... 4
1.2.2 Assoziationen bestimmen ............................................................................................... 4
1.2.3 Attribute identifizieren .................................................................................................... 5
1.2.4 Vererbung einführen ....................................................................................................... 5
1.2.5 Modell überarbeiten ....................................................................................................... 5
1.3 Dynamisches Modell ............................................................................................................... 5
1.3.1 Interaktionsdiagramme entwickeln ................................................................................ 5
1.3.2 Zustands- und Aktivitätsdiagramme entwickeln ............................................................. 6
2 Objektorientierter Entwurf ............................................................................................................. 7
2.1 Objektentwurf ......................................................................................................................... 7
2.1.1 Operationen hinzufügen ................................................................................................. 7
2.1.2 Assoziationen ausrichten ................................................................................................. 8
2.1.3 Zugriffsrechte bestimmen ............................................................................................... 8
2.1.4 Mehrfachvererbung auflösen .......................................................................................... 8
2.1.5 Wiederverwendung von Klassen ..................................................................................... 8
2.2 Realisierung von Zustandsdiagrammen .................................................................................. 8
2.2.1 Prozedurgesteuerte Realisierung .................................................................................... 9
2.2.2 Realisierung durch Fallunterscheidung ........................................................................... 9
2.2.3 Realisierung durch Zustandsobjekte ............................................................................... 9
2.2.4 Realisierung durch eine Zustandsmaschine .................................................................. 10
2.3 Systementwurf ...................................................................................................................... 10
2.3.1 Grundlagen .................................................................................................................... 10

2.3.2 Fassadenklassen ............................................................................................................ 10
2.3.3 Schichtenarchitekturen ................................................................................................. 11
2.3.4 Drei-Schichten-Architektur für betriebliche Informationssysteme ............................... 11
2.3.5 Kontrollobjekte .............................................................................................................. 11
2.3.6 Beobachter .................................................................................................................... 11
Anmerkung:
Der folgende Text versteht sich mit Blick auf die Klausur als Zusammenfassung zur gleichnamigen Vorlesung
und fußt dazu natürlich auf die von Prof. Dr. Hennicker erstellten Inhalte.
Quelle: http://www.pst.ifi.lmu.de/Lehre/wise-10-11/swtechnik
Der Autor übernimmt keinerlei Gewährleistung dafür, dass diese Zusammenfassung inhaltlich vollständig oder
korrekt ist. Die Benutzung erfolgt also zu eigenem Vergnügen – und auf eigene Gefahr. ;)
Daniel Buschek

3
1 OBJEKTORIENTIERTE ANALYSE
Ziel: Die Anforderungen an das Softwaresystem erfassen und präzise und verständlich beschreiben.
1.1 Use Case – Modell
Input: Informelle, knappe Beschreibung, z.B. aus einem Interview.
Ziel: Die (vom Kunden) gewünschte Funktionalität des Systems beschreiben.
1.1.1 Aktoren bestimmen
Zunächst sollen die Aktoren bestimmt werden, die mit dem System interagieren:
• Wer benützt das System?
• Wer holt Informationen vom System?
• Wer liefert dem System Informationen?
1.1.2 Anwendungsfälle bestimmen
Nun können die Anwendungsfälle bestimmt werden; diese beschreiben die Aufgaben, die das
System für einen oder mehrere Aktoren erledigen soll.
Hierbei besteht oft die Schwierigkeit, die richtige Granularität zu finden: Welche Alternativen
gehören noch zum selben Anwendungsfall, was ist schon ein neuer Anwendungsfall?
1.1.3 Diagramm erstellen
Nachdem Aktoren und Anwendungsfälle bestimmt wurden, kann ein entsprechendes
Anwendungsfall-Diagramm (Use Case – Diagramm) erstellt werden. Eventuell kann hier noch eine
kurze Beschreibung der Aktoren und Anwendungsfälle angegeben werden.
1.1.4 Beschreibungen anfertigen
In diesem letzten Schritt werden die Anwendungsfälle (iterativ) mit Beschreibungen versehen. Diese
haben folgendes Format:
• Name des Anwendungsfalls
• Kurzbeschreibung
• Vorbedingung: Was ist Voraussetzung für eine erfolgreiche Ausführung des Anwendungsfalls?
• Nachbedingung: Beschreibung des Zustands nach erfolgreicher Ausführung.
• Primärszenario: Beschreibt den schrittweisen Ablauf im Normalfall.
• Sekundärszenarien: Beschreiben den schrittweisen Ablauf bei Fehlerfällen oder Optionen.

4
1.2 Statisches Modell
Input: Das Use Case – Modell, die ursprüngliche Problembeschreibung, erweitert um Experten- und
Allgemeinwissen.
Ziel: Ein Klassendiagramm, noch ohne Operationen.
1.2.1 Klassen identifizieren
Es sollen die Klassen für das statische Modell gefunden werden. Kandidaten dafür sind Personen
bzw. Rollen, Organisationen, Gegenstände und begriffliche Konzepte (z.B. Bestellung).
Vorgehensweise:
1. Kandidaten notieren:
Hierzu durchsucht man die Use Case – Beschreibungen nach Substantiven.
2. Ungeeignete Klassen streichen:
Es sollen Klassenkandidaten gestrichen werden, die redundant, irrelevant oder vage sind. Ebenso
eignen sich manche der gefundenen Substantive möglicherweise besser als Attribut einer anderen
Klasse oder es handelt sich um eine Tätigkeit.
3. Fehlende relevante Klassen hinzufügen:
Hinweise auf fehlende Klassen ergeben sich aus Problembereichswissen und aus Attributen vom
vorigen Schritt, zu denen es noch keine Klassen gibt.
1.2.2 Assoziationen bestimmen
Nun sollen Assoziationen zwischen den Klassen gefunden werden. Kandidaten dafür sind
physische/logische Verbindungen mit bestimmter Dauer, z.B. konzeptionelle Verbindungen
(„arbeitet für“), Besitz („hat“, „ist Teil von“) sowie häufige Zusammenarbeit von Objekten zur Lösung
einer Aufgabe.
Vorgehensweise:
1. Kandidaten notieren:
Hierzu durchsucht man die Use Case – Beschreibungen nach Verben, Substantiven im Genitiv („die
Karte des Kunden“) oder Possessivpronomen („seine“, „ihre“, …). Achtung: Verben bezeichnen oft
Aktivitäten statt Beziehungen.
2. Ungeeignete Assoziationen streichen:
Vor allem auf redundante (abgeleitete) Assoziationen sollte verzichtet werden.
3. Fehlende relevante Assoziationen hinzufügen:
Analog zur Vorgehensweise beim Bestimmen der Klassen.
4. Multiplizitäten und ggf. explizite Rollennamen hinzufügen:
Im Zweifelsfall kann man die Multiplizitäten aber auch noch weglassen und erst später bestimmen.

5
1.2.3 Attribute identifizieren
Bei der Suche nach Attributen gelten folgende Richtlinien:
• Es sollen nur für die Anwendung relevante Attribute eingeführt werden.
• Attribute sollen keine Objekttypen haben, dafür werden Assoziationen verwendet.
• Die genauen Attributtypen können noch weggelassen werden.
1.2.4 Vererbung einführen
In der Analyse geht es hierbei vor allem um Generalisierung: Gemeinsame Merkmale der
vorhandenen Klassen (Attribute, Assoziationen) können in einer Oberklasse zusammengefasst
werden. Außerdem sollte hier bestimmt werden, welche Klassen abstrakt sind.
1.2.5 Modell überarbeiten
Im Prinzip besteht dieser Schritt aus dem „Überdenken“ der bisherigen Arbeit. Checkliste:
• Fehlen Klassen oder Assoziationen?
• Sind alle Klassen und Assoziationen notwendig?
• Sind alle Attribute und Assoziationen richtig platziert?
• Gibt es Assoziationen, bei denen ein Qualifizierer sinnvoll wäre?
• Welche Typen haben/bekommen die Attribute?
• Fehlen noch Multiplizitäten?
1.3 Dynamisches Modell
Input: Use Case – Beschreibungen (Szenarien) und statisches Modell.
Ziel: Entwurf von Interaktionsdiagrammen für jeden Anwendungsfall, auf deren Basis dann Zustandsund
Aktivitätsdiagramme abgeleitet werden.
1.3.1 Interaktionsdiagramme entwickeln
Interaktionsdiagramme beschreiben die Zusammenarbeit und den Nachrichtenaustausch zwischen
mehreren Objekten. In UML gibt es Sequenzdiagramme und Kommunikationsdiagramme. Im
Rahmen der Vorlesung bzw. Übung wurden nur Sequenzdiagramme auch wirklich verwendet.
Vorgehensweise:
1. Identifizieren der Nachrichten, die innerhalb eines Anwendungsfalls ausgetauscht werden und
der Objekte, die die Nachrichten senden und empfangen.
2. Konstruktion von Interaktionsdiagrammen für jeden Anwendungsfall bzw. dessen Szenarien.

6
1.3.2 Zustands- und Aktivitätsdiagramme entwickeln
Input: Die im vorigen Schritt erstellten Sequenzdiagramme zu den Anwendungsfällen.
Ziel: Ein Zustandsdiagramm für jede Klasse mit „interessanten Verhalten“ entwickeln (Klassen deren
Objekte einen nicht-trivialen Lebenszyklus haben). Die in den Zustandsdiagrammen auftauchenden
Operationen sollen dann mit Aktivitätsdiagrammen beschrieben werden.
Zustands- und Aktivitätsdiagramme erfassen also das vollständige Verhalten eines jeden Objekts
einer Klasse über viele Szenarien hinweg. Aktivitätsdiagramme können auch weggelassen werden,
wenn es bereits ein einziges Interaktionsdiagramm gibt, das schon das vollständige Ablauf-Verhalten
der Operation zeigt.
Kriterien für „interessantes Verhalten“:
• Ein Objekt reagiert auf gleiche Ereignisse in Abhängigkeit seines Zustands unterschiedlich.
• Mindestens ein Ereignis wird in bestimmten Zuständen ignoriert (bzw. kann dort gar nicht
auftreten).
Typische zustandsabhängige Objekte sind Kontrollobjekte für Anwendungsfälle und
Benutzerschnittstellen, Geräte (z. B. Digitaluhr) sowie Objekte mit beschränktem Fassungsvermögen
(voll, leer).
Klassifizierung von Zuständen:
• stabiler/inaktiver Zustand: Ein Zustand, dem keine Aktivität zugeordnet ist.
• Aktivitätszustand: Ein Zustand, dem eine Aktivität zugeordnet ist und der nur durch ein (evtl.
bedingtes) Completion Event verlassen werden kann.
Vorgehensweise zur Konstruktion eines Zustandsdiagramms:
1. Wahl eines Sequenzdiagramms, das eine typische Interaktion für ein Objekt der betrachteten
Klasse zeigt (normalweise das Sequenzdiagramm für das Primärszenario).
2. Betrachten der Lebenslinie des Objekts.
3. Bilden einer Kette von Zuständen, wobei man der Lebenslinie des Objekts folgt:
• Inaktive Phasen werden durch stabile Zustände modelliert.
• Aktive Phasen werden durch Aktivitätszustände umgesetzt, in denen lokale Operationen
zur Durchführung der Aktivität aufgerufen werden (dies wird später in den
Aktivitätsdiagrammen dargelegt).
• Eintreffende Ereignisse werden durch entsprechend markierte Transitionen von stabilen
Zuständen in Aktivitätszustände modelliert.
• Das Ende von aktiven Phasen wird durch eine Transition mit einem Completion Event
von einem Aktivitätszustand in einen stabilen Zustand umgesetzt.
4. Bilden von Zyklen für Abläufe, die wiederholt werden können.
Damit ist dann ein Sequenzdiagramm verarbeitet, freilich noch ohne die Details zu den Aktivitäten.
Die angegebenen Schritte wiederholt man für alle Sequenzdiagramme, in denen ein Objekt der

7
betrachteten Klasse eine Rolle spielt und erweitert das Zustandsdiagramm entsprechend. Meist führt
diese Erweiterung zu Verzweigungen von einem stabilen Zustand aus, der in mehreren
Sequenzdiagrammen als Ausgangszustand des Objekts auftauchte.
Anschließend folgt die Konstruktion von Aktivitätsdiagrammen für die lokalen Operationen (also die
Operationen in den Aktivitätszuständen des erstellten Zustandsdiagramms).
Außerdem kann das Zustandsdiagramm evtl. noch durch das Hinzufügen von Bedingungen bei den
von Aktivitätszuständen ausgehenden Transitionen verfeinert werden. Dies ist wichtig, damit das
Zustandsdiagramm deterministisch ist!
Zuletzt müssen evtl. auch noch weitere angegebene Sekundärszenarien integriert werden, für die
gar kein Sequenzdiagramm erstellt wurde.
2 OBJEKTORIENTIERTER ENTWURF
Input: Das statische und dynamische Modell der objektorientierten Analyse.
Ziel: Ein Modell der Systemimplementierung; also wie die einzelnen Aufgaben gelöst werden.
2.1 Objektentwurf
Das statische Analysemodell wird nun erweitert und überarbeitet. Dazu verwendet man die
Informationen aus dem dynamischen Modell der Analyse. Die beiden Modelle werden also
zusammengeführt.
2.1.1 Operationen hinzufügen
Das statische Modell soll um Operationen erweitert werden.
Vorgehensweise:
1. Betrachten der Interaktionsdiagramme: Für jede an ein Objekt der Klasse K gesendete Nachricht
wird eine entsprechende Operation bei K eingeführt.
2. Betrachten der Zustands- und Aktivitätsdiagramme: Es wird eine Operation eingeführt für jedes
Call-Event eines Zustandsdiagramms und für jede in einem Aktivitätszustand aufgerufene (lokale)
Operation. Das gilt natürlich auch für Aktionen in den zugehörigen Aktivitätsdiagrammen.
3. Benutzerdefinierte Konstruktoren bei nicht-abstrakten Klassen hinzufügen.
4. Benötigte Zugriffsoperationen für Attribute und Rollen hinzufügen (also Getter- und Setter).
5. Beschreiben der Algorithmen der Operationen (z. B. in Java-Pseudocode).

8
2.1.2 Assoziationen ausrichten
Mit diesem Schritt sollen bidirektionale Assoziationen vermieden werden, was die spätere
Implementierung erleichtert. Dazu wird betrachtet, in welche Richtung die bestehenden
Assoziationen durchlaufen werden (z.B. beim Senden von Nachrichten oder Operationsaufrufen).
Wenn sich dabei herausstellt, dass dies nur in eine Richtung geschieht, wird die Assoziation
entsprechend ausgerichtet.
2.1.3 Zugriffsrechte bestimmen
Nun werden die Zugriffsrechte für Attribute, Rollennamen und Operationen festgelegt. Attribute und
Rollennamen sollten dabei nicht öffentlich zugreifbar sein.
2.1.4 Mehrfachvererbung auflösen
Dieser Schritt ist notwendig, wenn die bei der Implementierung benutzte Sprache keine
Mehrfachvererbung unterstützt (z.B. Java). Die Auflösung wird durch die Einführung einer
Schnittstelle umgesetzt.
Eine der beiden Oberklassen wird durch ein Interface ersetzt, das an ihrer Stelle von der Unterklasse
geerbt (bzw. implementiert) wird. Zudem wird eine neue Klasse erstellt, welche die entfernte
Oberklasse ersetzen soll (vermutlich gleiche Implementierung). Diese neue Klasse implementiert
ebenfalls das eingeführte Interface und wird von der Unterklasse zur Delegation bei Aufrufen der
Operationen aus dem Interface benutzt.
Beispieldiagramme dazu finden sich im Skript in Kapitel 4.1.4 (Folie 11).
2.1.5 Wiederverwendung von Klassen
Oft bestehen bereits erprobte und hochwertige Klassen, die man im Entwurf wiederverwenden
möchte. Braucht man noch mehr Funktionen als die vorhandenen, kann man diese durch
Spezialisierung in einer Subklasse hinzufügen.
Achtung: Vielleicht bietet die geerbte Klasse mehr Operationen an, als man eigentlich benötigt.
Dadurch könnte das Kapselungsprinzip verletzt werden. In einem solchen Fall bietet sich eine
Wiederverwendung durch Delegation an. Hierbei bekommt die neue Klasse ein (privates) Objekt der
wiederverwendeten Klasse, an das sie bei Bedarf Methodenaufrufe weiterleiten kann.
2.2 Realisierung von Zustandsdiagrammen
Input: Das Zustandsdiagramm einer Klasse.
Ziel: Ein Objektentwurf mit Algorithmen zur Realisierung des durch das Zustandsdiagramm
beschriebenen Verhaltens.
Zustandsdiagramme können systematisch realisiert und in den Objektentwurf integriert werden.
Dazu gibt es vier Möglichkeiten, die im Folgenden beschrieben werden.

9
2.2.1 Prozedurgesteuerte Realisierung
Bei diesem Ansatz werden Ereignisse durch erzwungene Benutzereingaben unterschieden. Das setzt
voraus, dass es sich bei den Objekten um Kontrollobjekte zur Dialogsteuerung handelt und sich diese
somit an der Systemgrenze befinden.
Vorgehensweise:
Das gesamte Zustandsdiagramm wird überführt in eine Prozedur mit:
• modalen Dialogen für die (externen) Ereignisse
• bedingten Anweisungen für Verzweigungen
• Wiederholungsanweisungen für Zyklen des Diagramms
Anmerkung: Diese Methode ist heutzutage offensichtlich keine allzu gute Idee mehr; flexible
Benutzerschnittstellen sind so nur schwer zu realisieren.
2.2.2 Realisierung durch Fallunterscheidung
Hier merkt sich das Objekt seinen Zustand in Form eines Attributs. In den Operationen kann dann
anhand dieses Wertes entschieden werden, wie sie sich zu verhalten haben.
Vorgehensweise:
1. Ein Enumerationstyp stellt die endlich vielen (stabilen) Zustände dar.
2. Die Klasse bekommt ein explizites Zustandsattribut dieses Typs.
3. Die zustandsabhängigen Operationen werden durch Fallunterscheidung nach dem aktuellen
Wert des Zustandsattributs realisiert.
Vorteil: Leichte Erweiterbarkeit bezüglich neuer Operationen. Eine neue Operation wird einfach zur
Klasse hinzugefügt und nutzt die Fallunterscheidung nach dem Wert des Zustandsattributs.
Nachteil: Schlechte Erweiterbarkeit bezüglich neuer Zustände. Ein neuer Zustand bedeutet
möglicherweise Veränderungen (nämlich einen neuen Fall) bei den Fallunterscheidungen in allen
bisherigen Operationen.
2.2.3 Realisierung durch Zustandsobjekte
Ein spezielles Zustandsobjekt übernimmt hier die Ausführung der zustandsabhängigen Operationen.
Vorgehensweise:
1. Jedes Objekt der Klasse bekommt ein Zustandsobjekt, das den aktuellen Zustand repräsentiert.
2. Aufrufe von zustandsabhängigen Operationen werden an das Zustandsobjekt delegiert.
3. Das aktuelle Zustandsobjekt führt die gewünschte Aktivität aus und gibt den (neuen) Zustand
zurück, der nun mit dem Basisobjekt verbunden werden soll.

10
Vorteil: Leichte Erweiterbarkeit bezüglich neuer Zustände. Ein neuer Zustand kann einfach als neue
Unterklasse der abstrakten Zustandsklasse umgesetzt werden.
Nachteil: Schlechte Erweiterbarkeit bezüglich neuer Operationen. Eine neue Operation muss
zumindest in die Klasse und den abstrakten Zustand aufgenommen werden; möglicherweise aber
leider auch in alle bisherigen Zustands-Unterklassen.
2.2.4 Realisierung durch eine Zustandsmaschine
Dieser Ansatz realisiert das Zustandsdiagramm, in dem dieses komplett mit verbundenen Objekten
„nachgebaut“ wird.
Idee:
• Alle in einem Zustandsdiagramm vorkommenden Größen (stabile Zustände, Transitionen,
Aktivitäten, Ereignisse) werden durch Objekte dargestellt.
• Ereignisse werden von einer speziellen „Event-Handle“-Operation interpretiert.
• Das gesamte Zustandsdiagramm wird durch eine verzeigerte Objektstruktur repräsentiert.
2.3 Systementwurf
Ziel: Der Objektentwurf soll in die Systemumgebung eingebettet werden. Außerdem wird die
Systemarchitektur festgelegt.
2.3.1 Grundlagen
Die Systemarchitektur beschreibt die Gesamtstruktur des Software-Systems durch Angabe von
Subsystemen und Beziehungen zwischen diesen. Eine grobe Systemarchitektur wird meist schon zu
Beginn der Systementwicklung angegeben. Subsysteme werden durch Pakete oder durch
Komponenten (mit Schnittstellen) dargestellt.
Grundregeln:
• hohe Kohärenz (high cohesion):
Systemteile die (logisch) zusammen gehören sollen in einem Subsystem zusammengefasst werden.
• geringe Kopplung (low coupling):
Zwischen den Subsystemen sollen möglichst wenige Abhängigkeiten bestehen.
→Vorteil: Änderung und Austauschen von einzelnen Teilen wird vereinfacht.
2.3.2 Fassadenklassen
Mit Hilfe von Fasadenklassen kann eine geringe Kopplung erreicht werden. Sie vereinen die Dienste
verschiedener Klassen eines Subsystems durch Delegation der Aufrufe an die zuständigen Objekte.
Ein Beispiel dazu findet sich im Skript in Kapitel 4.3.2 (Folie 50).

11
2.3.3 Schichtenarchitekturen
In einer Schichtenarchitektur stellt jede Schicht Dienste für die darüber liegende(n) Schicht(en)
bereit. Ein bekanntes Beispiel ist das OSI-Modell.
• Bei „geschlossenen“ Architekturen darf eine Schicht nur auf die direkt darunterliegende Schicht
zugreifen, andernfalls spricht man von einer „offenen“ Architektur.
• Als Client/Server-System bezeichnet man eine Verteilung der Schichten auf verschiedene Rechner.
• Eine Schicht kann selbst aus verschiedenen Subsystemen bestehen.
2.3.4 Drei-Schichten-Architektur für betriebliche Informationssysteme
Für viele Anwendungen wird eine Drei-Schichten-Architektur gewählt. Diese besteht aus einer
Benutzerschnittstelle, dem Anwendungskern und einer Datenbankschnittstelle.
Benutzerschnittstelle:
• Behandelt Nutzereingaben (Mausklicks, Tasten)
• Ein-/Ausgabe von Daten
• Dialogkontrolle
Anwendungskern:
• Zuständig für die Anwendungslogik, also die eigentlichen Aufgaben des Problembereichs
• Ergibt sich aus dem Objektentwurf
Datenbankschnittstelle:
• Sorgt für Speicherung persistenter Daten der Anwendung und den Zugriff darauf
Daneben gibt es noch Subsysteme für allgemeine Dienste, wie etwa Kommunikationsdienste,
Dateiverwaltung oder Bibliotheken (APIs, GUI, …).
2.3.5 Kontrollobjekte
Für die Dialogsteuerung (z.B. Verwaltung mehrerer Fenster) oder zur Steuerung der Aufgaben des
Anwendungskerns werden häufig eigene Objekte verwendet. Solche Kontrollobjekte sorgen für
geringe Kopplung und haben meist ein interessantes Verhalten, das durch Zustandsdiagramme
beschrieben werden kann.
2.3.6 Beobachter
Es gilt die Sichtbarkeitsregel zu beachten: Der Anwendungskern darf die Benutzerschnittstelle nicht
kennen. Das hat den Vorteil, dass Änderungen an der GUI keine Auswirkungen auf den Code des
Anwendungskerns haben. Um die berechneten Daten dennoch anzeigen zu können, kann man mit
Beobachtern arbeiten.

12
Indirekte Kommunikation durch Beobachter:
• GUI-Objekte melden sich als Beobachter (Observer) beim Anwendungskern an (addObserver).
• Falls der Anwendungskern ein Ereignis publizieren will, benachrichtigt er alle seine Beobachter
(notifyObservers), die entsprechend reagieren (update).
• Jeder konkrete Beobachter implementiert das Interface Observer.
• Der Anwendungskern kennt (zur Programmierzeit) nur das Observer-Interface. Konkrete
Observer werden zur Laufzeit dynamisch eingebunden.