Die Präsentation wird geladen. Bitte warten

Die Präsentation wird geladen. Bitte warten

Design Pattern SS 10 Prof. Albert Zündorf Fachgebiet für Software Engineering Wilhelmshöher Allee 73 34121 Kassel (Raum 1339)

Ähnliche Präsentationen


Präsentation zum Thema: "Design Pattern SS 10 Prof. Albert Zündorf Fachgebiet für Software Engineering Wilhelmshöher Allee 73 34121 Kassel (Raum 1339)"—  Präsentation transkript:

1 Design Pattern SS 10 Prof. Albert Zündorf Fachgebiet für Software Engineering Wilhelmshöher Allee Kassel (Raum 1339)

2 Design Pattern SS2010 © 2010 Albert Zündorf, University of Kassel 2 Organisatorisches m Umfang: 4 SWS teils Vorlesungen teils Übungen m Übungsbetreuung: Johannes Spohr, Sebastian Schulz m Ort und Zeit: Vorlesung: Dienstags 16: :00 Raum 2104 (Erste Vorlesung: ) Übung:?In obigem Zeitraum m Prüfung: l Pflichtübungsaufgaben (korrigiert, bepunktet) m Folienskript / Screen Videos: l

3 Design Pattern SS2010 © 2010 Albert Zündorf, University of Kassel 3 Literatur Grundlegend: m E. Gamma, R. Helm, R. Johnson, J. Vlissides: Design Patterns (Elements of Reusable Object-Oriented Software); Addison Wesley, Bonn, ISBN (1994) m Patterns Home Page: st-www.cs.uiuc.edu/users/patterns/patterns.html Unified Modeling Language: m Martin Hitz, Gerti Kappel: Work, dpunkt.verlag (ziemlich gut) Hintergrund: m Frederick P.\ Brooks: The Mythical Man Month, Addison Wesley 1975 (ist nur kurz aber ziemlich witzig, unbedingt mal lesen)

4 Design Pattern SS2010 © 2010 Albert Zündorf, University of Kassel 4 Gliederung 1. Einführung 2. Design Grundprinzipien 3. Grundlegende Pattern 4. Weitere Pattern 5. Zusammenfassung

5 Design Pattern SS2010 © 2010 Albert Zündorf, University of Kassel 5 1. Einführung Ziele der Veranstaltung: m Design Know How für große Programme > LOC m Grundprinzipien der Wartbarkeit und Erweiterbarkeit m sicherer Umgang mit Vererbung und Delegation m Grundkenntnis der wichtigsten Design Pattern m neue UML 2.0 features

6 Design Pattern SS2010 © 2010 Albert Zündorf, University of Kassel 6 Beispiel Composite Pattern m Realisierung hierarchischer Datenstrukturen m kommt in praktisch allen Software-Anwendungen vor m naiver Ansatz verursacht dramatische Wartungsprobleme m Gute Lösung ist Ausgangspunkt für viele weitere Pattern

7 Design Pattern SS2010 © 2010 Albert Zündorf, University of Kassel 7 Gliederung 1. Einführung 2. Design Grundprinzipien 3. Grundlegende Pattern 4. Weitere Pattern 5. Zusammenfassung

8 Design Pattern SS2010 © 2010 Albert Zündorf, University of Kassel 8 2. Design Grundprinzipien m Wartbarkeit m Erweiterbarkeit m ein Ort eine Design Entscheidung / eine Funktionalität lokale Änderungen m nur lokale Auswirkungen lokaler Änderung (Module/Klassen, Interfaces, Sichtbarkeiten) m "wenig" Vererbung

9 Design Pattern SS2010 © 2010 Albert Zündorf, University of Kassel 9 Vererbung m Substitutionsprinzip: Söhne müssen halten was die Väter versprechen m anstelle eines Vaterklassenobjektes kann man auch immer ein Unterklassenobjekt verwenden Enterprise Employee work (t : Task) : Product Manager work (t : Task) : Product manage ( proj : Project ) : Presentation hat Project Task Presentation Product created does

