7. Manuelle Prüfverfahren - Fachbereich Informatik - Hochschule ...

Hochschule Darmstadt 

Fachbereich Informatik 

Nachtrag aus Objektorientierte Analyse 

und Design 

Manuelle Prüfverfahren und Entwurfsmuster 

OOAD, Prof. Dr. Wolfgang Weber SS2012, h_da, Fachbereich Informatik 1



Software Engineering 

Manuelle Prüfverfahren 


7. Manuelle Prüfverfahren 

Lernziel Manuelle Prüfverfahren 

• Sie sollen in diesem Kapitel verstehen, 

warum manuelle Prüfungen notwendig sind 

warum Reviews oft "diplomatische Missionen" sind 

was ein Review ausmacht und wie es abläuft 

dass es verschiedene manuelle Prüfverfahren gibt 

Anschließend können Sie ein Review durchführen ! 



Quiz: Welches Design ist besser? 

• Entwurf A • Entwurf B 

Lied 

Interpret-Name: String 

Intepret-Wohnort: String 

Album-Name: String 

Album-Cover: Bild 

Titel: String 

Titel-Länge: Int 

Interpret 

Name: String 

Wohnort: String 

1 

1..* 

Album 

Name: String 

Cover: Bild 

1..* 

Lied 

Titel: String 

Titel-Laenge: Int 

Wie kann man das erkennen ? 



Warum manuelle Prüfverfahren? 

Was muss geprüft werden? 

• Semantik, Konsistenz, Syntax, Vollständigkeit, Produktqualität 

durch Einsatz konstruktive Qualitätssicherung (geeigneter Verfahren beim 

Entwickeln z. B. Case-Tools) 

durch Einsatz analytische Prüfmethoden 

- dynamische Prüfmethoden 

• wie Tests 

- statische Prüfmethoden 

• wie automatische Prüfverfahren (Syntax-Checker, Konsistenz-Checker, autom. Codeanalyse) 

• Manuelle Prüfverfahren (Reviews) – insbes. für Prüfung Semantik, Qualität, Vollständigkeit 

manche Fehler oder Qualitätsmängel können nur durch 

manuelle Prüfungen gefunden werden 



Was wird geprüft? 

• Alle Arbeitsergebnisse! 

Anforderungen, Spezifikation 

Design 

Code 

Testfälle 

Dokumentation 

Projektpläne 

Prozessbeschreibungen 

Veröffentlichungen, Webauftritte 

… 



Was ist ein Review? Grundidee 

• Dokumente (Arbeitsergebnisse) werden in Reviews validiert, d. h.: 

Sie werden den Mitgliedern des Review-Teams zur Durchsicht zugeleitet 

Die Dokumente werden (oft unter Zuhilfenahme von Checklisten) von jedem 

einzelnen Review-Team-Mitglied durchgearbeitet und die Fehler oder 

Unklarheiten notiert 

Gemeinsames Durchsprechen der Dokumente und Diskussion der Fehler und 

Unklarheiten 

Protokollieren der Fehler (und evtl. Lösungsideen) 

• Verbesserung der Fehler durch den Autor (nicht in der Gruppe!) 

• Wesentliche Arten von manuellen Prüfverfahren: 

Walkthrough 

Review 

Inspektion 

Es gibt noch diverse 

Varianten davon... 



Phasen einer manuellen Prüfung 

0) Prüfanforderung 

Autor stößt den Prüfprozess an 

Phasen sind 

unterschiedlich 

ausgeprägt – je nach 

Art des Prüfverfahrens 

1) Vorbereitung 

Teilnehmer und deren Rollen festlegen 

Termine festlegen 

Dokumente verteilen 

Dokumente gemäß der zugewiesenen Rolle durcharbeiten 

2) Sitzung 

Mehrere Personen untersuchen gemeinsam ein Arbeitsergebnis 

Defekte sammeln 

Protokollieren 

Modus für die Weiterarbeit festlegen (Freigabe) 

