Die Präsentation wird geladen. Bitte warten

Die Präsentation wird geladen. Bitte warten

Design Pattern SS 10 Prof. Albert Zündorf

Veröffentlicht von:Lies Radden Geändert vor über 10 Jahren

Ähnliche Präsentationen

Präsentation zum Thema: "Design Pattern SS 10 Prof. Albert Zündorf"—  Präsentation transkript:

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

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

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

4 Gliederung Einführung Design Grundprinzipien Grundlegende Pattern
Weitere Pattern Zusammenfassung Design Pattern SS © 2010 Albert Zündorf, University of Kassel

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

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

7 Gliederung Einführung Design Grundprinzipien Grundlegende Pattern
Weitere Pattern Zusammenfassung Design Pattern SS © 2010 Albert Zündorf, University of Kassel

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

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

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

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

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

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

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

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

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

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

18 Gliederung Einführung Design Grundprinzipien Grundlegende Pattern
Weitere Pattern Zusammenfassung Design Pattern SS © 2010 Albert Zündorf, University of Kassel

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

47 State: red yellow green transferCar(car) / car.stop()
TraficLight state :Integer transferCar(car) Car transferCar(car) / car.setPos(…) yellow transferCar(car) / car.stop() green Struktur Verhalten Daten 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; } } } Design Pattern SS © 2010 Albert Zündorf, University of Kassel

48 State: Red TraficLight transferCar(car) Car current Yellow TLState name states Green Struktur Verhalten Daten 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"]; } } :Car :Red states["red"] states["yellow"] :Yellow :TrafficLight :Green states["green"] Design Pattern SS © 2010 Albert Zündorf, University of Kassel

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

50 Listener/Observer/Model-View-Controler
listeners > File size :Integer write(bytes[]) Drive usedSpace :Integer propertyChange (obj, attrName, oldVal, newVal) n Struktur Verhalten Daten 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 write ("aaaa") :Drive usedSpace = 112 :File size = 42 Design Pattern SS © 2010 Albert Zündorf, University of Kassel

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

89 Hausaufgabe: Baut ein Rahmenwerk, das einfach ein Fenster aufmacht
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. Das Rahmenwerk bekommt eine Liste der zu ladenden Plugins als Aufrufparameter. Achtung: das Rahmenwerk darf KEINE Compilezeitabhängigkeiten zu den Plugins haben Design Pattern SS © 2010 Albert Zündorf, University of Kassel

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

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

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

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

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

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

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

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

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

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

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

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

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

Herunterladen ppt "Design Pattern SS 10 Prof. Albert Zündorf"

Ähnliche Präsentationen

Anzahl der ausgefüllten und eingesandten Fragebögen: 211

Anzahl der ausgefüllten und eingesandten Fragebögen: 211
Vorlesung: 1 Betriebliche Informationssysteme 2003 Prof. Dr. G. Hellberg Studiengang Informatik FHDW Vorlesung: Betriebliche Informationssysteme Teil3.

Vorlesung: 1 Betriebliche Informationssysteme 2003 Prof. Dr. G. Hellberg Studiengang Informatik FHDW Vorlesung: Betriebliche Informationssysteme Teil3.
Die Projektgruppe heißt Sie herzlichst willkommen

Die Projektgruppe heißt Sie herzlichst willkommen
Einführung in die Informatik: Programmierung und Software-Entwicklung

Einführung in die Informatik: Programmierung und Software-Entwicklung
LS 2 / Informatik Datenstrukturen, Algorithmen und Programmierung 2 (DAP2)

LS 2 / Informatik Datenstrukturen, Algorithmen und Programmierung 2 (DAP2)
Telefonnummer.

Telefonnummer.
Modelle und Methoden der Linearen und Nichtlinearen Optimierung (Ausgewählte Methoden und Fallstudien) U N I V E R S I T Ä T H A M B U R G November 2011.

Modelle und Methoden der Linearen und Nichtlinearen Optimierung (Ausgewählte Methoden und Fallstudien) U N I V E R S I T Ä T H A M B U R G November 2011.
1 JIM-Studie 2010 Jugend, Information, (Multi-)Media Landesanstalt für Kommunikation Baden-Württemberg (LFK) Landeszentrale für Medien und Kommunikation.

1 JIM-Studie 2010 Jugend, Information, (Multi-)Media Landesanstalt für Kommunikation Baden-Württemberg (LFK) Landeszentrale für Medien und Kommunikation.
13 18 13 + 18 31 6 25 25 25 25 25 + = = = 1 1. 7 11 7 + 11 18 6 1 12 12 1212 12 2 15 + 32 = 47 = 47 = 48 = 48 2. 35 21 35 - 21 14 7 52 52 52 52 26 - =

= = = = 47 = 47 = 48 = =
Statistiken und Tabellen

Statistiken und Tabellen
EF: Standards + H2O red = H2O.

EF: Standards + H2O red = H2O.
Rechneraufbau & Rechnerstrukturen, Folie 2.1 © W. Oberschelp, G. Vossen W. Oberschelp G. Vossen Kapitel 2.

Rechneraufbau & Rechnerstrukturen, Folie 2.1 © W. Oberschelp, G. Vossen W. Oberschelp G. Vossen Kapitel 2.
Mh9S170Nr6 a. x1= –9; x2 = 1 b. x1= –4; x2 = 1 c. x1= 1; x2 = 2 d. leer e. x1= –15; x2 = 4,2 f. x1= –3,53; x2 = 1,28 g. leer h. x1= 0,2; x2 = 2 i. x1=

Mh9S170Nr6 a. x1= –9; x2 = 1 b. x1= –4; x2 = 1 c. x1= 1; x2 = 2 d. leer e. x1= –15; x2 = 4,2 f. x1= –3,53; x2 = 1,28 g. leer h. x1= 0,2; x2 = 2 i. x1=
Internet facts 2008-II Graphiken zu dem Berichtsband AGOF e.V. September 2008.

Internet facts 2008-II Graphiken zu dem Berichtsband AGOF e.V. September 2008.
Vorlesung: 1 Betriebliche Informationssysteme 2003 Prof. Dr. G. Hellberg Studiengang Informatik FHDW Vorlesung: Betriebliche Informationssysteme Teil2.

Vorlesung: 1 Betriebliche Informationssysteme 2003 Prof. Dr. G. Hellberg Studiengang Informatik FHDW Vorlesung: Betriebliche Informationssysteme Teil2.
PKJ 2005/1 Stefan Dissmann Zusammenfassung Bisher im Kurs erarbeitete Konzepte(1): Umgang mit einfachen Datentypen Umgang mit Feldern Umgang mit Referenzen.

PKJ 2005/1 Stefan Dissmann Zusammenfassung Bisher im Kurs erarbeitete Konzepte(1): Umgang mit einfachen Datentypen Umgang mit Feldern Umgang mit Referenzen.
Differentielles Paar UIN rds gm UIN

Differentielles Paar UIN rds gm UIN
Prof. Dr. Bernhard Wasmayr

Prof. Dr. Bernhard Wasmayr
Programmiermethodik SS 07 Prof. Albert Zündorf

Programmiermethodik SS 07 Prof. Albert Zündorf
Programmiermethodik SS 09 Prof. Albert Zündorf Fachgebiet für Software Engineering Wilhelmshöher Allee 73 34121 Kassel (Raum 1339 im Altbau)

Programmiermethodik SS 09 Prof. Albert Zündorf Fachgebiet für Software Engineering Wilhelmshöher Allee Kassel (Raum 1339 im Altbau)

Ähnliche Präsentationen

Google-Anzeigen