Software Engineering. 7. Entwurfsmuster

Transkript

1 Software Engineering 7. Entwurfsmuster

2 Gliederung Vorlesung Einführung V-Modell XT Analyse und Anforderungsmanagement Benutzungsoberflächen Architektur Entwurf Entwurfsmuster Persistenz Implementierung Konfigurationsmanagement Testen Abnahme, Einführung, Wartung und Pflege

3 Entwurfsmuster (Patterns) Einführung Erzeugungsmuster Fabrikmethode Singleton Strukturmuster Dekorierer Fassade Proxy Verhalten Beobachter Model-View-Controller Iterator Schablonenmethode Strategie

4 Beschreibung von Entwurfsmustern Entwurfsmuster (Design Patterns) geben bewährte, generische Lösungen für immer wiederkehrende Entwurfsprobleme an Beschreibung eines Entwurfsmusters Name des Musters Problembeschreibung Wo ist das Muster anwendbar (Kontext)? Welches Entwurfsproblem wird gelöst? Lösungsbeschreibung Allgemein mögliche Anordnung von Klassen und Assoziationen zur Lösung des Entwurfsproblems Dient als Schablone, die an die jeweilige konkrete Situation angepasst werden muss Konsequenzen Hinsichtlich Zeit- oder Speichereffizienz, Sprach- und Implementierungseigenschaften, Flexibilität, Erweiterbarkeit, Portabilität

5 Typen von Entwurfsmustern Erzeugungsmuster (creational patterns) Helfen, ein System unabhängig davon zu machen, wie seine Objekte erzeugt, zusammengesetzt und repräsentiert werden Strukturmuster (structural patterns) Befassen sich damit, wie Klassen und Objekte zu größeren Strukturen zusammengesetzt werden Nutzung von Vererbung zur Zusammenführung von Schnittstellen und Implementierungen Verhaltensmuster (behavioral patterns) Befassen sich mit der Interaktion zwischen Objekten und Klassen Beschreiben komplexe Kontrollflüsse

6 Klassen- und objektbasierte Erzeugungsmuster Klassenbasierte Muster Behandeln Beziehungen zwischen Klassen Werden durch Vererbungen ausgedrückt und zur Übersetzungszeit festgelegt Objektbasierte Muster Beschreiben Beziehungen zwischen Objekten, die zur Laufzeit geändert werden können Z. T. ausgedrückt durch Vererbungen, z. T. durch Aggregationen und Kompositionen

7 Fabrikmethode-Muster Fabrikmethode-Muster (factory method, virtual constructor) ist ein klassenbasiertes Erzeugungsmuster Bietet Schnittstelle zum Erzeugen eines Objekts an, wobei die Unterklassen entscheiden, von welcher Klasse das zu erzeugende Objekt ist Problemstellung Beispiel Framework für Anwendungen, die mehrere Dokumente anzeigen können Das Framework muss Objekte der Klasse MyDocument erzeugen können, kennt aber nur die abstrakte Oberklasse Document, von der es keine Objekte erzeugen darf

8 Fabrikmethode-Muster Lösung: Die Unterklassen von Application überschreiben die abstrakte Operation createdocument(), so dass sie ein Exemplar von MyDocument zurück gibt Sobald ein Objekt von MyApplication erzeugt ist, kann das Framework die Botschaft createdocument() schicken. Das Framework braucht die Klasse nicht zu kennen. createdocument() wird Fabrikmethode genannt Anwendung Wenn eine Klasse die von ihr zu erzeugenden Objekte nicht im Voraus kennen kann Wenn eine Klasse benötigt wird, deren Unterklassen selbst festlegen, welche Objekte sie erzeugen

9 Fabrikmethode-Muster allgemeine Darstellung Creator Product factorymethod() anoperation()... product = factorymethod()... ConcreteProduct «creates» ConcreteCreator factorymethod() return new ConcreteProduct Interaktionen Creator verlässt sich darauf, dass Unterklassen die Fabrikmethode korrekt implementieren Konsequenzen Verhindert, dass man anwendungsspezifische Klassen in den Code des Frameworks einbinden muss