3) Nachbearbeitung 

Korrekturen einarbeiten 

Ergebnis evtl. erneut zur Prüfung anmelden 



1) Vorbereitung 

• Teilnehmer festlegen 

Endbenutzer, fachverwandte Spezialisten, Ahnungslose,… 

• Jeder Reviewteilnehmer bekommt folgende Unterlagen: 

Prüfobjekt (z.B. OOD-Modell) 

Ursprungsobjekt (z.B. OOA-Modell) 

Erstellungsregeln (z.B. Methode zur Erstellung eines OOD-Modells) 

Fragenkatalog (z.B. "Wurde Regel xxx eingehalten?") 

• Individuelle Vorbereitung 

Jedes Mitglied arbeitet die Unterlagen individuell durch 

Die Vorbereitung muss bis zur Sitzung abgeschlossen sein. 

Jeder Prüfer sucht nach rollenspezifischen Defekten (z.B. als User, Wartung, 

Gesamtsystem-Verantwortlicher). 

Gefundene Defekte sind zu notieren. 

Die empfohlene Arbeitsgeschwindigkeit ist zu beachten 

(ca. 5-10 Seiten/h – Qualität vor Quantität!). 



2) Sitzung 

• Ablauf der Sitzung 

Entweder Zeile für Zeile durcharbeiten und gefundene Defekte dem 

Protokollführer melden oder nur in der Vorbereitung gefundene Defekte melden. 

wie ein Brainstorming 

- ohne Diskussion der einzelnen Punkte 

- keine Lösungsvorschläge, keine Kommentierung potenzieller Defekte 

• Das Protokoll soll folgende Punkte enthalten: 

Ort, Datum, Zeit, Moderator, Sonst. Teilnehmer, Prüfobjekt, Referenzunterlagen 

anonym für jeden Teilnehmer: Die benötigte Zeit für Vorbereitung, die Anzahl 

schwerer Fehler und die Anzahl geprüfter Seiten 

Defekte mit folgenden Angaben: 

- Ort und Kurzbeschreibung des Defekts 

- Bezug zu Regeln oder Checklisten 

- leichter oder schwerer Fehler 

- in der Sitzung identifiziert oder bei der Vorbereitung 

- Verbesserungsvorschläge / Fragen an den Autor 



3) Überarbeitung 

• Der Autor überarbeitet das Prüfobjekt 

Änderungen werden an Hand des Protokolls eingearbeitet 

im Protokoll wird notiert, welche Aktionen pro Protokolleintrag unternommen 

wurden 

Evtl. müssen Änderungsanträge für Referenzprodukte gestellt werden 

• Freigabe des Prüfobjekts 

evtl. erst nach erneuter Überprüfung 



Varianten von Reviews 

• Je nach Anwendung verwendet man verschieden aufwändige Prüfverfahren 

für unkritische Anwendungen: "Walkthrough" 

- z.B. Forschungsprototyp, Vorversionen etc. 

• schnelle Durchsicht mit wenigen Beteiligten im Hinblick auf grundlegende (Denk)fehler 

• 2-3 Teilnehmer, Autor ist auch Moderator, wenig (keine) Vorbereitung, Prüfobjekt wird vom 

Autor vorgetragen, Autor entscheidet. (Variante: Durcharbeiten durch Gutachter und nur 

Durchsprache von Fehlern, Verbesserungsvorschlägen und Fragen) 

für normalkritische Anwendungen: "Review" 

- z.B. Textverarbeitung, Computerspiel, Entwurfs-Tool etc. 

• mittelgründliche Untersuchung mit grundlegenden Formalitäten 

• 3 - 4 Teilnehmer, spezieller Moderator, Protokollführer, Autor ist passiv, zusätzl. Planung, 

Vorbereitung und Protokoll, Prüfteam gibt Empfehlung an Manager, evtl. Nachprüfung 

für kritische Anwendungen: "Formale Inspektion" 

- z.B. Steuersoftware von Flugzeugen, ABS, Kontrolle eines Atomkraftwerks etc. 

