, Rainer Schmidberger, ISTE. Entwurfsmuster. Rainer Schmidberger

Transkript

1 Entwurfsmuster Rainer Schmidberger

2 Was sind Entwurfsmuster? A design pattern names, abstracts and identifies the key aspect of a common design structure that makes it uful for creating a reusable object-oriented design [Gamma95] Eine Menge von Klasn und eine Regel sie zu gebrauchen Ein Entwurfs-Beispiel, das geschickt (im Sinne von clever oder trickreich) Mechanismen der Objektorientierung auf eine bekannte Problemstellung anwendet I. allg. nicht an eine Programmiersprache gebunden (wenngleich Entwurfsmuster mit Schablonenklasn nicht in jeder objektorientierten Sprache verwendet werden können) [Gamma95]: Gamma, E. u.a., "Design Patterns, Elemets of Reusable Object-Oriented Software", Addison-Wesley, 1995 Folie 2

3 Entwurfsmuster gibt es schon lange... Folie 3

4 Nutzen von Entwurfsmustern Wiederverwendung von Software-Entwürfen: für viele wiederkehrende Aufgabenstellungen gibt es bereits fertige Lösungen Standardisierung von Software-Entwürfen Erhöhung von Verständlichkeit von Software- Entwürfen Aber: nicht jede Zeile Implementierung muss in ein bekanntes Entwurfsmuster eingebettet werden Die verwendeten Entwurfsmuster müsn den am Projekt beteiligten Entwicklern bekannt in Falscher Einsatz von Entwurfsmustern verwirrt Folie 4

5 Darstellung von Entwurfsmustern UML-Modelle, zumeist Klasndiagramme, teilwei Interaktionsdiagramme (speziell bei den Behavior- Pattern) Exemplarische Implementierung der wichtigen Methoden Textuelle Beschreibung Entwurfsmuster bekommen oft einen "griffigen" Namen wie z.b. Facade, Composite,... Folie 5

6 Null-Object Problemstellung null-überprüfungen von Objektreferenzen führen zu u.u. unübersichtlichem Programmcode Auch "null-objekte" hätten u.u. ein bestimmtes Verhalten, das oft über el-zweige zu implementieren wäre TabDialog tabdialog = view.gettabdialog(i); if(tabdialog!= null) { tabdialog.open(); } el... Folie 6

7 Null-Object Die Methoden der Klas TabDialogNull sind i.allg. leer implementiert View TabDialog open() TabDialogA open() TabDialogB open() TabDialogNull open()... {}... public class View... {... TabDialog gettabdialog(int index) {... Hier wird er gefunden... } } return new TabDialogNull(); //... Und hier nicht Folie 7

8 Vor und Nachteile Dem null-objekt können Verhaltensmuster implementiert werden Weniger if-konstrukte Dient u.u. der Fehlervermeidung Erhöht die Zahl der Klasn Es muss eine entsprechende Vererbungshierarchie oder ein zu implementierendes Interface im Vorfeld geben Folie 8

9 Entwurfsmuster - Standard Gang of Four - GoF Erich Gamma, Richard Helm, Ralph E. Johnson, John Vlissides Industriestandard Aufgabe Entwurfs-Muster Erzeugungs-Muster Struktur-Muster Verhaltens-Muster Klasnbasiert Factory method Adapter Interpreter Template method Gültigkeitsbereich Objektbasiert Abstract Factory Adapter Command Builder Bridge Obrver Prototype Decorator Visitor Singleton Facade Iterator Flyweight Memento Composite Proxy Strategy Mediator State Chain of Responsibility Folie 9

10 Singleton Problemstellung Es soll sichergestellt werden, dass es zu einer Klas höchstens eine Instanz gibt. Die Instanz soll global verfügbar in, d.h. es muß eine Möglichkeit für alle Objekte geben, die Instanz anzusprechen. Beispiele: Datenbank, Drucker,... Lösung 1: Instanz in globaler Variablen ablegen. Problem: verhindert nicht die mehrfache Instantiierung. Lösung 2: deklariere alle Eigenschaften der Instanz als Klasneigenschaften. Problem: keine Redefinition möglich Folie 10