10 Singleton-Muster Objektbasiertes Erzeugungsmuster, das sicher stellt, dass eine Klasse genau ein Objekt besitzt, und globalen Zugriff auf dieses Objekt ermöglicht Anwendbarkeit Es soll genau ein Objekt einer Klasse geben und einfacher Zugriff darauf möglich sein Wenn das einzige Exemplar durch Unterklassen erweitert wird und Klienten das erweiterte Exemplar ohne Code-Änderung verwenden sollen Interaktionen Klienten holen sich ausschließlich über die Klassenoperation getinstance() eine Referenz auf das einzige Objekt Konsequenzen Verbesserung gegenüber globalen Variablen Kann durch Unterklassen spezialisiert werden Leicht änderbar, wenn später mehrere Exemplare benötigt werden

11 Dekorierer-Muster (Decorator) Problem: Einem Objekt müssen neue Zuständigkeiten zugeordnet werden. Die Klasse darf dabei nicht geändert werden. Lösung: Dynamisches "Vorschalten" von Objekten mit dem gleichen Typ wie die "dekorierte" Klasse. comp

12 Dekorierer - Implementierung Die Implementierung ist recht eindeutig. Je nach verwendeter Programmiersprache können spezifische Sprachkonzepte eingesetzt werden Beispiel Z.B. Interfaces bei Java Ein Modem-Objekt soll zusätzlich noch folgende Zuständigkeiten erhalten: Loggen von gesendeten Daten in eine Datei Zählen der Aufrufe und Ausgabe auf die Konsole

13 Dekorierer - Bemerkungen Decorator-Objekte können dynamisch zur Laufzeit eingehängt werden Sehr flexibler Ansatz Der Aufrufer arbeitet nicht mit dem Orginalobjekt, sondern mit einem Decorator-Objekt. Decorator-Objekt hat einen andere ID als das Orginalobjekt Bei der Verwendung des Decorator-Patterns werden viele Objekte erzeugt Delegationsaufrufe kosten Performance Der Einsatz von Decorator-Objekte muss im Entwurf berücksichtigt werden Man benötigt ein Interface bzw. eine abstrakte Klasse, von der die Decorator-Klassen abgeleitet werden können

14 Fassaden-Muster Objektbasiertes Strukturmuster, das eine Schnittstelle zu einer Menge von Schnittstellen (Pakete) anbietet Definiert abstrakte Schnittstelle zur einfacheren Nutzung des Pakets Motivation Entwurfsziel: Pakete sollen möglichst lose gekoppelt sein (vereinfacht Wartbarkeit des Codes) Lösung Einführung einer Fassadenklasse, die eine vereinfachte Schnittstelle für die Funktionalität des Pakets zur Verfügung stellt Den meisten Klienten genügt diese vereinfachte Sicht Nur in komplexeren Fällen müssen Klienten hinter die Fassade schauen

15 Fassaden-Muster Client Client Package Package Facade

16 Fassaden-Muster Anwendbarkeit Wenn eine einfache Schnittstelle zu einem komplexen Paket gewünscht ist Wenn es zahlreiche Abhängigkeiten zwischen Klienten und einem Paket gibt. Dann entkoppelt die Fassade beide Komponenten. Wenn Pakete in Schichten organisiert werden sollen. Dann definiert die Fassade den Eintritt für jede Schicht und vereinfacht den Zugriff auf die jeweilige Schicht. Interaktionen Klienten kommunizieren mit der Fassaden-Klasse, welche die Botschaften innerhalb des Pakets weiter leitet. Konsequenzen Reduktion der Anzahl der Klassen, die dem Klienten bekannt sein müssen vereinfachte Nutzung des Systems Pakete können leichter ausgetauscht und unabhängig implementiert werden Bei Bedarf ist eine Umgehung der Fassade möglich.

17 Proxy-Muster Objektbasiertes Strukturmuster, das den Zugriff auf ein Objekt mit Hilfe eines vorgelagerten Stellvertreter-Objekts (surrogate) kontrolliert Beispiel Große Grafiken sollen in ein Dokument eingebunden werden. Sie sollen jedoch erst in den Hauptspeicher geladen werden, wenn die Grafik angezeigt wird Lösung Anstelle des eigentlichen Grafikobjekts wird ein Platzhalter, der Proxy in das Dokument eingebunden, der das eigentliche Objekt erst bei Bedarf lädt