• besonders gründliche und formale Untersuchung mit vielen Beteiligten 

• 4 – 5 Teilnehmer, zusätzl. Vorleser, zusätzl. formale Eingangsprüfung und Freigabe. 

Achtung! Der Begriff Review wird oft als Oberbegriff für alle 

manuellen Prüfverfahren verwendet. 



Formular zur Durchführung von Reviews: mit Beispiel 

Ort, Datum Darmstadt, 01.10.13 

Reviewdauer Start: 14:00 Ende: 16:00 

Autor, Moderator, Gutachter A. Utor (A), M. Oterator (M), P. Rüfer (G), G. Utachter (G) 

Prüfobjekt 

Referenzunterlagen 

CocktailPro_Entwuf_V0.9 

Doku OOA CocktailPro_V1.0 

Geschäftspräsentation Cocktail4U vom 10.09.13 

Use Cases CocktailPro V1.0 

Fortsetzung nächste Folie 



Formular zur Durchführung von Reviews: mit Beispiel 

Schwere Defekte 

protokolliert (M) 

Leichte Defekte 

protokolliert (m) 

Verbesserungsvorschläge 

(I) 

Fragen an 

den Autor (?) 

Neu entdeckte 

Defekte (Nm) 

Reviewergebnis 

3 8 1 2 2 

Freigabe nach Überarbeitung 

Reviewprotokoll 

Lfd. Nr. 

Klassifikation 

Beschreibung Relevante Regel / 

Checkliste 

1. m Namenskonvention verletzt durch Klasse Rezeptbuch Naming Conventions 

2. M Assoziation zwischen m_Waage und m_Dosierer fehlt Doku OOA S.17 

…….. 

OOAD, Prof. Dr. Wolfgang Weber SS2012, h_da, Fachbereich Informatik 

14


Qualitative Nutzenbetrachtung für Reviews 

• Aufwand und Nutzen von Reviews (Erfahrungswerte) 

Aufwand 

- 15-20% des Erstellungsaufwands des Prüfobjekts 

- Die Trainings- und Einführungskosten fallen pro Team nur einmal an 

Nutzen 

- 60-70% der Fehler in einem Dokument werden gefunden 

- Reduktion der Fehlerkosten in der Entwicklung von 75% und mehr 

- Nettoeinsparungen für die Entwicklung ca. 20%, für die Wartung ca. 30% 

- Korrektur von Fehlern in frühen Phasen verursachen nur einen Bruchteil der Kosten 

als wenn Fehler erst bei Abnahme oder nach Einführung gefunden werden 

• „Return on Investment“ (RoI) 

Der RoI ergibt sich aus dem Verhältnis der ersparten Ingenieurstunden dividiert 

durch die Kosten. Dieser Wert ist viel besser als für viele andere Investitionen. 

Die Investition zahlt sich schnell aus 



Voraussetzungen für manuelle Prüfmethoden 

• Planung 

Feste Einplanung des notwendigen Aufwands und der benötigten Zeit 

Jedes Mitglied des Prüfteams muss in der Prüfmethode geschult sein 

keine Überlastung einzelner Mitarbeiter durch Teilnahme an Prüfungen 

• Organisation & Kultur 

Hohe Priorität der Prüfungen beim Projektleiter / im Management / in der 

Mannschaft 

Kurzfristige Durchführung der Prüfung 

Prüfungsergebnisse werden nicht eingesetzt zur Beurteilung von Mitarbeitern 

Vorgesetzte (und Zuhörer) sollen an den Prüfungen nicht teilnehmen 



Der Mensch in manuellen Prüfmethoden 

• Wichtige Grundeinstellung: 

es geht nicht darum keine Fehler zu machen! 

es geht darum, mit möglichst wenigen Fehlern weiter zu machen! 

Ihre Kollegen helfen Ihnen dabei! 

bei einer Durchsprache / Diskussion treten Missverständnisse zu Tage 

