OOD – Object Oriented Design I

Präsentation zum Thema: "OOD – Object Oriented Design I"—  Präsentation transkript:

1 OOD – Object Oriented Design I
Design-Prozess Design-Patterns Prototyping

2 Lernziele Sie können ... die wesentlichen Design-Prinzipien erläutern.
die wichtigsten Design-Patterns darlegen und anwenden. die wesentlichen Funktionen und Möglichkeiten des Prototyping darlegen.

3 Literatur Applikationen objektorientiert konzipieren
Kapitel 6 Lehrbuch der Objektmodellierung LE 14 (Entwurfsmuster)

4 Design - Entwurf Analyse-Modell Design-Modelle (Entwurfs-Modelle):
Implementationsunabhängig  Überführung in Design-Modelle (Entwurfs-Modelle): GUI-Interaktionsmodell  meist Design-Prototyp Komponentenmodell Persistenzmodell (meist Datenbankmodell) Design 1:1-Modell der Implementation (des Codes)

5 Entwurfsproblemkreise
Benutzerinteraktion/GUI Sitzungsverwaltung Workflowgestaltung Anwendungslogik Persistenz (Datenhaltung) Datenzugriff Datenhaltung

6 OOP  COP OOP – Object Oriented Programming
COP – Component Oriented Programming Komponentenmodelle (z.B. J2EE) Komponenten laufen in Container Mehrere Klassen werden zu einer Komponente zusammengefasst Container übernehmen zusätzliche Dienste: Session-Handling Security Persistence ...

7 Heuristiken «Best Practices»
Regeln, Konzepte die sich in der Praxis bewährt haben: Geheimnisprinzip realisieren

8 Designprinzipien Kapselung Lose Koppelung Hohe Kohäsion
Interne Logik wird «versteckt» Information Hiding, Geheimnisprinzip realisieren Zugriff erfolgt über definierte und kontrollierte Schnittstellen Lose Koppelung Möglichst wenig Abhängigkeiten zwischen Klassen bzw. Komponenten Hohe Kohäsion Möglichst hoher logischer innerer Zusammenhalt in einer Klasse bzw. Komponente

9 Separation of Concerns
Zuständigkeiten sauber separiert Je Modell, Subsystem, Komponente Möglichst keine Überschneidung im Fokus Beispiele der Trennung von: Schichtenarchitektur Front-End – Middle Tier – Back-End Subsysteme je Geschäftslogikeinheit Kunde, Artikel, Auftrag, … Geschäftslogik und technikabhängige Komponenten Geschäftskomponente Kundenauftrag Datenzugriffskomponente Kundenauftragsdaten Funktionslogische Trennung Schnittstelle, Steuerung und Implementation

10 Design by Abstraction Ziel: Flexibilität für zukünftige Änderungen
Konkreteres wird in Allgemeineres abstrahiert Sich nicht im Detail verlieren Allgemeine Muster herausarbeiten Bildung von Entwicklungsmuster in Form von Abstrakten Klassen Interface Klassen

11 Design by Enumeration Gegenteil von «Design by Abstraction»
Alle Anwendungsmöglichkeiten prüfen Alle Lösungsmöglichkeiten eruieren und evaluieren ist meist zu aufwändig Ein sich Verlieren im Detail!

12 Design by Mapping Synonym: Recursive Design Iteratives Vorgehen:
Je Element pro Modellebene

13 Design by Contract Ziel: zuverlässige Software
Bei Schnittstellen wird ein Kontrakt (Abmachung, Vertrag) festgelegt: Vorbedingungen (precondition) Nachbedingungen (postcondition) Modellierung mittels OCL (Object Constraint Language) Bei «Vertragsbruch»: «Raising» (werfen) einer bestimmten Exception (Ausnahmebehandlung)

14 Muster - Patterns Beschreiben allgemeine Lösungen zu häufig wiederkehrenden Problemstellungen Ebenen von Muster: Problemorientierte Seite: Analysemuster Lösungsorientierte Seite (abhängig von Granularität): Architekturmuster Grobkörniger Siehe auch Musterarchitekturen in Kapitel Softwarearchitektur! Entwurfsmuster Feinkörniger