10 Design Pattern SS2010 © 2010 Albert Zündorf, University of Kassel 10 Beispielsituationen EnterpriseEmployee work (t : Task) : Product Manager work (t : Task) : Product manage ( proj : Project ) : Presentation hat Project Task Presentation Product created does … prod = e.work (t); … Struktur Verhalten Daten :Employee :Manager :Task :Product :Presentation :Project :Task

11 Design Pattern SS2010 © 2010 Albert Zündorf, University of Kassel 11 Beispielsituationen EnterpriseEmployee work (t : Task) : Product Manager work (t : Task) : Product manage ( proj : Project ) : Presentation hat Project Task Presentation Product created does … prod = e.work (t); … Struktur Verhalten Daten :Employee :Manager :Task :Product :Presentation :Project :Task

12 Design Pattern SS2010 © 2010 Albert Zündorf, University of Kassel 12 Beispielsituationen EnterpriseEmployee work (t : Task) : Product Manager work (t : Task) : Product manage ( proj : Project ) : Presentation hat Project Task Presentation Product created does … prod = e.work (t); … Struktur Verhalten Daten :Employee :Manager :Task :Product :Presentation :Project :Task

13 Design Pattern SS2010 © 2010 Albert Zündorf, University of Kassel 13 Beispielsituationen EnterpriseEmployee work (t : Task) : Product Manager work (t : Task) : Product manage ( proj : Project ) : Presentation hat Project Task Presentation Product created does … prod = e.work (t); … Struktur Verhalten Daten :Employee :Manager :Task :Product :Presentation :Project :Task