Menschen mit unterschiedlichem Hintergrund denken an andere Dinge 

• Bei allen Vorteilen 

es wird die (harte) Arbeit eines Menschen kritisiert 

nicht alle Menschen können damit gut umgehen 

deshalb: Vorsicht mit der Form der Kritik: 

- immer sachlich bleiben 

- keine persönlichen Angriffe 

- konstruktive Kritik üben 



Faktor Mensch 

Die Grundeinstellung ist entscheidend! 

Wegen der Qualitätssicherung muss ich… 

Ich hab's mir genau angeschaut! 

Es funktioniert doch! 

Die wollen bloß mein Baby schlecht 

machen! 

Ich hab keine Zeit für so etwas… 

Ich will gerne…, damit die Qualität stimmt 

Viele Augen sehen mehr… 

Es gibt immer Fehler! 

Die helfen mir meine Arbeit besser zu 

machen! 

Die Zeit hole ich durch die entdeckten 

Fehler locker raus… 



Zusammenfassende Bewertung manueller Prüfmethoden 

Oft die einzige Möglichkeit, die Semantik zu überprüfen 

- Notwendige Ergänzung werkzeuggestützter Überprüfungen (für Syntaxprüfungen etc.) 

- Effizientes Mittel zur Qualitätssicherung 

Verantwortung für die Qualität der geprüften Produkte wird vom ganzen Team 

getragen 

Verbreiterung der Wissensbasis der Teilnehmer 

Prüfteam lernt die Arbeitsmethoden seiner Kollegen kennen 

Autoren bemühen sich um eine verständliche Ausdrucksweise, 

da mehrere Personen das Produkt begutachten 

Unterschiedliche Produkte eines Autors werden von Prüfung zu Prüfung besser 

In der Regel aufwändig 

- Bis zu 20% der Erstellungskosten des zu prüfenden Produkts 

- aber die Investition zahlt sich schnell aus 

Autoren geraten u. U. in eine psychologisch schwierige Situation 

- »Sitzen auf der Anklagebank« 

- »Müssen sich verteidigen« 



1. Beispiel: Review der Anforderungen 

• Das Review-Team besteht aus 3 bis 7 Teilnehmern 

• Neben dem Autor und dem Moderator sollen folgende Personen dabei sein: 

Vertreter der Anwenderseite (Stakeholders) wie 

- Auftraggeber, 

- zukünftige Benutzer, 

- Anwendungsexperten, 

Vertreter der IT-Seite wie 

- Systemanalytiker, 

- Entwickler, 

- Tester 

der Projektleiter 

• Es wird geprüft, ob alle Anforderungen in Anforderungsspezifikation richtig 

modelliert sind (Use-Cases, Domainklassen, Benutzerschnittstelle, 

Prototypen, nichtfunktionale Anforderungen) 



2. Beispiel: Code-Review - Vorbetrachtung 

• Es soll die Qualität von Quellcode geprüft werden 

In modernen Projekten gibt es sehr viel Code 

Der Aufwand für eine manuelle Prüfung ist entsprechend hoch 

Vor dem Review werden Tools verwendet um möglichst viele Probleme vorher zu 

erkennen und zu beseitigen: 

Compiler auf hohem Warning-Level, Tools zur "Statischen Code Analyse" 

(z.B. QA-C++, LINT++) etc. 

• Moderne Tool erkennen viele (potenzielle) Probleme 

d.h. ohne den 

Code auszuführen 

- Falsche oder inkompatible Datentypen, uninitialisierte oder unbenutzte Variablen 

- Fehlerträchtige Zugriffe über Pointer oder auf Arrays 

- Zuweisungen mit fehlerträchtiger Priorisierung / fehlender Klammerung (z.B. a-- = b++) 

- übermäßig komplizierte Ausdrücke 

- Verstöße gegen Programmierrichtlinien (die u.a. fehlerträchtige Konstrukte verbieten) 

- Unvollständige Fallunterscheidungen (z.B. switch ohne default)? 