15 Schichtenmuster (Layer Pattern)
Architekturmuster Schnittstellen nur zwischen angrenzenden Layers Höhere Layer haben die Kontrolle und ist von unterem Layer abhängig Unterer Layer ist von oberen Layer unabhängig

16 MVC – Model View Control
Architekturmuster Model enthält Business Logik und Daten View Präsentation der Daten Control Steuerung durch Benutzerinteraktion

17 MVC-Implementation im Java-Umfeld

18 Entwurfsmuster (Design Patterns)
Die Dokumentation enthält: Kontext Problembeschreibung Lösung Auswirkungen Bekannte Musterkataloge: GoF – Gang of Four J2EE-Patterns

19 GoF – Design Patterns Erzeugungsmuster (creational patterns)
Fabrikmethode (factory method) Singleton Strukturmuster (structural patterns) Adapter Proxy Fassade (facade) Kompositum (composite) Verhaltensmuster (behavioral patterns) Beobachter (observer) Schablonenmethode (template method)

20 Fabrikmethode GoF Erzeugungsmuster
Virtueller Konstruktor, bietet eine Schnittstelle zum Erzeugen eines Objektes, wobei die Unterklasse entscheidet von welcher Klasse es sein soll. Allg. Framework spezifische Implementation

21 Singleton GoF Erzeugungsmuster
Stellt sicher, dass von einer Klasse nur genau ein Objekt erzeugt wird. z.B. ein Steuerobjekt Objektreferenz

22 Adapter GoF Strukturmuster
Passt Schnittstelle an die Erwartungen des Klienten an. Wenn z.B. Client nicht geändert werden kann. Target.Request(gewünschte Schnittstelle)

23 Proxy GoF Strukturmuster Surrogat, Stellvertreter-Objektes (Proxy)
Ermöglicht: Zugriffsschutz, Ortstransparenz Objektdiagramm:

24 Fassade GoF Strukturmuster
Einfache Schnittstelle zu einem Paket mit einer Menge von Komponenten (oder Klassen) Implementierung

25 Kompositum GoF Strukturmuster
Setzte Objekte zu Baumstrukturen zusammen. Bsp.: Grafik, aus Linien, Rechtecke, Text und Bilder Objektdiagramm: Einzelobjekte Containerobjekte

26 Beobachter GoF Verhaltensmuster
Bei Änderung eines Objektes werden alle davon abhängigen Objekte benachrichtigt. Diagrammanzeige (Observer-2) Tabellenanzeige (Observer-1) Datenpool (Subject)

27 Schablonenmethode GoF Verhaltensmuster
Definiert den Rahmen bzw. den invarianten Teil eines Algorithmus in einer Operation und delegiert Teilschritte an Unterklassen. Enthält keinen Programmcode Enthält invarianten Programmcode Konkreter Programmcode

28 Kontrollmuster Fork-Interaction: Stair-Interaction:
Ein Steuerobjekt kontrolliert alle Aufrufe Stair-Interaction: Die Kontrolle ist dezentral bei den Fachkomponenten GoF Verhaltensmuster: Zuständigkeitskette (Chain of Responsability)

29 Literaturhinweis Patterns kompakt Eilebrecht, Starke
ISBN: Spektrum Verlag

30 Prototyping Analyseprototyp weiterführen Explorativer Prototyp
abhängig von eingesetztem Tool Explorativer Prototyp Verifizierung der Machbarkeit von Lösungsideen „Spike“  Prototyp zur Überprüfung von Architekturentscheiden (High-Fidelity) Design-Prototyp Anwenderinteraktion partizipatives Prototyping (d.h. Anwender wird miteinbezogen) Bildschirmlayout direkt in Implementation weiterverwenden

31 Übungen UML-Übungen Übung 7 Fallstudie Auftrag 6 Auftrag 7