2. Wer bin ich?
Vorabinfos
Ready?
Go!
Dokumente fürs Design
Wie man es nicht macht
Besser machen
Quak, Quik, Quek
Tools
Was zum Lesen Ergänzungen
Inhalt
3. Jeffrey Groneberg
Master-Student
Adobe Flex - Entwickler
BSc seit SS09
2. Mal Tutor im SEP
www.twitter.com/inkvine
www.inkvine.de
Wer bin ich?
4. Nicht all zuviel Theorie
Nicht der Master-Plan
Kein Ersatz für OOT / TPE und SEE
Vorabinfos
5. Eigene Erfahrung
Auflistung, die hilft
Überblick der Dokumente
Betrachtung der Voraussetzungen
Vorabinfos
6. Pflichtenheft
Architekturspezifikation
Development
Logical View
View
Process View Physical View
http://www.ifi.uzh.ch/swe/teaching/courses/seminar2004/abg
aben/Wimmer-Architektur-Sichten.pdf
Ready?
7. Nie alleine – gegenseitig erklären
Gutes Abstraktionsverständnis
Plotting – Studiengebühren
müssen sich rentieren
Mind-Mapping
OOA/OOD ist ein autodidaktischer Prozess
Guter Programmierer != guter Designer
Go!
8. Von Oben nach Unten!
Modul für Modul
Schnittstellen Mit Programmierern
und Strukturen absprechen
Plotten
sind wichtig
Gute Architektur
erleichtert gutes Design
Go!
9. Statische Sicht :
• Klassendiagramm verbalisieren
• Optional: Datenbank / XML / (Backend)
• Frameworks Dynamische Sicht:
• Sequenzdiagramm
• Aktivitätsdiagramm
Design-Validierung: •…
• Design <-> Pflichtenheft
• Das WAS wird durch das WIE beantwortet
Klassendiagramm
Dokumente stetig anpassen
Dokumente fürs Design
10. Planlos beginnen
• Probleme müssen abstrahiert werden
• Fehler in Architektur fehlerhaftes Design
Dynamische Sicht:
• Me vs . Framework • Sequenzdiagramm
• Aktivitätsdiagramm
Design unterschätzen: •…
Probleme bei:
Implementierung
Anforderungen
Veränderungen Klassendiagramm
Probleme beim Testen
Nicht Validieren
Wie man es nicht macht
11. Konkrete Beispiele durch fehlerhaftes Design:
• Enge Kopplung
• Static. Static. Static. zzZZzzzZZzz
• Doppelter Code
• Kein automatisiertes Testen
• White-Box-Testing wird umständlich
Positives Beispiel durch fehlerhaftes Design:
• Anwendung wird kryptographisch
Arbeitsplatz gesichert
Wie man es nicht macht
12. Das Rad nicht neu erfinden
Erfahrungen von anderen nutzen
Problemlösungen nutzen, die sich in der Praxis
bewährt haben
Best Practices
Ändernde Anforderungen führen zu anderen
Best Practices
Besser machen
13. Best Practices in OOD sind Design Pattern
Strategy Observer Decorator Factory
Pattern Pattern Pattern Pattern
Template Iterator and
Singleton Facade
Methode Composite
Pattern Pattern
Pattern Pattern
Command
State Pattern Proxy Pattern …
Pattern
Besser machen
14. „Nicht alles Gold, was glänzt“
Pattern genau kennen für Anwendung
Problem komplexer als Beispiel-UML des Pattern
Zwang , bei allem ein Pattern zu verwenden
Besser machen
15. Strategy Pattern
Änderung des Verhaltens zur Laufzeit
Veränderungen kapseln
Schnittstellen nutzen
Kapselung wiederverwenden
Komposition > Vererbung
Quak, Quik, Quek
19. Head First – Design Pattern
Gang of Four: Design Pattern
Refactoring – Improving the Design of Existing Code
Karteikarten
http://www.mcdonaldland.info/2007/11/28/40/
Ausführliche Erklärungen
http://sourcemaking.com/design_patterns
Was zum Lesen