- uvm. 



2. Beispiel: Code-Review - Durchführung 

• Vorbereitung: 

Der Code wird mit durchgehenden Zeilennummern an alle Teilnehmer verteilt 

zusätzlich wird eine Kurzbeschreibung zu Funktion und Aufbau des Codes und 

die zugrundeliegende Designbeschreibung verteilt 

es werden maximal 250-300 Zeilen Code betrachtet 

der Code wurde vorher mit Tools auf die Einhaltung der Programmierrichtlinien 

und potenzielle Fehler analysiert 

• Das Review-Team besteht aus 3 bis 5 Teilnehmern 

- der Entwerfer des umgesetzten Software-Designs 

- mehrere Entwickler (darunter der Autor) 

- Entwickler von Software, die Schnittstellen zur analysierten Software hat 

- einem Tester / Integrator 

• Es wird geprüft, wie gut die Code-Qualität einer Anwendung ist 

Verbesserung des Quellcodes 



2. Beispiel: Code-Review - Checkliste (I) 

• Funktion 

Compiliert bzw. läuft das Programm? 

Erfüllt die Lösung die Aufgabenstellung? 

- Wurden Teile der Aufgabenstellung nicht oder mangelhaft implementiert? 

Gibt es Fälle, in denen das Programm die falsche Lösung liefert? 

- Sind boolesche Ausdrücke korrekt? 

- Werden alle Fälle bei Fallunterscheidungen berücksichtigt? Wird jede Schleife richtig 

beendet? Ist Schrittzahl nicht eins zu hoch oder zu niedrig? 

- Kann es Über- oder Unterlauf in Zwischenergebnissen geben? Können Ungenauigkeiten 

durch Dualdarstellung auftreten? 

- Wurde die Priorität der Operationen beachtet? Sind ganzzahlige Divisionen korrekt? 

- Sind Vergleichs-/ Zuweisungsoperationen korrekt verwendet? 

- Werden Eingabedaten auf Gültigkeit geprüft? 

Gibt es Mängel, durch die das Programm abstürzen kann? 

Es muss alles geprüft 

werden, was die eingesetzten 

Tools nicht finden können! 

- Durch falsche Berechnungen (Möglichkeit der Division durch Null) 

- Durch falsche Pointerarithmetik, Endlosschleifen (falsche Schleifenbedingungen) 



2. Beispiel: Code-Review - Checkliste (II) 

• Lösung 

Wurde ein effizienter Lösungsweg gewählt? 

- Bezüglich Speicher? Bezüglich Laufzeit? Gibt es überflüssige Schleifen, Abfragen 

oder Anweisungen? ... 

Ist die Codierung gut gewählt? 

- Gibt es globale Variablen? Sind die Klassen und Methoden geschickt aufgeteilt? Gibt 

es redundante Codeteile? ... 

• Dokumentation 

Ist die Lösungsidee als Kommentar angegeben? 

Sind die Kommentare ausreichend um das Programm zu verstehen? 

- Sind die Kommentare aussagekräftig? 

- Gibt es überflüssige Kommentare? 

Sind die Kommentare durchgehend? 

- Sind einzelne Teile nicht dokumentiert? 

- Wurde durchgehend eine Sprache verwendet? 






2. Beispiel: Code-Review - Checkliste (III) 




• Umsetzung 

Wurden die Programmierrichtlinien eingehalten? 

Sind die Namen von Methoden, Klassen und Variablen sinnvoll und richtig? 

nicht: A = B + (C / 100) * B, sondern: brutto = netto + (Mwst_Satz / 100) * netto 

Gibt es ähnliche Variablennamen? 

Sind boolesche Ausdrücke, arithmetische Ausdrücke nicht überkompliziert? 

Wurden globale Variablen eingesetzt? Ist das wirklich notwendig? 

Es gibt viele Checklisten im Internet! 

siehe z.B. www.reviewtechnik.de 



Kontrollfragen zu manuellen Prüfverfahren 