11 Singleton Idee Idee: Die Klas ist lbst dafür verantwortlich, dass es von ihr nur ein Exemplar gibt. Sie stellt auch die Instanz zur Verfügung. Struktur: die Instanz wird in der privaten Singleton Klasnvariablen theinstance gespeichert sie kann mit der Klasnmethode +rvice() getinstance() angefordert werden. (Aufruf Singleton.getInstance()) Die Instanzierung von theinstance findet beim ersten Zugriff statt -theinstance : Singleton +getinstance() : Singleton Folie 11

12 Singleton Programmcode class Singleton { static private Singleton theinstance = null; static public Singleton getinstance() { if (theinstance == null) { theinstance = new Singleton(); } return theinstance; } } /* Es darf keinen public-konstruktor geben (also auch keinen Default-Konstruktor). Damit Unterklasn ihn trotzdem benutzen können, wird er protected deklariert */ protected Singleton() {... }... // Instanzvariablen und -methoden Folie 12

13 Singleton Bemerkungen Überwachter Zugang zu einer einzigen Instanz Instanz braucht erst bei Bedarf erzeugt werden Keine globale Variable notwendig Die Singleton-Klas kann redefiniert werden Kann verallgemeinert werden für n Instanzen Flexibler als die Realisierung durch Klasnoperationen Folie 13

14 Composite Problemstellung es sollen hierarchische Teil-Ganzes-Beziehungen modelliert werden einzelne Objekte (Primitive) und zusammengetzte Objekte (Container) sollen für den Verwender die gleiche Schnittstelle haben Beispiele: Dateisystem, UML: Pakete,... Lösung: gemeinsame Oberklas für Primitive und Container, die beide Eigenschaften in sich vereinigt Folie 14

15 Composite Lösung Component add(c : Component) +children remove(c : Component) getchild(i : int) : Component operation() 0..* Leaf operation() Composite add(c : Component) remove(c : Component) getchild(i : int) : Component operation() Folie 15

16 Composite Bemerkungen (1) Composite reicht normale Methodenaufrufe (operation()) in der Regel an alle Kinder durch, kann aber auch noch zusätzliche Operationen durchführen die Aufnahme von Composite-Operationen in Component ist praktisch (einheitl. Schnittstelle), aber auch problematisch, da ihr Aufruf auf einen Leaf nicht sinnvoll ist. nötig ist zumindest eine Default-Implementierung dier Operationen (z.b. Exception auslön), ansonsten müsste jede Leaf-Klas das lbst tun ein Verschieben in Composite kann sinnvoll in (höhere Sicherheit). In beiden Fällen muss der Verwender darauf achten, nur bei Composite-Objekten add() etc. aufzurufen. Nur bedarf es beim zweiten Fall dazu eines expliziten Casts. Folie 16

17 Composite Bemerkungen (2) Component kann um getparent() erweitert werden, um den übergeordneten Composite referenzieren zu können. Problem: wer enthält den obersten Composite? statt mittels getchild() die Kinder einzeln verfügbar zu machen, kann nach außen auch ein externer und/oder interner Iterator über die Kinder zur Verfügung gestellt werden. Beispiel: java.awt.component Composite gehört zur Gruppe der Structural Patterns Folie 17

18 State Problemstellung Ein Objekt soll sich abhängig von inem Zustand verschieden verhalten. Hiervon können eine oder viele Methoden betroffen in. Idee: Der Zustand wird als Klas gekaplt. Spezielle Zustands-Klasn mit überladenen Methoden implementieren die jeweilige Zustandsabhängigkeit Folie 18

19 State: Lösung Aufruf: einstudent.dasrichtigetun(); Student Zustand dasrichtigetun() Vorlesung Pruefung Freizeit Party dasrichtigetun() dasrichtigetun() dasrichtigetun() dasrichtigetun() Folie 19

20 State Bemerkungen Als Erweiterung könnten die Methode dasrichtigetun() ein Objekt des Folgezustandes zurückliefern Es könne leicht weitere Zustände aufgenommen werden State gehört zur Gruppe der Behavioral Patterns Dinge, die in allen Zuständen gleich gemacht werden, können in der gemeinsamen Vaterklas implementiert werden Folie 20

