Die Präsentation wird geladen. Bitte warten

Die Präsentation wird geladen. Bitte warten

Mitglied der Fachhochschule Ostschweiz FHO 1 www.fhsg.ch © FHS St.Gallen Software Engineering OOD – Object Oriented Design I Design-Prozess Design-Patterns.

Ähnliche Präsentationen


Präsentation zum Thema: "Mitglied der Fachhochschule Ostschweiz FHO 1 www.fhsg.ch © FHS St.Gallen Software Engineering OOD – Object Oriented Design I Design-Prozess Design-Patterns."—  Präsentation transkript:

1 Mitglied der Fachhochschule Ostschweiz FHO 1 © FHS St.Gallen Software Engineering OOD – Object Oriented Design I Design-Prozess Design-Patterns Prototyping

2 Mitglied der Fachhochschule Ostschweiz FHO 2 © FHS St.Gallen Software Engineering 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 Mitglied der Fachhochschule Ostschweiz FHO 3 © FHS St.Gallen Software Engineering Literatur Applikationen objektorientiert konzipieren –Kapitel 6 Lehrbuch der Objektmodellierung –LE 14 (Entwurfsmuster)

4 Mitglied der Fachhochschule Ostschweiz FHO 4 © FHS St.Gallen Software Engineering Design - Entwurf Analyse-Modell 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 Mitglied der Fachhochschule Ostschweiz FHO 5 © FHS St.Gallen Software Engineering Entwurfsproblemkreise Benutzerinteraktion/GUI Sitzungsverwaltung Workflowgestaltung Anwendungslogik Persistenz (Datenhaltung) Datenzugriff Datenhaltung

6 Mitglied der Fachhochschule Ostschweiz FHO 6 © FHS St.Gallen Software Engineering 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 Mitglied der Fachhochschule Ostschweiz FHO 7 © FHS St.Gallen Software Engineering Heuristiken «Best Practices» Regeln, Konzepte die sich in der Praxis bewährt haben: Geheimnisprinzip realisieren

8 Mitglied der Fachhochschule Ostschweiz FHO 8 © FHS St.Gallen Software Engineering Designprinzipien Kapselung 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 Mitglied der Fachhochschule Ostschweiz FHO 9 © FHS St.Gallen Software Engineering 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 Mitglied der Fachhochschule Ostschweiz FHO 10 © FHS St.Gallen Software Engineering 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 Mitglied der Fachhochschule Ostschweiz FHO 11 © FHS St.Gallen Software Engineering 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 Mitglied der Fachhochschule Ostschweiz FHO 12 © FHS St.Gallen Software Engineering Design by Mapping Synonym: Recursive Design Iteratives Vorgehen: Je Element pro Modellebene

13 Mitglied der Fachhochschule Ostschweiz FHO 13 © FHS St.Gallen Software Engineering 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 Mitglied der Fachhochschule Ostschweiz FHO 14 © FHS St.Gallen Software Engineering 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 Mitglied der Fachhochschule Ostschweiz FHO 15 © FHS St.Gallen Software Engineering 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 Mitglied der Fachhochschule Ostschweiz FHO 16 © FHS St.Gallen Software Engineering MVC – Model View Control Architekturmuster Model –enthält Business Logik und Daten View –Präsentation der Daten Control –Steuerung durch Benutzerinteraktion

17 Mitglied der Fachhochschule Ostschweiz FHO 17 © FHS St.Gallen Software Engineering MVC-Implementation im Java-Umfeld

18 Mitglied der Fachhochschule Ostschweiz FHO 18 © FHS St.Gallen Software Engineering Entwurfsmuster (Design Patterns) Die Dokumentation enthält: Kontext Problembeschreibung Lösung Auswirkungen Bekannte Musterkataloge: GoF – Gang of Four J2EE-Patterns

19 Mitglied der Fachhochschule Ostschweiz FHO 19 © FHS St.Gallen Software Engineering 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 Mitglied der Fachhochschule Ostschweiz FHO 20 © FHS St.Gallen Software Engineering 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 Mitglied der Fachhochschule Ostschweiz FHO 21 © FHS St.Gallen Software Engineering Singleton GoF Erzeugungsmuster –Stellt sicher, dass von einer Klasse nur genau ein Objekt erzeugt wird. z.B. ein Steuerobjekt Objektreferenz

22 Mitglied der Fachhochschule Ostschweiz FHO 22 © FHS St.Gallen Software Engineering 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 Mitglied der Fachhochschule Ostschweiz FHO 23 © FHS St.Gallen Software Engineering Proxy GoF Strukturmuster –Surrogat, Stellvertreter-Objektes (Proxy) Ermöglicht: Zugriffsschutz, Ortstransparenz Objektdiagramm:

24 Mitglied der Fachhochschule Ostschweiz FHO 24 © FHS St.Gallen Software Engineering Fassade GoF Strukturmuster –Einfache Schnittstelle zu einem Paket mit einer Menge von Komponenten (oder Klassen) Implementierung

25 Mitglied der Fachhochschule Ostschweiz FHO 25 © FHS St.Gallen Software Engineering Kompositum GoF Strukturmuster –Setzte Objekte zu Baumstrukturen zusammen. Bsp.: Grafik, aus Linien, Rechtecke, Text und Bilder Objektdiagramm: Einzelobjekte Containerobjekte

26 Mitglied der Fachhochschule Ostschweiz FHO 26 © FHS St.Gallen Software Engineering Beobachter GoF Verhaltensmuster –Bei Änderung eines Objektes werden alle davon abhängigen Objekte benachrichtigt. Datenpool (Subject) Tabellenanzeige (Observer-1) Diagrammanzeige (Observer-2)

27 Mitglied der Fachhochschule Ostschweiz FHO 27 © FHS St.Gallen Software Engineering Schablonenmethode GoF Verhaltensmuster –Definiert den Rahmen bzw. den invarianten Teil eines Algorithmus in einer Operation und delegiert Teilschritte an Unterklassen. Konkreter Programmcode Enthält keinen Programmcode Enthält invarianten Programmcode

28 Mitglied der Fachhochschule Ostschweiz FHO 28 © FHS St.Gallen Software Engineering Kontrollmuster Fork-Interaction: Ein Steuerobjekt kontrolliert alle Aufrufe Stair-Interaction: Die Kontrolle ist dezentral bei den Fachkomponenten GoF Verhaltensmuster: –Zuständigkeitskette (Chain of Responsability)

29 Mitglied der Fachhochschule Ostschweiz FHO 29 © FHS St.Gallen Software Engineering Literaturhinweis Patterns kompakt Eilebrecht, Starke ISBN: Spektrum Verlag

30 Mitglied der Fachhochschule Ostschweiz FHO 30 © FHS St.Gallen Software Engineering Prototyping Analyseprototyp weiterführen –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 Mitglied der Fachhochschule Ostschweiz FHO 31 © FHS St.Gallen Software Engineering Übungen UML-Übungen Übung 7 Fallstudie Auftrag 6 Auftrag 7


Herunterladen ppt "Mitglied der Fachhochschule Ostschweiz FHO 1 www.fhsg.ch © FHS St.Gallen Software Engineering OOD – Object Oriented Design I Design-Prozess Design-Patterns."

Ähnliche Präsentationen


Google-Anzeigen