• Warum sind manuelle Prüfungen notwendig? 

• Wie läuft ein Review ab? 

• Warum ist der Autor in einer Begutachtung in einer schwierigen Situation? 

• Wie unterscheidet sich eine Inspektion (ein Walkthrough) von einem Review 

• Wenn Sie ein Verfahren für eine formale Spezifikation eines Systems 

verwenden – brauchen Sie dann noch manuelle Prüfverfahren? 

• Was passiert, wenn Sie wegen Termindrucks die Reviews ausfallen lassen, 

und zur nächsten Entwicklungsphase übergehen? 

Können Sie jetzt ein Review durchführen? 




Objektorientierte Analyse und Design 

Entwurfsmuster 


6.1 Entwurfsmuster 

Muster (Patterns) 

„Auf der Grundlage von 

Erfahrung und der 

Reflexion darüber... 

...können wir 

wiederkehrende 

Muster erkennen ... 

Einmal erkannte Muster 

leiten unsere 

Wahrnehmung.“ 

M.C. Escher: Luft und Wasser 8 



Ein Problem aus der IT Welt 

• Stellen Sie sich vor, Sie sollen die Systemuhr für ein modernes 

Betriebssystem implementieren 

Polling soll vermieden werden 

Bereitstellung der Zeit und des Datums 

Unterstützung für eine im Voraus nicht bekannte Anzahl von Interessenten 

(Word, Tray-Clock, ...) 

Die Lösung soll möglichst übertragbar sein (z.B. für den Batteriestatus) 

• Entwerfen Sie Komponenten mit Verantwortlichkeiten und Beziehungen 

Analysieren Sie folgende Szenarien 

1. Wenn sich die Uhrzeit ändert soll sie in anderen Programmen wie word etc. (ohne 

Polling) angezeigt werden 

2. Interessenten kommen während der Laufzeit hinzu (oder fallen weg) 

3. Analoge Aufgabe: Ermitteln des Batteriestatus des Rechners 



1. Die Uhrzeit ändert sich und soll (ohne Polling) angezeigt werden 

Systemuhr 

Datum 

Zeit 

gibStunde() 

setzeStunde() 

... 

Zeitgeber 

Zeit_Beobachter 

UhrClient 

Zeit 

anzeigen() 

aktualisiere() 

• Idee: Drehe den Spieß um und "sage Bescheid", wenn sich die Zeit ändert! 

Bei einer Zeitänderung ruft die Systemuhr bei allen UhrClients eine Methode auf 

UhrClients besorgen sich dann von der Systemuhr die erwünschten Daten 

Definiere dazu beim Client eine Methode aktualisiere() 

kein Polling und dennoch immer die aktuelle Uhrzeit! 

Frage: Wenn Interessenten jederzeit hinzu kommen können – Wie? 



2. Interessenten kommen während der Laufzeit hinzu (oder fallen weg) 

Systemuhr 

Datum 

Zeit 

gibStunde() 

setzeStunde() 

... 

meldeAn(Beobachter) 

meldeAb(Beobachter) 

benachrichtige() 

realisiert durch list of * Beobachter 

1 

Zeitgeber 

* 



Zeit 

Beobachter 

{abstract} aktualisiere() 

UhrClient 


anzeigen() 

• Idee: Alle Interessenten (UhrClients) "registrieren" sich bei der Systemuhr 

Bei einer Zeitänderung ruft die Systemuhr in ihrer Methode benachrichtige() bei 

allen registrierten Clients die Methode aktualisiere() auf 

Aber das geht nur, wenn alle UhrClients zu einer Klasse gehören! 

Einführung einer (abstrakten) Oberklasse ("Beobachter") und 

Verschiebung der Assoziation 

Frage: Analoge Aufgabe für Batteriestatus? 



3. Auslagern der allgemeinen Funktionen 

Subjekt 




Systemuhr 

Datum 

Zeit 

gibStunde() 

setzeStunde() 


... 

