Als PDF, PPTX herunterladen
Hochgeladen vonJeffrey Groneberg
Design OOA OOD
Das Dokument befasst sich mit den Grundlagen und wichtigen Aspekten des Designs in der Softwareentwicklung, insbesondere im Hinblick auf Dokumentation, Architektur und bewährte Praktiken. Es werden Konzepte wie Klassendiagramme, Schnittstellen und Design Patterns behandelt sowie Beispiele für fehlerhafte Designs und deren Auswirkungen präsentiert. Zudem wird auf die Bedeutung der Validierung und Anpassung von Designs und Dokumenten eingegangen.
Design OOA OOD
- 1.
- 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 zuvielTheorie 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 nachUnten! 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 durchfehlerhaftes 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.