View
2.330
Download
1
Category
Preview:
DESCRIPTION
Präsentation über OOA und OOD als Kurzeinführung für Studenten des Bachelor Studiengang Informatik an der Hochschule Mannheim
Citation preview
Design
SEP WS 09/10
Vorabinfos
Inhalt
Ready?
Wie man es nicht macht
Go!
Wer bin ich?
Besser machen
Dokumente fürs Design
ToolsErgänzungenWas zum Lesen
Quak, Quik, Quek
Wer bin ich?
Jeffrey Groneberg
2. Mal Tutor im SEP
Master-Student
BSc seit SS09
Adobe Flex - Entwickler
www.twitter.com/inkvine
www.inkvine.de
Vorabinfos
Nicht all zuviel Theorie
Nicht der Master-Plan
Kein Ersatz für OOT / TPE und SEE
Vorabinfos
Eigene Erfahrung
Auflistung, die hilft
Überblick der Dokumente
Betrachtung der Voraussetzungen
Ready?
Pflichtenheft
Logical ViewDevelopment
View
Process View Physical View
Architekturspezifikation
http://www.ifi.uzh.ch/swe/teaching/courses/seminar2004/abgaben/Wimmer-Architektur-Sichten.pdf
Go!
Nie alleine – gegenseitig erklären
Gutes Abstraktionsverständnis
Mind-Mapping
Plotting – Studiengebühren müssen sich rentieren
OOA/OOD ist ein autodidaktischer Prozess
Guter Programmierer != guter Designer
Go!
Plotten
Von Oben nach Unten!
Modul für Modul
Gute Architekturerleichtert gutes Design
Schnittstellenund Strukturen sind wichtig
Mit Programmierern absprechen
Dokumente fürs Design
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
Wie man es nicht macht
Dynamische Sicht:• Sequenzdiagramm• Aktivitätsdiagramm• …
Klassendiagramm
Planlos beginnen• Probleme müssen abstrahiert werden• Fehler in Architektur fehlerhaftes Design
• Me vs. Framework
Design unterschätzen: Probleme bei:
Implementierung
AnforderungenVeränderungenProbleme beim Testen
Nicht Validieren
Wie man es nicht macht
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
Besser machen
Das Rad nicht neu erfinden
Problemlösungen nutzen, die sich in der Praxis bewährt haben
Erfahrungen von anderen nutzen
Ändernde Anforderungen führen zu anderen Best Practices
Best Practices
Besser machen
StrategyPattern
ObserverPattern
DecoratorPattern
Factory Pattern
Singleton Pattern
FacadePattern
Template Methode Pattern
Iterator andComposite
Pattern
State Pattern Proxy PatternCommand
Pattern…
Best Practices in OOD sind Design Pattern
Besser machen
„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
Quak, Quik, Quek
Strategy Pattern
Änderung des Verhaltens zur Laufzeit
Veränderungen kapseln
Schnittstellen nutzen
Kapselung wiederverwenden
Komposition > Vererbung
Flugverhalten flugVerhalten
Quakverhalten quakVerhalten
schwimmen()
anzeigen()
tuQuaken()
tuFliegen()
setQuakVerhalten()
setFlugVerhalten
//ANDERE Enten-Methoden
Stockente MoorEnte
LockenteGummiEnte
anzeigen() anzeigen()
anzeigen()
<<Interface>>
FlugVerhalten
fliegen()
FliegtMitFlügeln FliegtGarnicht
fliegen() fliegen()
quaken()
<<Interface>>
QuakVerhalten
Quak, Quik, Quek
Ente
anzeigen()
Gekapseltes Quakverhalten
Gekapseltes FlugverhaltenClient
OmondoUML
Microsoft Visio
Dia
Jude
Werkzeuge
Reverse-Engineering um Design anzupassennicht um Design zu erstellen
Checkstyle
DocFlexFind-Bugs
JavaDocs
Ergänzungen
Spring-Framework
Was zum Lesen
Head First – Design PatternGang of Four: Design Pattern
Refactoring – Improving the Design of Existing Code
Karteikartenhttp://www.mcdonaldland.info/2007/11/28/40/
Ausführliche Erklärungenhttp://sourcemaking.com/design_patterns
Fragen?
Recommended