18 Proxy-Muster Anwendbarkeit Remote-Proxy: lokaler Vertreter für ein Objekte auf einem anderen Computer Virtuelles Proxy erzeugt teure Objekte auf Verlangen (siehe Beispiel) Schutz-Proxy kontrolliert Zugriff auf das Objekt (z. B. Zugriffsrechte) Smart Reference führt zusätzliche Aufgaben aus, z. B. Interaktionen Zählen der Referenzen auf das Objekt, um es freizugeben, wenn es nicht mehr referenziert wird Laden eines Objekts in den Speicher beim ersten Aufruf Überprüfen, ob Objekt gesperrt ist Proxy leitet Befehle an das echte Objekt weiter Konsequenzen Remote-Proxy verbirgt die Tatsache, dass sich ein Objekt in einem anderen Adressraum befindet Virtuelles Proxy dient der Optimierung Schutz-Proxys und Smart References ermöglichen die Durchführung zusätzlicher Verwaltungsaufgaben beim Zugriff auf das Objekt

19 Beobachter-Muster Objektbasiertes Verhaltensmuster, das dafür sorgt, dass bei einer Änderung eines Objekts alle davon abhängigen Objekte benachrichtigt und aktualisiert werden Beispiel Die Daten eines Objekts sollen einmal als Tabelle und einmal als Grafik dargestellt werden. Tabellen- und Grafikobjekt kennen sich nicht, Änderungen in der Tabelle sollen aber die Grafik aktualisieren. Lösung Das Anwendungsobjekt (subject) kennt alle Anzeige-Objekte (Beobachter, observer) und informiert sie über alle Änderungen. Als Reaktion synchronisiert sich jeder Beobachter mit dem Zustand des Subjects.

20 Beobachter-Muster Anwendbarkeit Wenn eine Abstraktion mehrere voneinander abhängige Aspekte besitzt, und jeder dieser Aspekte durch unabhängige Objekte repräsentiert werden soll. Änderung eines Objekts impliziert Änderung anderer Objekte, und es ist nicht bekannt, wie viele Objekte geändert werden müssen Interaktionen Wird ConcreteSubjetct geändert, benachrichtigt es alle seine Beobachter mittels notify(). Jeder benachrichtigte ConcreteObserver bringt dann seinen Zustand mit dem des Subjekts in Einklang Konsequenzen Subjekte und Beobachter können unabhängig modifiziert werden Subjekte und Beobachter können einzeln wiederverwendet werden Neue Beobachter können ohne Änderung des Subjekts hinzugefügt werden

21 Model-View-Controller (MVC) Problem: Benutzungsschnittstellen müssen häufig geändert oder ausgetauscht werden. Die Änderungen bzw. der Austausch soll ohne großen Aufwand vollzogen werden können. Lösung: Unterteilung der Anwendung in drei Bereiche: Verarbeitung (Modell), Ausgabe (View) und Eingabe (Controller). Nicht unbedingt

22 MVC - Zusammenspiel 1. Benutzeraktion hat stattgefunden Controller 2. ändere Zustand View 3. Zustand hat sich geändert 4. get_zustand Model

23 MVC Bemerkungen Es gibt zahlreiche Varianten des Patterns Der Controller muss nicht unbedingt ein Observer sein Bei Java-Swing sind View und Controller zusammengelegt Zu den Swing-Komponenten gibt es nur noch die Modellschnittstelle Bei der Verwendung des Model-View-Controller-Patterns muss das Modell um entsprechende Registrier-Methoden für die Observer erweitert werden Änderungen am Modell müssen zu expliziten notify-aufrufen führen Das Pattern ist hart im Modell-Code verdrahtet. MVC ist recht aufwändig

24 Iterator-Muster Ermöglicht sequenziellen Zugriff auf Elemente eines zusammengesetzten Objektes unabhängig von dessen internen Struktur Beispiel Unterschiedlich implementierte Listen, z.b. als Vector, als Array, als Arraylist, als Baum, Eine Methode soll die Elemente dieser Listen traversieren, wobei ihr beliebige o.g. Listen übergeben werden können Lösung Es wird für jede der genannten Listen eine Iteratorklasse angelegt, die alle die gleiche Schnittstelle zur Verfügung stellen. Die Traversierungsmethode verwendet dann das jeweilige Iteratorobjekt, um auf die einzelnen Elemente zuzugreifen.

25 Iterator-Muster