21 Visitor: Problemstellung Es besteht eine Vererbungshierarchie. Für eine bestimmte Aufgabe, in der sich jede Klas unterschiedlich verhalten soll, erhält jeder Klas eine entsprechende Methode. Fragebogen drucken() 0..* FragebogenElement drucken() JaNeinFrage Mehrfachlektion FreitextFrage drucken() drucken() drucken() Was nun, wenn das drucken in unterschiedliche Medien stattfinden soll (z.b. HTML, pdf, usw...) oder verschiedene Druckstile verwendet werden sollen? Folie 21

22 Visitor: Lösung Je Druckstil wird ein Visitor implementiert public void visit(freitextfrage n) { // hier nun die Implementierung // für den HTML-Druck der // Freitextfrage } DruckeHTMLVisitor visit(n : Fragebogen) visit(n : JaNeinFrage) visit(n : Mehrfachlektion) visit(n : FreitextFrage) <<Interface>> Visitor visit(n : Fragebogen) visit(n : JaNeinFrage) visit(n : Mehrfachlektion) visit(n : FreitextFrage) DruckepdfVisitor visit(n : Fragebogen) visit(n : JaNeinFrage) visit(n : Mehrfachlektion) visit(n : FreitextFrage) Die drucken -Methode erhält als Parameter den Visitor Fragebogen drucken(v : Visitor) JaNeinFrage drucken(v : Visitor) 0..* Mehrfachlektion drucken(v : Visitor) FragebogenElement drucken(v : Visitor) FreitextFrage drucken(v : Visitor) public void drucken(visitor v) { v.visit(this); } Folie 22

23 Visitor: Bemerkung Vorteil Anstelle in vielen (gleichnamigen) Methoden über die Hierarchie verteilt, wird in einer zentralen Klas ein Aspekt behandelt Verhaltensmuster für eine ganze Reihe von Klasn lasn sich so übersichtlich austauschen Nachteil Kontrollfluss schwerer zu verfolgen Folie 23

24 Einteilung der Patterns Nach [Gamma95]: Creational Patterns Instanzierung von Objekten Beispiel: Singleton Structural Patterns Lösung bestimmter Strukturierungsprobleme Beispiel: Composite Behavioral Patterns Lösungen bestimmter Verhaltensaspekte Beispiel: State Folie 24

25 Kurzübersicht Unified Process und Agile Prozes Rainer Schmidberger

26 Wasrfall Prozess Business modelling Implementierung Requirements Analy und Design Modultest Inte- grations- Test Wasrfall vs. iterativem Prozess Auslieferung Iterativer Prozess Produktreife Configuration Management Folie 26

27 Der (Rational) Unified Process "The Unified Software Development Process", Ivar Jacobson u.a., Addison-Wesley, 1999 Der Einsatz Objektorientierter Sprachen führt i.allg. zu einem iterativen Prozessmodell Engineering Manage -ment Quelle: Rational Software Achtung: Quantitative Aussagen können aus diem Diagramm nicht abgeleitet werden! Folie 27

28 Unified Process (2) Jede Iteration führt zu einem ausführbaren Gesamtsystem Folie 28

29 Unified Process (3) Phan beschreiben den Reifegrad eines SW-Projektes über die Zeitach: Inception, Elaboration, Construction, Transition Workflows (Disciplines) sind die Aktivitäten eines SW-Projektes. Engineering Disciplines: Business Modeling, Requirements, Analysis&Design, Implementation, Test, Deployment Management Disciplines: Configuration&Change Management, Project Management, Environment Iterationen sind einzelne Abschnitte innerhalb einer Pha eines SW-Projektes. Entsprechend der Phan werden schwerpunktmäßig unterschiedliche Aktivitäten in den Disciplines durchgeführt! Jede Pha besteht aus mehreren Iterationen. Folie 29

30 Freigabe der Ressourcen für die Elaboration-Pha Major Milestones Produkt hat ausreichende Reife für erste Auslieferung an die Kunden (BZA) Freigabe der Ressourcen für die Construction- Pha Kundenakzeptanz oder Ende des Lebenszyklus Inception Elaboration Construction Transition Zeitach Quelle: Rational Software LCO (Lifecycle Objective) LCA (Lifecycle Architecture) IOC (Initial Operational Capability) PR (Product Relea) Folie 30

31 Typischer Projektverlauf und -Aufwand Pha Inception Elaboration Schedule 10% 30% Effort 5% 20% Meilenstein LCO LCA Construction Transition 50% 10% 65% 10% IOC PR Kruchten, P., The Rational Unified Process. An Introduction., Addison-Wesley, 2004 Folie 31

32 (Rational) Unified Process U Ca getrieben Die Analy wird für die funktionalen Anforderungen über U Ca Modellierung vorgenommen Die U Cas werden nach Risiko bewertet. U Cas mit hohem Risiko, also für den Kunden wichtigen Prozes, werden zuerst umgetzt. Architektur zentriert Der erste Architekturentwurf entsteht aus den wichtigsten U Cas und den zentralen nichtfunktionalen Anforderungen Je weiterer U Ca-Implementierung wird die Architektur inkrementell verfeinert Inkrementell Jeder Meilenstein soll ein ausführbares Gesamtsystem werden Iterativ Aus der Bewertung früher Inkremente kann der Analyst die noch ausstehenden U Cas optimieren Kundenanforderungen können noch umgetzt werden Folie 32

33 Agile Prozes Leichtgewichtige Prozessmodelle mit Fokussierung auf der Erstellung von Quellcode Weitere typische Merkmale: Focus on clo ating and clo communication Frequent delivery Information from real urs Extreme Programming (Kent Beck) Crystal Methodologies (Alistair Cockburn) Agile Software Development Manifesto ("The Agile Alience") Folie 33

34 Extreme programming (1) "extreme Programming explaid", Kent Beck, Addison- Wesley,1999 Small releas: kurze Iterationszyklen mit testbaren Resultaten Simple design: das einfachste Design, das ausreicht, wird implementiert (keep ist simple!) Testing: Ständige Unit-Tests der Entwickler. Je Klas wird eine eigene Test-Klas implementiert. Es wird sogar die Vorgehenswei empfohlen, zuerst Testfälle zu entwickeln um dann die eigentliche Anwendungs- Implementierung vorzunehmen. Refactoring: Ständiges Überarbeiten der Architektur mit dem Ziel der Vereinfachung bei unveränderter Funktionalität... Folie 34

35 Extreme programming (2)... Pair programming: der Programmcode wird immer von zwei Entwicklern gemeinsam entwickelt Collective ownership: Jeder kann jeden Code jederzeit ändern Continuous integration: häufiger (mehrmals täglich) Build des Gesamtsystems (zumindest immer wenn Teilsysteme fertig gestellt sind) 40-hour-week: niemals in zwei Wochen hintereinander Überstunden (d.h. mehr als 40 Wochenstunden) machen Coding standards: Gemeinsame Code-Richtlinien Folie 35

36 Folie 36

37 The Crystal Methodologies (1) "Agile Software Development", Alistair Cockburn, Addison-Wesley, 2002 Begriff "Crystal" ist einfach ein Name und hat letztlich keine Bedeutung ("Produktname") Tabelle mit Zuordnung Anzahl beteiligter Personen und Risiko zum empfohlenen Prozessmodell Risiko (Criticality, Hardness): Corresponds to more potential damage Je Prozessmodell existiert eine Prozess-Beschreibung mit Empfehlungen zu den beteiligten Personen und Rollen den zu erstellenden Dokumenten den einzutzenden Werkzeugen... Folie 37

38 The Crystal Methodologies (2) Criticality L6 L20 L40 L80 E6 E20 E40 E80 Criticality :Defects cau loss of... L=Life E=esntial money D=Discretionary money C=Comfort D6 C6 D20 C20 D40 C40 D80 C80 Clear Yellow Orange Red Number of people involved Ein Projekt der Criticality "D" und 20 beteiligten Personen wird nach dem Prozessmodell "D20" entwickelt Folie 38

39 "The Agile Alliance" "The Agile Alliance": 17, durchaus bekannte Personen aus dem SE-Umfeld "The Agile Software Development Manifesto", Utah Feb., 2002 Ziel: Es sollen besre Wege zur Software-Entwicklung aufgezeigt werden Vier (sicherlich fragwürdige) Kernpunkte: 1. Individuals and interactions 2. Working software 3. Custommer collaboration 4. Responding to change over over over over process and tools comprehensive documentation contract negotiation following a plan Folie 39

40 Refactoring Rainer Schmidberger

41 Was ist Refactoring? [Fowler 1999]: Refactoring: A change made to the internal structure of software to make it easier to understand and cheaper to modify without changing its obrvable behavior Gesucht: Anleitung zum Refactoring Indikatoren/Gegenindikatoren für eine bestimmtes Refactoring Aufwand und Nutzen Risiko [Fowler 1999] Fowler, M., Refactoring. Improving the Design of Existing Code., Addison- Wesley, 1999 Folie 41

42 Refactoring-Struktur nach Fowler Name Summary Motivation Mechanics Examples Kurze, griffige Bezeichnung. Bildet ein Vokabular an Refactorings. Kurze Zusammenfassung, Situationsbeschreibung für Anwendbarkeit des Refactorings. Beschreibt den Nutzen des Refactoring und auch Umstände, unter denen es nicht verwendet werden soll. Detaillierte, schrittwei Beschreibung wie das Refactoring durchgeführt werden soll. Beispielhafte Durchführung des Refactoring mit Veranschaulichung des Nutzens. Folie 42

43 Beispiel Move Method Name Summary Motivation Mechanics Examples Move Method A method is, or will be, using or ud by more features of another class than the class on wich it is defined. Create a new method with a similar body int the class it us most. Either turn the old method into a simple delegation or remove it altogether Method moving is the bread and butter of refactoring. I move methods when class have too much behavior... Examine all features ud by the source method that are defined on the source class. Consider whether they also should be moved. Check the sub- and superclass [...] Declare the method in the target class. Copy the code from the source method to the target. [...] Compile the target class. [...] Decide whether to remove the source method or retain it as a delegating method. [...] An account class illutrates this refactoring... Folie 43

44 Was fehlt bei Fowler (1) Vorbedingung Was muss im Code/Design vorliegen damit die Restrukturierung sinnvoll angewendet werden kann evtl. konkrete Metriken Gegenanzeigen Gründe, die gegen die Restrukturierung sprechen Risiko welcher Schaden kann entstehen Welche Nebenwirkungen sind zu erwarten und wie wären die ggf. zu begrenzen Angenommen, die Restrukturierung zeigt sich als undurchführbar. Wie aufwändig ist ein Undo Organisatorische Rahmenbedingungen welche Information (Dokumente, Ansprechpartner) sind erforderlich welche Kompetenz (Skill) ist erforderlich Folie 44

45 Was fehlt bei Fowler (2) Aufwand Zur Umtzung im Code Zur Qualitätssicherung Zur Pflege der Dokumente Zur Vermittlung an die weiteren Teammitglieder Nutzen Hat sich für das Modul bzw. die Prozedur ein Wartbarkeitsindex geändert? Welche Schaden entsteht durch eine Nichtdurchführung? Hat durch die einfacheren Strukturen das Fehlerrisiko abgenommen? Nachbedingung Das ursprüngliche (funktionale) Verhalten des Systems ist unverändert: Regressionstest. Folie 45

46 Beispiel: Move Method Name Vorbedingung Gegenanzeigen Risiko Organisatorische Rahmenbedingungen Move Method (m1 von K1 in K2) Eine Methode der Klas K1 wird überwiegend aus der Klas K2 heraus genutzt und hat lbst wenig Zugriff auf private Methoden oder Attribute Metriken: C&K nützen nichts, es gibt aber andere Publikationen hierzu Synchronisationen verbinden m1 mit K1 K1 ist abgeleitet und m1 ist auch in einer der Vaterklasn definiert K2 nicht lbst Sorgenkind Es könnte in, dass der Ausbau von K1 noch nicht abgeschlosn ist Reflektion Code-Ownership auf K1 und K2 liegt vor Die Verwendungen von K1 sind bekannt (Achtung bei Frameworks!) Eine Auslieferung steht nicht unmittelbar an (Da QS erfolgen muss) Aufwand Nutzen Nachbedingung Implementierung, Interne Dokumentation (z.b. Javadoc) ändern Externe Dokumentation, z.b. Klasn und Sequenzdiagramme QS Mitteilung an die Teammitglieder Programm leichter lesbar, weniger Delegation Zusammenhalt in K1 und K2 größer, Kopplung zwischen K1 und K2 kleiner Folie 46