1 Zeitgeber 

Zeit_Beobachter * 

Zeit_Beobachter * 

Zeit 

UhrClient 


anzeigen() 

• Idee: Das "Registrieren und Benachrichtigen" ist ein allgemeines Verfahren – 

unabhängig von den bereitgestellten Daten 

Herausziehen dieses Teils durch Spezialisierung ("Subjekt") ... und fertig ist das 

Beobachter-Muster 

Verschieben der Assoziation zum Benachrichtigen 

Beobachter 




Ein anderes Problem mit der gleichen Lösung 

Mehrere Diagramme hängen von einem 

gemeinsamen Datenobjekt ab 

Änderungen der Daten sollen in allen 

Diagrammen angezeigt werden 

Die Anzahl der Diagramme ist variabel 

Säule 1: ........... 

Säule 2: a=50% 

b=30% 

c=20% 

Säule 3: .......... 

90 

80 

70 

60 

50 

40 

30 

20 

10 

0 

Säule 1 

Säule 2 

Säule 3 

Dieses Problem taucht immer wieder auf! 

Das Design-Pattern Beobachter bzw. 

Observer bzw. "publish-subscribe" 

bietet eine allgemeine Lösung dafür! 

Segment 1 

Segment 2 

Segment 3 



Ein anderes Problem mit der gleichen Lösung 

es gibt eine Datenbasis ("Subjekt") 

es gibt mehrere "Beobachter" 

das Subjekt benachrichtigt die 

Beobachter über Änderungen 

Säule 1: ........... 


b=30% 

c=20% 

Säule 3: .......... 

90 

80 

70 

60 

50 

40 

30 

20 

10 

0 

Säule 1 

Säule 2 

Säule 3 

1.) Benachrichtigung 

über Änderung 

2.) Holen der 

Veränderungen 

(Aufruf gibt Zustand zurück) 

Segment 1 

Segment 2 

Segment 3 



Beobachtermuster (Observer Pattern) 

Subjekt 

Beobachter 

* 

Beobachter 





abstrakt 

KonkretesSubjekt 

subjektZustand 

gibZustand() 

setzeZustand() 

1 

Subjekt 

daten-speichernde 

Instanz 

Säule 1: ........... 


b=30% 

c=20% 

Säule 3: .......... 

KonkreterBeobachter 

beobachteterZustand 


daten-verwendende 

Instanz 

Bei Veränderung benachrichtige(): für alle angemeldeten Beobachter b: {b->aktualisiere} 

Nach Benachrichtigung aktualisiere(): {beobachteter Zustand = subjekt->gibZustand} 

Frage: Welche Instanzen gibt es? 



Beobachtermuster (Observer Pattern): Aufrufverhalten 


einKonkretesSubjekt: 

konkretesSubjekt 

einKonkreterBeobachter: 

konkreterBeobachter 

einAndererKonkreterBeobachter: 

konkreterBeobachter 



gibZustand() 

return(Zustand) 


gibZustand() 

return(Zustand) 

für jeden 

angemeldeten 

Beobachter 



Beobachtermuster (Observer Pattern): Einsatz in der Modellierung 

Subjekt 

Beobachter 

* 

Beobachter 





abstrakt 

KonkretesSubjekt 


gibZustand() 


1 Subjekt 

KonkreterBeobachter 



• Ein Pattern ist eine (weltweit) bekannte Musterlösung! 

Bitte ordnen Sie die Klassen auch genau so an (evtl. als eigenes Diagramm) 

benennen Sie die Methoden auch so – passen Sie nur die Parameter an 



Beobachtermuster – Beispielcode Digitaluhr 

Struktur: 

Subjekt 

Beobachter 

* 

Beobachter 





Zeitgeber 


1 Subjekt 

DigitalUhr 


gibStunde() 

... 



zeichne() 

weitere mögl. Beobachter: 

z. B. Kalender, Analoguhr 



Beobachtermuster – Beispielcode Digitaluhr 