26 Schablonenmethode-Muster Objektbasiertes Verhaltensmuster, das den Rahmen eines Algorithmus in einer Operation definiert und Teilschritte an Unterklassen delegiert Problem Für unterschiedliche Unterklassen einer Klasse benötigt die gleiche Operation teilweise gleiche, teilweise verschiedene Teile. Die gleichen Teile sollen nicht mehrfach implementiert werden. Lösung In der Oberklasse wird eine Operation definiert, die die gemeinsamen Teile des Algorithmus umfasst und für die verschiedenen Teile entsprechende abstrakte Operationen aufruft, die von den Unterklassen unterschiedlich implementiert werden.

27 Schablonenmethode-Muster Anwendbarkeit Wenn der Invariante Teil eines Algorithmus ein einziges Mal festgelegt werden soll und die variierenden Teile den Unterklassen überlassen werden Wenn gemeinsames Verhalten von Unterklassen in einer Oberklasse realisiert werden soll, um die Duplikation von Code zu vermeiden. Interaktionen Die ConcreteClass setzt voraus, dass die AbstractClass die invarianten Teile implementiert Konsequenzen Grundlegende Technik zur Wiederverwendbarkeit von Code Wichtiger Mechanismus in vielen abstrakten Klassen, insbes. in Klassenbibliotheken.

28 Strategie-Muster Definiert eine Familie von Algorithmen, kapselt jeden einzelnen und macht die Algorithmen austauschbar. Beispiel: In einem elektronischer Kalender sollen unter anderem die Ferientage angezeigt werden. Es soll möglich sein, ihn je nach Land so zu konfigurieren, dass jeweils die richtigen Ferientage angezeigt werden. Es soll auch leicht möglich sein, ihn für weitere Länder anzupassen. Lösung: Es wird eine abstrakte Klasse für die Ermittlung der Ferientage definiert. Für jedes Land wird eine konkrete Unterklasse angelegt. Je nach gewünschtem Land wird dem Kalender ein Objekt der zugehörigen konkreten Unterklasse zugeordnet.

29 Zustandsdiagramm (Statechart Diagram) Kann eingesetzt werden zur Modellierung der Benutzungsoberfläche Modellierung des Objekt-Lebenszyklus, ggf. gegenüber der Analyse erweitert Einfache Realisierung mit Hilfe eines Zustandsattributs der Klasse Komplexere Fälle: Nutzung des Zustands-Musters (state pattern)

30 Zustandsdiagramm - Beispiel Quelle: Kleuker, Grundkurs Software Engineering mit UML. 2. Aufl. Vieweg und Teubner 2011.

31 Zustandsautomat zur Oberflächenmodellierung

32 Oberfläche als Zustandsdiagramm Quelle: Kleuker, Grundkurs Software Engineering mit UML. 2. Aufl. Vieweg und Teubner 2011.

33 Hierarchisches Zustandsdiagramm Quelle: Kleuker, Grundkurs Software Engineering mit UML. 2. Aufl. Vieweg und Teubner 2011.

34 Beispiel: Uhr Anzeige im 12h/24h-Format Unabhängig davon: Einblenden von Datum oder Sekunden Zwei Knöpfe: Oben wechselt zwischen Stundenformat Unten wechselt zwischen Datum und Sekunden Quelle: Kleuker, Grundkurs Software Engineering mit UML. 2. Aufl. Vieweg und Teubner 2011.

35 Darstellung als Parallelkomposition Quelle: Kleuker, Grundkurs Software Engineering mit UML. 2. Aufl. Vieweg und Teubner 2011.

36 Zustandsmuster (1) OOA-Klasse bearbeiten() Zustand1 Ereignis bearbeiten ( ) Zustand3 Zustand2 bearbeiten ( ) Das aktuelle Verhalten hängt vom jeweiligen Zustand ab, d. h. die Operation bearbeiten ( ) muss andere Dinge tun, je nachdem, in welchem Zustand das Objekt ist Realisierung: a) Die Operation prüft den Zustand und reagiert entsprechend b) Nutzung des Zustandsmuster (s. nächste Folie)

37 Zustandsmuster (2) OOD-Klasse +bearbeiten() Aktueller Zustand 1 Zustand +bearbeiten() Diese Operation ruft die entsprechende Operation des aktuellen Zustandes auf Zustand1 +bearbeiten() Zustand2 +bearbeiten() Zustand3 +bearbeiten() Unterschiedliche Implementierung der Operation bearbeiten ()