14 Design Pattern SS2010 © 2010 Albert Zündorf, University of Kassel 14 Co- und Contravariante Redefinitionen: wegen Substituierbarkeit: m input Parameter (Lesen) in Unterklassen nur verallgemeinern (Contravariante Redefinition) m output Parametern (Schreiben in Unterklassen nur spezialisieren (Covariante Redefinition)

15 Design Pattern SS2010 © 2010 Albert Zündorf, University of Kassel 15 Delegation: House run () alarm () FlashLight alarm() Sirene alarm() MailAlarm alarm() alarmDevice Struktur Verhalten Daten … this.alarm(); … :House :FlashLight :Sirene :MailAlarm AlarmDevice alarm ()

16 Design Pattern SS2010 © 2010 Albert Zündorf, University of Kassel 16 Hausaufgabe 1: m Implementiert das Klassendiagramm zur Delegation m Implementiert die alarm () Methoden der AlarmDevice - Unterklassen mit unterschiedlichen System.out Ausgaben m Schreibt ein Testprogramm dass: l ein House erzeugt, l das House nacheinander mit verschieden AlarmDevice verbindet l jeweils einen alarm() auslöst

17 Design Pattern SS2010 © 2010 Albert Zündorf, University of Kassel 17 Abgabe: m Bis m Eclipse Workspace mit Projekt mit JUnit Test m start mit einem Click m Eclipse Projekte inklusive Quellcode

18 Design Pattern SS2010 © 2010 Albert Zündorf, University of Kassel 18 Gliederung 1. Einführung 2. Design Grundprinzipien 3. Grundlegende Pattern 4. Weitere Pattern 5. Zusammenfassung

19 Design Pattern SS2010 © 2010 Albert Zündorf, University of Kassel Referenzarchitektur interaktive System Repository Data Model GUI (Commands) Generators / Interpreters QVT (Control) Import/ Export GUI (Unparsing)

20 Design Pattern SS2010 © 2010 Albert Zündorf, University of Kassel 20 Datenmodell mit Composite Pattern: naiv Struktur Verhalten Daten

21 Design Pattern SS2010 © 2010 Albert Zündorf, University of Kassel 21 Datenmodell mit Composite Pattern: besser Struktur Verhalten Daten

22 Design Pattern SS2010 © 2010 Albert Zündorf, University of Kassel 22 Datenmodell mit Composite Pattern: gut Struktur Verhalten Daten

23 Design Pattern SS2010 © 2010 Albert Zündorf, University of Kassel 23 Hausaufgabe 2: m Implementiert ein Datenmodell für ein Filesystem mit dem Composite Pattern m Lest eine Teilbaum eueres Computers ein m es sollte eine Jar Datei enthalten sein. m zählt die Anzahl der Files inklusive der Files in den Jar Dateien m summiert die Dateigrößen aller.java Dateien auf m macht euch für weitere Anforderungen bereit

24 Design Pattern SS2010 © 2010 Albert Zündorf, University of Kassel 24 Composite Pattern Problem: Struktur Verhalten Daten

25 Design Pattern SS2010 © 2010 Albert Zündorf, University of Kassel 25 Naiver Ansatz: Struktur Verhalten Daten

26 Design Pattern SS2010 © 2010 Albert Zündorf, University of Kassel 26 Visitor Pattern m rekursiver Durchlauf durch Composite Struktur m durchreichen eines Visitor Objekts m uniformerer Umgang mit Rekursionsparametern m Trennung von Durchlauf und Aktion

27 Design Pattern SS2010 © 2010 Albert Zündorf, University of Kassel 27 Visitor Pattern Struktur Verhalten Daten

28 Design Pattern SS2010 © 2010 Albert Zündorf, University of Kassel 28 Visitor Pattern Struktur Verhalten Daten

29 Design Pattern SS2010 © 2010 Albert Zündorf, University of Kassel 29 Visitor Pattern Struktur Verhalten Daten

30 Design Pattern SS2010 © 2010 Albert Zündorf, University of Kassel 30 Visitor Pattern Zusammenfassung m Ziemlich viele accept und visit Methoden m Double Dispatch möglich m Seperation of concern m Zustandsobjekt in der Rekursion

31 Design Pattern SS2010 © 2010 Albert Zündorf, University of Kassel 31 Hausaufgabe 3: m stellt das Composite Pattern für Files vom letzten Mal auf ein Visitor pattern um. m Baut einen Visitor zur Summierung der Dateigrößen aller.java Dateien auf m Baut einen Visitor der alle Dateien zählt, auf deren Namen ein mitgelieferter regulärer Ausdruck matcht

32 Design Pattern SS2010 © 2010 Albert Zündorf, University of Kassel 32 Strategy Pattern m ersetze if-then-else-if Ketten

33 Design Pattern SS2010 © 2010 Albert Zündorf, University of Kassel 33 If-then-else-if Kette: Struktur Verhalten Daten public void ring () { if (mode == SIRENE) { …} else if (mode == FLASH) { …} else if (mode == MAIL) { …} … House run () ring () mode : int

34 Design Pattern SS2010 © 2010 Albert Zündorf, University of Kassel 34 MailAlarm ring () Strategy Pattern: House run () ring () Alarm ring () Sirene ring () alarm 0..1 Struktur Verhalten Daten class House { public void ring () { alarm.ring (); } … :House :FlashLight :Sirene :MailAlarm FlashLight ring ()

35 Design Pattern SS2010 © 2010 Albert Zündorf, University of Kassel 35 Strategy Pattern Struktur Verhalten Daten

36 Design Pattern SS2010 © 2010 Albert Zündorf, University of Kassel 36 Hook Pattern (nicht im Gof-Buch) m zusätzliches Verhalten nachträglich einbauen

37 Design Pattern SS2010 © 2010 Albert Zündorf, University of Kassel 37 Hook Pattern: House run () ring () Alarm ring () FlashLight ring () Sirene ring () MailAlarm ring () externAlarms Struktur Verhalten Daten public void ring () { storeProtocol (); for (alarm in externAlarms) { alarm.ring (); } } :House :FlashLight :Sirene :MailAlarm n

38 Design Pattern SS2010 © 2010 Albert Zündorf, University of Kassel 38 Chain of Responsibility m im wesentlichen Hook m aber Abbruch wenn erfolgreich bearbeitet

39 Design Pattern SS2010 © 2010 Albert Zündorf, University of Kassel 39 < next Chain of Responsibility, original House run () ring () Alarm ring () FlashLight ring () Sirene ring () MailAlarm ring () alarm Struktur Verhalten Daten class Alarm { public boolean ring () { if (next != null) { return next.ring(); } return false; } } :House :FlashLight :Sirene :MailAlarm

40 Design Pattern SS2010 © 2010 Albert Zündorf, University of Kassel 40 Chain of Responsibility, original : House run () ring () Alarm ring () FlashLight ring () Sirene ring () MailAlarm ring () alarm Struktur Verhalten Daten class FlashLight { public boolean ring () { // try it if (bulb.isReady ()) { bulb.activate (); return true; } else { super.ring (); }}} :House :FlashLight :Sirene :MailAlarm < next

41 Design Pattern SS2010 © 2010 Albert Zündorf, University of Kassel 41 Chain of Responsibility, besser debugbar: House run () ring () Alarm ring () FlashLight ring () Sirene ring () MailAlarm ring () alarms n Struktur Verhalten Daten class House { public boolean ring () { boolean success = false; for (a in alarms) { success = a.ring(); if (success) return true; } return false; }} :House :FlashLight :Sirene :MailAlarm {ordered} alarms[1] alarms [2] alarms [3]

42 Design Pattern SS2010 © 2010 Albert Zündorf, University of Kassel 42 Chain of Responsibility, besser debugbar: Struktur Verhalten Daten class FlashLight { public boolean ring () { // try it if (bulb.isReady ()) { bulb.activate (); return true; } else { return false; }}} :House :FlashLight :Sirene :MailAlarm House run () ring () Alarm ring () FlashLight ring () Sirene ring () MailAlarm ring () alarms n {ordered}

43 Design Pattern SS2010 © 2010 Albert Zündorf, University of Kassel 43 Beobachtungen m typische Kombinationen von Assoc und Vererbung m Unterklassen haben KEINE neue Methoden m Unterklassen redefinieren geerbte Methoden

44 Design Pattern SS2010 © 2010 Albert Zündorf, University of Kassel 44 Beobachtungen

45 Design Pattern SS2010 © 2010 Albert Zündorf, University of Kassel 45 Hausaufgabe 4: m Baut euer Hausbeispiel aus der ersten Hausaufgabe in eine Chain of Responsibility um. m Sinnvolle Tests

46 Design Pattern SS2010 © 2010 Albert Zündorf, University of Kassel 46 State m im wesentlichen Strategy m aber systematische Strategy-Änderung nach Benutzung m meist Implementierung von Statecharts

47 Design Pattern SS2010 © 2010 Albert Zündorf, University of Kassel 47 State: Struktur Verhalten Daten TraficLight state :Integer transferCar(car) Car class TrafficLigth { void transferCar (Car car) { if (state == GREEN) { car.setPos (…); state = YELLOW; } else if (state == YELLOW) { car.stop(); state == RED; } else if (state == RED) car.stop() state = GREEN; }}} green yellow red transferCar(car) / car.setPos(…) transferCar(car) / car.stop()

48 Design Pattern SS2010 © 2010 Albert Zündorf, University of Kassel 48 State: Struktur Verhalten Daten TLState Green Yellow Red current TraficLight transferCar(car) Car :TrafficLight :Car :Red :Yellow :Green name states states["red"] states["yellow"] states["green"] class Red { void transferCar (Car car) { car.stop() owner.current = owner.states["green"]; }} class Green { void transferCar (Car car) { car.setPos(…) owner.current = owner.states["yellow"]; }}

49 Design Pattern SS2010 © 2010 Albert Zündorf, University of Kassel 49 Listener/Observer/Model-View-Controler/Mediator m im wesentlichen Hook m aber Einsatz zur Überwachung von Änderungen

50 Design Pattern SS2010 © 2010 Albert Zündorf, University of Kassel 50 Listener/Observer/Model-View-Controler Struktur Verhalten Daten Drive usedSpace :Integer propertyChange (obj, attrName, oldVal, newVal) File size :Integer write(bytes[]) :Drive usedSpace = 112 write ("aaaa") class File { void write (bytes[]) { … this.setSize (size+bytes.length()); } void setSize (newVal) { if (this.size != newVal) { int oldVal = size; size = newVal; firePropertyChange ("size", oldVal, newVal); }} … :File size = 23 :File size = 42 listeners > n

51 Design Pattern SS2010 © 2010 Albert Zündorf, University of Kassel 51 Listener/Observer/Model-View-Controler Struktur Verhalten Daten Drive usedSpace :Integer propertyChange (obj, attrName, oldVal, newVal) File size :Integer write(bytes[]) :Drive usedSpace = 112 write ("aaaa") class File { … void firePropertyChange (attrName, oldVal, newVal){ for (l in listeners) { l.propertyChange (this,attrName,oldVal,newVal); }} … :File size = 23 :File size = 42 listeners > n

52 Design Pattern SS2010 © 2010 Albert Zündorf, University of Kassel 52 Listener/Observer/Model-View-Controler Struktur Verhalten Daten Drive usedSpace :Integer propertyChange (obj, attrName, oldVal, newVal) File size :Integer write(bytes[]) :Drive usedSpace = 112 write ("aaaa") class Drive { … void propertyChange (obj,attrName,oldVal,newVal){ usedSpace += newVal – oldVal; }} … :File size = 23 :File size = 42 listeners > n

53 Design Pattern SS2010 © 2010 Albert Zündorf, University of Kassel 53 Listener/Observer/Model-View-Controler Struktur Verhalten Daten Drive usedSpace :Integer File size :Integer write(bytes[]) :Drive usedSpace = 112 write ("aaaa") class SpaceUpdater { … void propertyChange (obj,attrName,oldVal,newVal){ for (t : targets) { t.usedSpace += newVal – oldVal; }}} … :File size = 23 :File size = 42 listeners > n SpaceUpdater propertyChange (obj,attrName,oldVal,newVal) targets > n :SpaceUpdater

54 Design Pattern SS2010 © 2010 Albert Zündorf, University of Kassel 54 Model-View-Controler/Mediator Struktur Verhalten Daten Drive usedSpace :Integer File size :Integer write(bytes[]) :Drive usedSpace = 112 write ("aaaa") class SpaceUpdater { … void propertyChange (obj,attrName,oldVal,newVal){ for (t : targets) { t.usedSpace += newVal – oldVal; }}} … :File size = 23 :File size = 42 listeners > n SpaceUpdater propertyChange (obj,attrName,oldVal,newVal) targets > n :SpaceUpdater :Computer usedSpace = 1012 Computer

55 Design Pattern SS2010 © 2010 Albert Zündorf, University of Kassel 55 Hausaufgabe 5?: m Baut ein GUI für ein Auto m es soll nur die Geschwindigkeit modelliert werden m die Geschwindigkeit soll auf zwei Wegen visualisiert werden: l Zahldarstellung (JSpinner) l Schieberegler m die Geschwindigkeit soll in beiden Views editiert werden können und von einem Testprogramm verstellt werden m macht eine Tabelle für mehrere Autos

56 Design Pattern SS2010 © 2010 Albert Zündorf, University of Kassel 56 Listener Concept for Car Example Struktur Verhalten Daten

57 Design Pattern SS2010 © 2010 Albert Zündorf, University of Kassel 57 Struktur Verhalten Daten

58 Design Pattern SS2010 © 2010 Albert Zündorf, University of Kassel 58 Template Method m Motivation ähnlich wie Hook m aber feste Vorgabe von abstrakten Template-Methoden m alle Template-Methoden müssen überschrieben werden

59 Design Pattern SS2010 © 2010 Albert Zündorf, University of Kassel 59 Template Method: House run () ring () Alarm + ring () ~ start () ~ stop () alarm Struktur Verhalten Daten class Alarm { void ring () { start (); … stop (); … } } :House :FlashLight :Sirene :MailAlarm MailAlarm ring () Sirene ring () FlashLight ~ start () ~ stop ()

60 Design Pattern SS2010 © 2010 Albert Zündorf, University of Kassel 60 Template Method: House run () ring () Alarm + ring () ~ start () ~ stop () alarm Struktur Verhalten Daten class FlashLigth { void start () { powerOn (); } void stop () { powerOff () }} :House :FlashLight :Sirene :MailAlarm MailAlarm ring () Sirene ring () FlashLight ~ start () ~ stop ()

61 Design Pattern SS2010 © 2010 Albert Zündorf, University of Kassel 61

62 Design Pattern SS2010 © 2010 Albert Zündorf, University of Kassel 62 Decorator m ähnlich wie Composite mit nur einem Kind m ähnlich wie Chain-of-Responsibility m erweitere eine Strategy um zusätzliche Aktionen

63 Design Pattern SS2010 © 2010 Albert Zündorf, University of Kassel 63 Decorator: Struktur Verhalten Daten class MailAlarm { ring () { sendMail(); orig.ring(); }} :House :Sirene :MailAlarm MailAlarm ring () House run () ring () Alarm ring () Sirene ring () alarm 0..1 FlashLight ring () 0..1 orig

64 Design Pattern SS2010 © 2010 Albert Zündorf, University of Kassel 64 Proxy m ähnlich wie Decorator m aber kein Zusatzeffekt m sondern remote, lazy oder cache Effekte

65 Design Pattern SS2010 © 2010 Albert Zündorf, University of Kassel 65 Proxy: Struktur Verhalten Daten ? :House :Sirene :MailAlarm

66 Design Pattern SS2010 © 2010 Albert Zündorf, University of Kassel 66 Adapter m ähnlich wie Decorator m aber Schnittstellenanpassung

67 Design Pattern SS2010 © 2010 Albert Zündorf, University of Kassel 67 Adapter: Struktur Verhalten Daten ? :House :Sirene :MailAlarm

68 Design Pattern SS2010 © 2010 Albert Zündorf, University of Kassel 68 Hausaufgabe: m Baut das Hausbeispiel mit einem (Objekt) Adapter für einen Mail-Alarm

69 Design Pattern SS2010 © 2010 Albert Zündorf, University of Kassel 69

70 Design Pattern SS2010 © 2010 Albert Zündorf, University of Kassel 70 Flyweight Struktur Verhalten Daten

71 Design Pattern SS2010 © 2010 Albert Zündorf, University of Kassel 71 Flyweight Struktur Verhalten Daten

72 Design Pattern SS2010 © 2010 Albert Zündorf, University of Kassel 72 Struktur Verhalten Daten

73 Design Pattern SS2010 © 2010 Albert Zündorf, University of Kassel 73 Command Struktur Verhalten Daten

74 Design Pattern SS2010 © 2010 Albert Zündorf, University of Kassel 74 Command Struktur Verhalten Daten

75 Design Pattern SS2010 © 2010 Albert Zündorf, University of Kassel 75 Hausaufgabe: Command m Erstellt eine einfache GUI mit einem Fußball Icon auf einer Malfläche m Darunter 4 Knöpfe um den Ball jeweils 1 cm in jede Himmelsrichtung zu bewegen m Darunter ein Undo und ein Redo Knopf m Mit Command Pattern implementieren m Test: 10 mal bewegen, 5 Undo wieder an Pos 5, 2 Redo wieder an Pos 7, 7 Undo wieder an Pos 1 m Sonderpunkte für Dragging

76 Design Pattern SS2010 © 2010 Albert Zündorf, University of Kassel 76

77 Design Pattern SS2010 © 2010 Albert Zündorf, University of Kassel 77

78 Design Pattern SS2010 © 2010 Albert Zündorf, University of Kassel 78 Factory Method: Struktur Verhalten Daten

79 Design Pattern SS2010 © 2010 Albert Zündorf, University of Kassel 79 Prototype: Struktur Verhalten Daten

80 Design Pattern SS2010 © 2010 Albert Zündorf, University of Kassel 80 Komplexer Prototyp

81 Design Pattern SS2010 © 2010 Albert Zündorf, University of Kassel 81 Abstract Factory: Struktur Verhalten Daten

82 Design Pattern SS2010 © 2010 Albert Zündorf, University of Kassel 82 Hausaufgabe: m Abstrakte Fabrik für Autos und Garagen m Konfiguration für rote Spielzeugautos und Minigaragen m Konfiguration für blaue Nutzfahrzeuge und Flugzeughallen m vielleicht mal Spielzeugauto mit LKW-Motor und Hundehütte

83 Design Pattern SS2010 © 2010 Albert Zündorf, University of Kassel 83

84 Design Pattern SS2010 © 2010 Albert Zündorf, University of Kassel 84 Facade: Struktur Verhalten Daten

85 Design Pattern SS2010 © 2010 Albert Zündorf, University of Kassel 85 Import Umkehrung: Struktur Verhalten Daten

86 Design Pattern SS2010 © 2010 Albert Zündorf, University of Kassel 86 Import Umkehrung: Struktur Verhalten Daten

87 Design Pattern SS2010 © 2010 Albert Zündorf, University of Kassel 87 Plugins: Struktur Verhalten Daten

88 Design Pattern SS2010 © 2010 Albert Zündorf, University of Kassel 88 Daten Plugin: Struktur Verhalten Daten

89 Design Pattern SS2010 © 2010 Albert Zündorf, University of Kassel 89 Hausaufgabe: m Baut ein Rahmenwerk, das einfach ein Fenster aufmacht m Baut ein Plugin, das in das Rahmenwerkfenster einen Button und ein Label einhängt, bei jedem Button Click soll das Label eins hoch gezählt werden. m Das Rahmenwerk bekommt eine Liste der zu ladenden Plugins als Aufrufparameter. m Achtung: das Rahmenwerk darf KEINE Compilezeitabhängigkeiten zu den Plugins haben

90 Design Pattern SS2010 © 2010 Albert Zündorf, University of Kassel 90

91 Design Pattern SS2010 © 2010 Albert Zündorf, University of Kassel 91

92 Design Pattern SS2010 © 2010 Albert Zündorf, University of Kassel 92 Reuse Architekturen: m Bibliotheken m Frameworks m Product Line Architecture

93 Design Pattern SS2010 © 2010 Albert Zündorf, University of Kassel 93

94 Design Pattern SS2010 © 2010 Albert Zündorf, University of Kassel 94

95 Design Pattern SS2010 © 2010 Albert Zündorf, University of Kassel 95 Components & Connectors Architekturen

96 Design Pattern SS2010 © 2010 Albert Zündorf, University of Kassel 96

97 Design Pattern SS2010 © 2010 Albert Zündorf, University of Kassel 97 Components & Connectors Architekturen m Wiederverwendung von "Komponenten" m "Konnektoren" zur Verknüpfung und Anpassung von Komponenten

98 Design Pattern SS2010 © 2010 Albert Zündorf, University of Kassel 98 Components & Connectors Architekturen

99 Design Pattern SS2010 © 2010 Albert Zündorf, University of Kassel 99 Components & Connectors Architekturen

100 Design Pattern SS2010 © 2010 Albert Zündorf, University of Kassel 100 Components & Connectors Architekturen

101 Design Pattern SS2010 © 2010 Albert Zündorf, University of Kassel 101

102 Design Pattern SS2010 © 2010 Albert Zündorf, University of Kassel 102


Herunterladen ppt "Design Pattern SS 10 Prof. Albert Zündorf Fachgebiet für Software Engineering Wilhelmshöher Allee 73 34121 Kassel (Raum 1339)"

Ähnliche Präsentationen


Google-Anzeigen