class Subjekt{ 

public: 

virtual ~Subjekt(); 

virtual void meldeAn(Beobachter*); 

virtual void meldeAb(Beobachter*); 

virtual void benachrichtige(); 

protected: 

Subjekt(); 

private: 

Liste _beobachter; 

}; 

void Subjekt::meldeAn(Beobachter* beobachter) { 

_beobachter->haengeAn(beobachter); //Methode von Liste 

} 

class ZeitGeber : public Subjekt { 

public: 

ZeitGeber(); 

virtual int gibStunde(); 

virtual int gibMinute(); 

virtual int gibSekunde(); 

void tick(); // zählt jede Sekunde 

// und ruft dann 

// benachrichtige() auf 

}; 

class Beobachter { 

public: 

virtual ~Beobachter(); 

virtual void aktualisiere(Subjekt* 

dasGeaenderteSubjekt)=0; // pure virtual 

protected: 

Beobachter(); 

}; 

void Subjekt::meldeAb(Beobachter* beobachter) { 

_beobachter->entferne(beobachter); 

} 

void Subjekt::benachrichtige() { 

ListenIterator iter(_beobachter); 

for(iter.start(); !iter.istFertig(); iter.weiter()) 

{ 

iter.aktuellesElement()->aktualisiere(this); 

} 

} 

class DigitalUhr: public Widget, 

public Beobachter{ 

public: 

DigitalUhr(ZeitGeber* subjekt){ 

_subjekt=subjekt; 

_subjekt->meldeAn(this)}; 

virtual ~DigitalUhr(){...meldeAb(this)}; 

virtual void aktualisiere(Subjekt* _subjekt){ 

zeichne()}; 

virtual zeichne(){ 

int stunde=_subjekt->gibStunde; ... } 

private: 

ZeitGeber* _subjekt; }; 



Diskussion Beobachtermuster 

• Vor- und Nachteile beim Einsatz des Beobachter-Musters 

Beobachter können leicht hinzugefügt oder entfernt werden 

Es wird nur aktualisiert, wenn sich etwas geändert hat 

Wenn es nur wenige und feste Beobachter sind, ist es etwas komplizierter als 

eine direkte Implementierung mit Abhängigkeiten 

• Anwendungen: 

E-Mail Verteiler für SW-Updates (Benachrichtigung automatisch, Aktualisierung 

manuell) 

Anzeige der Uhr in vielen Clients auf einem PC 

im Praktikum: Dosierer und Display beobachten die Waage 

• Diskussion: 

Würden Sie bei einer (traditionellen) Kuckucksuhr den Kuckuck als Beobachter 

der Uhr implementieren? 

Wie würden Sie in einem Autoradio implementieren, das CD oder Kassette oder 

... bei einer Verkehrsfunkdurchsage angehalten wird? 


Ende 


5.4.4 Überblick über die Diagramme der UML 

Übersicht der UML-Diagramme 

Diagramme 

der UML2.2 

Verhaltensdiagramme 

Strukturdiagramme 

Klassendiagramm 

Komponentendiagramm 

Use Case – 

diagramm * 

Objektdiagramm 

Aktivitätsdiagramm 

Zustandsdiagramm 

Verteilungsdiagramm 

Profildiagramm 

Kompositionsstrukturdiagramm 

Paketdiagramm 

Interaktionsdiagramme 

* Die Einordnung des Use Case Diagramms ist 

strittig. Auch wenn es dabei um das Verhalten geht, 

stellt es "nur" die Struktur von Anwendungsfällen 

und Akteuren dar. Damit wäre es eher ein Strukturals 

ein Verhaltensdiagramm. 

Sequenzdiagramm 

Kommunikationsdiagramm 

Interaktionsübersichtsdiagramm 

Timingdiagramm

7. Manuelle Prüfverfahren - Fachbereich Informatik - Hochschule ...

Sie wollen auch ein ePaper? Erhöhen Sie die Reichweite Ihrer Titel.

Template löschen?

Als Template speichern?