Präsentation über OOA und OOD als Kurzeinführung für Studenten des Bachelor Studiengang Informatik an der Hochschule Mannheim

1. Design
SEP WS 09/10

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

16. Client Gekapseltes Flugverhalten
<<Interface>>
Ente FlugVerhalten
Flugverhalten flugVerhalten fliegen()
Quakverhalten quakVerhalten
schwimmen()
anzeigen() FliegtMitFlügeln FliegtGarnicht
tuQuaken()
tuFliegen() fliegen() fliegen()
setQuakVerhalten()
setFlugVerhalten
//ANDERE Enten-Methoden Gekapseltes Quakverhalten
<<Interface>>
Stockente MoorEnte QuakVerhalten
anzeigen() anzeigen()
quaken()
GummiEnte Lockente
anzeigen() anzeigen()
Quak, Quik, Quek

17. OmondoUML
Jude
Microsoft Visio
Dia
Reverse-Engineering um Design anzupassen
nicht um Design zu erstellen
Werkzeuge

18. Checkstyle
JavaDocs
DocFlex
Find-Bugs
Spring-Framework
Ergänzungen

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

20. Fragen?