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

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.

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

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)

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

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 ...

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

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

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

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

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!

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

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)

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

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

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

MVC-Implementation im Java-Umfeld

Entwurfsmuster (Design Patterns) Die Dokumentation enthält: Kontext Problembeschreibung Lösung Auswirkungen Bekannte Musterkataloge: GoF – Gang of Four J2EE-Patterns http://java.sun.com/blueprints/corej2eepatterns/Patterns/index.html

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)

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

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

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)

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

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

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

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

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

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)

Literaturhinweis Patterns kompakt Eilebrecht, Starke ISBN: 3-8274-1591-8 Spektrum Verlag www.patterns-kompakt.de

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

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