3 Die Entwurfsphase OOD (Grundlagen) Software-Technik

3 Die Entwurfsphase OOD (Grundlagen) Software-Technik
LE 30 3 Die Entwurfsphase OOD (Grundlagen) Prof. Dr. Helmut Balzert Lehrstuhl für Software-Technik Ruhr-Universität Bochum

I SWT - Die Entwurfsphase - OOD (Grundlagen)
LE 30

Lernziele LE 30 Die Charakteristika von OOD, seine Aufgaben und seine Einordnung zwischen OOA und OOP darstellen können Aufgaben und Architekturen von Klassen-bibliotheken und frameworks erklären können Die Ansätze für eine komponentenbasierte Softwareentwicklung und Halbfabrikate skizzieren können Beschreibungs- und Klassifikationsschemata für Entwurfsmuster erklären können Das Entwurfsmuster »abstract factory« auf Problemstellungen anwenden können.

3.10 Objektorientierter Entwurf
I SWT - Die Entwurfsphase - OOD (Grundlagen) Inhalt LE 30 3.10 Objektorientierter Entwurf Einführung und Überblick Klassenbibliotheken und ihre Architektur Halbfabrikate und ihre Schnittstellen Entwurfsmuster.

3.10 Objektorientierter Entwurf
I SWT - Die Entwurfsphase - OOD (Grundlagen) 3.10 Objektorientierter Entwurf LE 30 Zur Historie Grady Booch * in Texas Chief Scientist Rational Software Corporation Pionier auf dem Gebiet des modularen und objektorientierten Softwareentwurfs 1983: Buch Software Engineering with Ada 1987: Buch Software Components with Ada 1991/94: Buch Object Oriented Design with Applications Pionier wiederverwendbarer Bibliotheken 1987: Komponentenbibliothek in Ada 1991: Klassenbibliothek in C++.

3.10.1 Einführung und Überblick
I SWT - Die Entwurfsphase - OOD (Grundlagen) Einführung und Überblick LE 30 Ziel der Definitionsphase Erstellung einer Produkt-Definition, die das Fachkonzept der gewünschten Anwendung in Struktur und Semantik aus Anwendersicht vollständig, konsistent und eindeutig beschreibt Für ein OOA-Modell bedeutet dies: Es beschreibt keine technischen Lösungen Beispiele: Datenbankschema, Verteilung Es enthält keine Optimierungen Beispiele: Zusammenfassen/Trennen von Klassen Es enthält keine Objektverwaltung Beispiel: Objektlisten usw. Alle Assoziationen und Aggregationen sind bidirektional.

I SWT - Die Entwurfsphase - OOD (Grundlagen) Einführung und Überblick LE 30 Ziel der Entwurfsphase Ausgehend von einer Produkt-Definition einen Produkt-Entwurf erstellen, der die Produkt-Anforderungen realisiert und die Anwendung architektonisch in die Anwendungsumgebung einbettet OOD läßt sich in 2 Schritte gliedern: Architekturentwurf (Systementwurf) Implementierungsentwurf.

I SWT - Die Entwurfsphase - OOD (Grundlagen) Einführung und Überblick LE 30 OOD: 2 Schritte Architekturentwurf (Systementwurf) Anbindung an die Benutzungsoberfläche Anbindung an die Datenhaltung Verteilung auf ein Netzwerk Anbindung an die Systemschnittstelle Verarbeitungssteuerung ... Implementierungsentwurf Architekturentwurf verfeinern An die Zielprogrammiersprache anpassen. technische Anwendungen

I SWT - Die Entwurfsphase - OOD (Grundlagen) Einführung und Überblick LE 30 Kein »Strukturbruch« von OOA nach OOD Sowohl in OOA als auch in OOD werden die objektorientierten Grundkonzepte verwendet Objekt, Klasse, Attribut, Operation, Botschaft, Vererbung, Polymorphismus Ausgangspunkt für den Architekturentwurf ist das OOA-Modell des Fachkonzepts Das OOA-Modell wird erweitert, modifiziert, optimiert und an die umgebende Architektur angepaßt Es ergibt sich ein OOD-Modell.

I SWT - Die Entwurfsphase - OOD (Grundlagen) Einführung und Überblick LE 30 Entscheidungen bei OOD

3.10.2 Klassenbibliotheken und ihre Architektur
I SWT - Die Entwurfsphase - OOD (Grundlagen) Klassenbibliotheken und ihre Architektur LE 30 Klassenbibliotheken Organisierte Softwaresammlungen, aus der der Entwickler nach Bedarf Einheiten verwendet Bilden die Voraussetzung, um »Wiederverwendung im Kleinen« zu realisieren Eigenentwicklung kommerziell.

I SWT - Die Entwurfsphase - OOD (Grundlagen) Klassenbibliotheken und ihre Architektur LE 30 Anwendungsgebiete von Klassenbibliotheken

I SWT - Die Entwurfsphase - OOD (Grundlagen) Klassenbibliotheken und ihre Architektur LE 30 Vorteile von Klassenbibliotheken Eigener Aufwand wird gespart Bessere Qualität, da bereits oft eingesetzt Höhere Flexibilität, da Varianten zur Auswahl Von Spezialisten entwickelt Auswahl zwischen mehreren Herstellern Oft plattformübergreifend Nachteile Möglicherweise hoher Einarbeitungsaufwand Evtl. Namenskonflikte beim Einsatz mehrerer Bibliotheken Verschiedene Klassenbibliotheken müssen oft durch eine Zwischenschicht gekoppelt werden.

I SWT - Die Entwurfsphase - OOD (Grundlagen) Klassenbibliotheken und ihre Architektur LE 30 Entwurfsziele hohe Laufzeiteffizienz hohe Speichereffizienz volle Nutzung des Sprachumfangs Einfachheit der Benutzung Plattformunabhängigkeit Kriterien bei Zukauf Quellcode verfügbar Familie mit kompatiblen Bibliotheken verschiedene Implementierungen für kritische Funktionalitäten.

I SWT - Die Entwurfsphase - OOD (Grundlagen) Klassenbibliotheken und ihre Architektur LE 30 Grundlegende Bibliothekstopologien

I SWT - Die Entwurfsphase - OOD (Grundlagen) Klassenbibliotheken und ihre Architektur LE 30 Beispiele für Bibliothekstopologien

I SWT - Die Entwurfsphase - OOD (Grundlagen) Klassenbibliotheken und ihre Architektur LE 30 Baumtopologie und ihre Bewertung Nutzung der Vererbung Alle Klassen können allg. Ober-Dienste nutzen Leichte Erweiterbarkeit Sehr komplexe Baumhierarchien Hoher Lernaufwand Anwender muß alle Oberklassen berücksichtigen Overhead durch nicht benötigte Klassen Wenn Kopplung durch Aggregation/Assoziationen, dann Einbettung benachbarter Unterbäume Probleme durch Mehrfachvererbung Vererbung oft überstrapaziert Anwendungsbereich: GUI-Bibliotheken.

I SWT - Die Entwurfsphase - OOD (Grundlagen) Klassenbibliotheken und ihre Architektur LE 30 Waldtopologie und ihre Bewertung Leichter Überblick durch flachere Hierarchie Leichte Nutzung Abgegrenzter Aufgabenbereich Höhere Performance als ein Baum Manche Lösungen weniger elegant als ein Baum Beziehungen zwischen Teilbäumen sehr mächtig Anwendungsbereiche Fundamentalklassen Klassen zur Steuerung von GUIs.

I SWT - Die Entwurfsphase - OOD (Grundlagen) Klassenbibliotheken und ihre Architektur LE 30 Bausteintopologie und ihre Bewertung Große Unabhängigkeit der einzelnen Klassen Hohe Flexibilität Gute Effizienz Erweiterungen haben keine globalen Auswirkungen »Explosion« des Objektcodes durch die Generierung von Klassen mit Hilfe des template-Mechanismus Oft keine konsistente Schnittstelle der Klassen Anwendungsbereich Fundamentalklassen.

I SWT - Die Entwurfsphase - OOD (Grundlagen) Klassenbibliotheken und ihre Architektur LE 30 »framework« Ein durch den Softwareentwickler anpaßbares oder erweiterbares System kooperierender Klassen I. allg. werden abstrakte oder leere Operationen in Unterklassen definiert bzw. implementiert Besitzt oft eine Baumtopologie Zwingt den Bibliotheksbenutzer dazu, die Ar-chitektur der eigenen Anwendung in die Bibliothek einzupassen Speicher vs. Laufzeit Gute Klassenbibliotheken verfügen über speichereffiziente und laufzeiteffiziente Implementierungen seperation of policy and implementation.

I SWT - Die Entwurfsphase - OOD (Grundlagen) Klassenbibliotheken und ihre Architektur LE 30 Struktur von Klassenbibliotheken Abstrakte Klassen Vorzugsweise verwendet, wenn zu einem Konzept verschiedene Implementierungen mit identischer Schnittstelle zur Verfügung stehen sollen Die Schnittstelle ist in eine eigene abstrakte Klasse ausgegliedert Sie dient als Oberklasse für die Implementierungen Dadurch ist es möglich, für verschiedene Anforderungen geeignete Implementierungen zur Verfügung zu stellen und gleichzeitig eine identische Verwendung sicherzustellen.

I SWT - Die Entwurfsphase - OOD (Grundlagen) Klassenbibliotheken und ihre Architektur LE 30 Struktur von Klassenbibliotheken Knotenklassen Befinden sich in größeren Klassenhierarchien Sie verwenden die Operationen ihrer Oberklassen und erweitern diese Erlauben eine weitere Spezialisierung durch Ableitung neuer Klassen Knotenklassen zusammen mit abstrakten Klassen sind vor allem in Smalltalk-ähnlichen Klassenbibliotheken anzutreffen.

I SWT - Die Entwurfsphase - OOD (Grundlagen) Klassenbibliotheken und ihre Architektur LE 30 Struktur von Klassenbibliotheken Schnittstellenklassen Dienen zur Anpassung von Klassen an einen konkreten Verwendungszweck Geerbte Operationen der Oberklassen werden teilweise redefiniert durch... Umbennung von Operationen Veränderung der Parameterreihenfolge Vereinigung von Operationen.

I SWT - Die Entwurfsphase - OOD (Grundlagen) Klassenbibliotheken und ihre Architektur LE 30 Struktur von Klassenbibliotheken

3.10.3 Halbfabrikate und ihre Schnittstellen
I SWT - Die Entwurfsphase - OOD (Grundlagen) Halbfabrikate und ihre Schnittstellen LE 30 Komponentenbasierte Softwareentwicklung Erlaubt die einfache, schnelle und preiswerte Herstellung individueller, integrierter Anwendungen durch Zusammenbau von vorgefertigten Halbfabrikaten bzw. Komponenten Dazu benötigt man Halbfabrikate, die... i. allg. kleiner als Anwendungen sind, d.h. einen stärkeren Komponenten- bzw. Bausteincharakter besitzen deutlich größer als Klassen sind, d.h. mehr Funktionalität kapseln Komplexität verbergen.

I SWT - Die Entwurfsphase - OOD (Grundlagen) Halbfabrikate und ihre Schnittstellen LE 30 Halbfabrikat (componentware) Ist ein abgeschlossener, binärer Software-Baustein, der eine anwendungsorientierte, semantisch zusammengehörende Funktionalität besitzt, die nach außen über Schnittstellen zur Verfügung gestellt wird Beim Entwurf des Halbfabrikats wurde auf hohe Wiederverwendbarkeit großer Wert gelegt Beispiele Rechtschreibprüfung, Silbentrennung, Seitenvorschau.

I SWT - Die Entwurfsphase - OOD (Grundlagen) Halbfabrikate und ihre Schnittstellen LE 30 Notwendige Voraussetzungen: Sprachunabhängigkeit Es spielt keine Rolle, in welcher Programmier-sprache die Komponente realisiert ist Beispiele: OCX, VBX, ActiveX Plattformunabhängigkeit Es spielt keine Rolle, für welches Betriebssystem die Komponente entwickelt wurde Beispiele: JavaBeans, in Ansätzen CORBA Verteilbarkeit Die Komponente kann sich irgendwo in einem heterogenen Netz befinden Beispiele: JavaBeans, ActiveX, CORBA.

I SWT - Die Entwurfsphase - OOD (Grundlagen) Halbfabrikate und ihre Schnittstellen LE 30 Es gibt verschiedene Ansätze, um diese Voraussetzungen zu erfüllen Probleme Wie kann der Aufwand für die Verbindung zweier Komponenten minimiert werden? Wünschenswert ist die Verknüpfung von Komponenten mit Hilfe visueller und generativer Programmierumgebungen Wie soll die interne Struktur eines Halbfabrikates aussehen? 2 Ansätze: CORBA-Modell (siehe LE 27) VBX/OCX-Modell.

I SWT - Die Entwurfsphase - OOD (Grundlagen) Halbfabrikate und ihre Schnittstellen LE 30 Das CORBA-Modell

I SWT - Die Entwurfsphase - OOD (Grundlagen) Halbfabrikate und ihre Schnittstellen LE 30 Das CORBA-Modell Objekte können über den Object Request Broker miteinander kommunizieren ORB nimmt Anfragen an ein Objekt entgegen ORB findet das Adressatobjekt ORB ruft die gewünschte Objektmethode auf ORB leitet das Ergebnis an den Anrufer zurück Objekte können sich registrieren lassen Registrierte Fähigkeiten stehen anderen Objekten als Application Objects zur Verfügung Zu jedem ORB gehören Common Facilities Über Object Services kann jedes Objekt Informationen über andere Objekte oder die Systemumgebung erhalten.

I SWT - Die Entwurfsphase - OOD (Grundlagen) Halbfabrikate und ihre Schnittstellen LE 30 Das CORBA-Modell: Beispiel Klassen werden in IDL spezifiziert Daraus werden Client-Proxies und Server-Rümpfe generiert interface Person { attribute string Name; attribute string Vorname; void Drucken(); };.

I SWT - Die Entwurfsphase - OOD (Grundlagen) Halbfabrikate und ihre Schnittstellen LE 30 Das VBX-Modell Komponentenbasierte Entwicklung entstand durch die Visual-Basic-Dialogelemente (VBXe) Von Microsoft für die Windows-Programmierung VBX kann sowohl Windows-Kontrollelemente als auch OLE-Objekte repräsentieren Beispiele für VBXe sind: Datenbankanwendungen Tabellenkalkulation Grafik (dynamische Grafik, Geschäftsgrafik) Diagramme (z.B. für Statistik) Dialogelemente von Benutzungsoberflächen Zahlreiche Büro-Anwendungen verfügen über Komponenten-Schnittstellen.

I SWT - Die Entwurfsphase - OOD (Grundlagen) Halbfabrikate und ihre Schnittstellen LE 30 Das VBX-Modell VBX-Einbindung in ein Programm Über visuell arbeitende Werkzeuge Zugriff auf die Komponenten Über sprachunabhängige Schnittstellen auf Binärebene Dadurch ist Komponentenentwicklung in einer frei gewählten Programmiersprache möglich Außerdem ist die Wiederverwendung beliebiger Fremdkomponenten möglich Außer für Visual Basic gibt es Programmierschnittstellen für C++ und C.

I SWT - Die Entwurfsphase - OOD (Grundlagen) Halbfabrikate und ihre Schnittstellen LE 30 Das VBX-Modell Komponenten können über ihre Schnittstellen mit Hilfe einer Skript-Sprache, z.B. Visual Basic, integriert werden Mit der Visual Basic-Umgebung ist der Programmierer in der Lage, vorhandene VBX-Komponenten visuell in seine eigene Software zu integrieren Neben Microsoft bieten inzwischen auch Drittan-bieter solche VBX-Elemente für verschiedene Anwendungsbereiche an.

I SWT - Die Entwurfsphase - OOD (Grundlagen) Halbfabrikate und ihre Schnittstellen LE 30 Das VBX-Modell VBX ist eine prozedurale Funktionsbibliothek, die den Grundumfang von Visual Basic erweitert Die Komposition erfolgt durch Programmierung von Funktionsaufrufen Einfach zu nutzende Funktionsbibliothek Charakteristika: Keine Vererbung und Polymorphie Nachbildung mit Referenzen Anpaßbarkeit beschränkt sich auf das Verändern vorgegebener Eigenschaftswerte der Parameter Nur objektbasiert, da nur Kapselung von Daten und Funktionen Proprietäres Modell.

I SWT - Die Entwurfsphase - OOD (Grundlagen) Halbfabrikate und ihre Schnittstellen LE 30 Das OCX-Modell VBX-Modell wird durch das OCX-Modell (OLE-control extensions) abgelöst Auf der Grundlage von OLE2 sind OCX auch auf Netze verteilbar, z.B. in Windows NT 4.0. Basiert auf dem common object model COM/DCOM Es definiert Programmierkonventionen, nach denen Softwaremodule Schnittstellen exportieren bzw. Schnittstellen anderer Module aufrufen können COM ist objektbasiert Skriptsprache ist Visual Basic Erstellung von OCX-Komponenten mit C++ Rechnerübergreifende Kommunikation über zukünftige Windows-Mechanismen.

I SWT - Die Entwurfsphase - OOD (Grundlagen) Halbfabrikate und ihre Schnittstellen LE 30 Das OCX-Modell Beispiel: Verknüpfung von OCX-Komponenten

I SWT - Die Entwurfsphase - OOD (Grundlagen) Halbfabrikate und ihre Schnittstellen LE 30 Das OCX-Modell Beispiel: Visual Basic-Code Rechtschreibprogramm von Excel integrieren Excel-Objekt deklarieren und erzeugen Zelle mit Inhalt füllen, anzeigen Rechtschreibung prüfen Private Sub Rechtschreibung_Click() Dim x As Object Set x = CreateObject("Excel.Sheet") x.Cells(1,1).Value = Text1.Text x.Visible = True x.CheckSpelling Text1.Text = x.Cells(1,1).Value x.Application.Quit Set x = Nothing End Sub Wert zurückschreiben, Excel beenden und Objekt vernichten.

I SWT - Die Entwurfsphase - OOD (Grundlagen) Halbfabrikate und ihre Schnittstellen LE 30 Das COM-Modell (Component Object Model) Eine Klasse definiert sich durch ihre Operationen (interface) Namen der Interfaces beginnen mit I Vererbung wird auf Objektebene realisiert Ausnahme: Gemeinsame Basisklasse IUnknown Objektlebensdauer wird über manuell zu verwaltende Referenzzähler gesteuert (kein delete) Neue Objekte werden mit Hilfe einer Factory Class erzeugt Klassen identifizieren sich durch eine Class-ID In einer Class Table werden die Class-IDs aller Klassen und Zeiger auf ein oder mehrere Factory Classes gespeichert. Ein Interface wird einfach als eine Liste von Zeigern auf Funktionen realisiert, zu denen Prototypen angegeben werden müssen. Daß das später benutzte Interface tatsächlich den Prototypen entsprechende Operationen implementiert, ist Konvention. Es kann nicht durch den Compiler oder irgendeinen Mechanismus überprüft werden. Vererbung auf Objektebene bedeutet, daß sie zur Laufzeit geändert werden kann. Außerdem kann ein Objekt niemals zu verschiedenen Interfaces gleichzeitig gehören, man muß durch einen Aufruf einer Operation von IUnknown zwischen den einzelnen Interfaces umschalten (geschieht zyklisch) Das Konzept der manuell zu verwaltenden Referenzzähler wird als Vorteil verkauft, da es gestattet, Optimierungen durchzuführen, wenn bekannt ist, daß das zu referenzierende Objekt bereits einen Referenzzähler > 0 hat. Wer die Gefahr liebt... Natürlich kann man das Objektmodell kapseln, indem man z.B. für jedes Interface eine abstrakte C++-Klasse definiert und die Implementierung später in einer anderen Klasse, die von allen Interfaces, die sie darstellen können soll, erbt, durchführt.

I SWT - Die Entwurfsphase - OOD (Grundlagen) Halbfabrikate und ihre Schnittstellen LE 30 Das COM-Modell Das Interface Iunknown wird von allen Objekten implementiert QueryInterface() Eingabeparameter: Class-ID des gesuchten Interfaces Rückgabewert: Zeiger auf die Funktionstabelle AddRef() Referenzzähler auf das Objekt bzgl. des aktuellen Interfaces erhöhen Release() Referenzzähler auf das Objekt dekrementieren Ein Objekt, das mehrere Interfaces implementiert, hat diese Operationen mehrmals! Ein Interface wird einfach als eine Liste von Zeigern auf Funktionen realisiert, zu denen Prototypen angegeben werden müssen. Daß das später benutzte Interface tatsächlich den Prototypen entsprechende Operationen implementiert, ist Konvention. Es kann nicht durch den Compiler oder irgendeinen Mechanismus überprüft werden. Vererbung auf Objektebene bedeutet, daß sie zur Laufzeit geändert werden kann. Außerdem kann ein Objekt niemals zu verschiedenen Interfaces gleichzeitig gehören, man muß durch einen Aufruf einer Operation von IUnknown zwischen den einzelnen Interfaces umschalten (geschieht zyklisch) Das Konzept der manuell zu verwaltenden Referenzzähler wird als Vorteil verkauft, da es gestattet, Optimierungen durchzuführen, wenn bekannt ist, daß das zu referenzierende Objekt bereits einen Referenzzähler > 0 hat. Wer die Gefahr liebt... Natürlich kann man das Objektmodell kapseln, indem man z.B. für jedes Interface eine abstrakte C++-Klasse definiert und die Implementierung später in einer anderen Klasse, die von allen Interfaces, die sie darstellen können soll, erbt, durchführt.

I SWT - Die Entwurfsphase - OOD (Grundlagen) Halbfabrikate und ihre Schnittstellen LE 30 Erfolgreicher Einsatz von Halbfabrikaten: Komponenten müssen an bestimmten, wohldurchdachten Stellen offen sein Komponenten sollen daher mit speziellen austauschbaren Ablaufklassen kooperieren Analog sollte die Art der Fehlerentdeckung und -behandlung geändert werden können Komponenten sollten flexibel konfigurierbar und wiederverwendbar sein Schnittstellen wichtiger Komponenten sollten standardisiert sein Das (OOA-)Modell der Komponente sollte offengelegt sein.

I SWT - Die Entwurfsphase - OOD (Grundlagen) Halbfabrikate und ihre Schnittstellen LE 30 Vorgehensweise 1 Auswahl eines geeigneten Architekturrahmens 2 Auswahl geeigneter Halbfabrikate 3 Anpassung der Halbfabrikate 4 Verbinden der Halbfabrikate 5 Überprüfung, ob das entstehende Produkt den gewünschten Anforderungen entspricht.

Entwurfsmuster (design pattern)
I SWT - Die Entwurfsphase - OOD (Grundlagen) Entwurfsmuster LE 30 Entwurfsmuster (design pattern) Gibt eine bewährte generische Lösung für ein immer wiederkehrendes Entwurfsproblem an, das in bestimmen Situationen auftritt. Analog: Analysemuster in OOA.

3.10.4 Entwurfsmuster Entwurfsmuster...
I SWT - Die Entwurfsphase - OOD (Grundlagen) Entwurfsmuster LE 30 Entwurfsmuster... unterstützen die Wiederverwendung von Lösungen dokumentieren existierende und erprobte Entwurfserfahrungen benennen und erklären wichtige Entwürfe helfen bei der Auswahl von Entwurfsalternativen verhelfen dem Entwerfer schneller zum richtigen Entwurf bieten ein gemeinsames Entwurfs-Vokabular und -Verständnis für eine Gruppe von Entwicklern.

3.10.4 Entwurfsmuster Beschreibungsschema 1 Name des Musters
I SWT - Die Entwurfsphase - OOD (Grundlagen) Entwurfsmuster LE 30 Beschreibungsschema 1 Name des Musters 2 Problembeschreibung Das Problem und der Kontext werden erklärt 3 Lösungsbeschreibung Gibt die Elemente an, die den Entwurf, die Beziehungen, Verantwortlichkeiten und die Zusammenarbeit ausmachen Die Lösung gibt keinen konkreten Entwurf oder eine Implementierung an 4 Konsequenzen Ergebnisse und »trade-offs« Auswirkungen eines Muster auf Flexibilität, Erweiterbarkeit und Portabilität.

Klassifikation von Entwurfsmustern
I SWT - Die Entwurfsphase - OOD (Grundlagen) Entwurfsmuster LE 30 Klassifikation von Entwurfsmustern Zweck Erzeugendes Muster (creational pattern): Erzeugen von Objekten Strukturelles Muster (structural pattern): Komposition von Klassen und Objekten Verhaltensmuster (behavioral pattern): Kommunikation und Verantwortlichkeiten zwischen Objekten Geltungsbereich Klassen (statisch) Vererbung Objekte (dynamisch) Assoziationen, Aggregationen.

Klassifikation von Entwurfsmustern
I SWT - Die Entwurfsphase - OOD (Grundlagen) Entwurfsmuster LE 30 Klassifikation von Entwurfsmustern

Beziehungen zwischen Entwurfsmustern
I SWT - Die Entwurfsphase - OOD (Grundlagen) Beziehungen zwischen Entwurfsmustern LE 30

Beispiel: »abstract factory«
I SWT - Die Entwurfsphase - OOD (Grundlagen) Entwurfsmuster LE 30 Beispiel: »abstract factory« Zweck Stellt Schnittstelle zur Verfügung, um Familien von Objekten, die miteinander in Beziehung stehen oder voneinander abhängig sind, ohne Angabe ihrer konkreten Klassen zu erzeugen Motivation Die Oberfläche einer Anwendung soll dem jeweiligen look-and-feel entsprechen Über das konkrete GUI sollen keine Annahmen in der Anwendung gemacht werden Abstrakte factory-Klasse wird für jedes GUI konkretisiert.

I SWT - Die Entwurfsphase - OOD (Grundlagen) Entwurfsmuster LE 30 Beispiel: »abstract factory« Motivation Konkrete Unterklassen implementieren die Schnittstelle für die einzelnen Fenstersysteme:

I SWT - Die Entwurfsphase - OOD (Grundlagen) Entwurfsmuster LE 30 Beispiel: »abstract factory« Motivation Für jedes Interaktionselement eine abstrakte Klasse mit konkreten Unterklassen In WidgetFactory ist je eine Operation zum Erzeugen eines Interaktionselement definiert Diese Operation muß von Anwendungen (Clients) aufgerufen werden In einzelnen GUIs nicht vorhandene Elemente können nachgebildet werden option button durch drop down combo box slider durch scrollbar.

I SWT - Die Entwurfsphase - OOD (Grundlagen) Entwurfsmuster LE 30 Beispiel: »abstract factory« Dieses Muster ist anwendbar, wenn... ein System unabhängig davon sein soll, wie seine Produkte erzeugt, zusammengesetzt und repräsentiert werden ein System mit einer von mehreren Produktfamilien konfiguriert werden soll eine Familie mit in Beziehung stehenden Produktobjekten zusammen benutzt werden soll eine Klassenbibliothek von Produkten zur Verfügung gestellt werden soll, aber nur die Schnittstellen, nicht aber die Implementierungen sichtbar sein sollen.

I SWT - Die Entwurfsphase - OOD (Grundlagen) Entwurfsmuster LE 30 Beispiel: »abstract factory« Struktur

3.10.4 Entwurfsmuster Beteiligte Abstract Factory: Concrete Factory:
I SWT - Die Entwurfsphase - OOD (Grundlagen) Entwurfsmuster LE 30 Beteiligte Abstract Factory: Deklariert die Schnittstelle für die Operationen, die abstrakte Produktobjekte erzeugen Concrete Factory: Implementiert die Operationen, um konkrete Produktobjekte zu erzeugen Abstract Product: Deklariert eine Schnittstelle für einen Typ des Objekts Concrete Product: Implementiert die Schnittstelle von Abstract Product Client: Benutzt nur die Schnittstellen, die durch Abstract Factory und Abstract Product deklariert sind.

I SWT - Die Entwurfsphase - OOD (Grundlagen) Entwurfsmuster LE 30 Beispiel: »abstract factory« Zusammenarbeit Zur Laufzeit wird im allgemeinen ein Objekt einer ConcreteFactory-Klasse erzeugt Diese konkrete Fabrik erzeugt Produktobjekte, die eine spezielle Implementierung besitzen Um andere Produktobjekte zu erzeugen, müssen Clients eine andere konkrete Fabrik benutzen Abstract Factory verlagert die Erzeugung von Produktobjekten zu ihren Unterklassen.

3.10.4 Entwurfsmuster Konsequenzen
I SWT - Die Entwurfsphase - OOD (Grundlagen) Entwurfsmuster LE 30 Konsequenzen Konkrete Klassen werden isoliert, d.h. Clients werden von Implementierungsklassen isoliert Klassennamen von Produkten werden in der Implementation der Concrete Factory isoliert Sie erscheinen nicht im Client-Code. Produkt-Familien leichter ausgetauschbar Die Klasse einer konkreten Fabrik erscheint nur einmal in der Anwendung, nämlich wenn ein Objekt von ihr erzeugt wird Fördert die Konsistenz zwischen Produkten, d.h. die Anwendung benutzt zu einer Zeit nur Objekte einer Familie.

3.10.4 Entwurfsmuster Konsequenzen
I SWT - Die Entwurfsphase - OOD (Grundlagen) Entwurfsmuster LE 30 Konsequenzen Unterstützung neuer Produkte schwierig, da Schnittstelle von Abstract Factory zu erweitern Gemeinsame Schnittstelle aller Produkte muß geschaffen werden Höhere Laufzeit.

abstract factory, abstract product
I SWT - Die Entwurfsphase - OOD (Grundlagen) Entwurfsmuster LE 30 abstract factory, abstract product class DialogFactory // abstract Factory { public: virtual YesNo* newYesNo(const char* m) const = NULL; virtual QueryVal* newQueryVal() const = NULL; }; class YesNo // abstract Product { public: virtual bool ask() = NULL; virtual bool getAnswer() const = NULL; };.

concrete factory in C++
I SWT - Die Entwurfsphase - OOD (Grundlagen) Entwurfsmuster LE 30 concrete factory in C++ class DialogFactoryT: public DialogFactory { public: YesNo* newYesNo(const char *m) const { return new YesNoT(m); } QueryVal* newQueryVal() const; }; class YesNoT: public YesNo { public: friend class DialogFactoryT; bool ask(); bool getAnswer() const { return val; } protected: YesNoT(const char *); bool val; char *msg; };.

concrete product in C++
I SWT - Die Entwurfsphase - OOD (Grundlagen) Entwurfsmuster LE 30 concrete product in C++ YesNoT::YesNoT(const char *m): val(false) { msg = strdup(m); } bool YesNoT::ask() { char ch; cout << msg << endl << "(J)a oder (N)ein "; cin >> ch; val = toupper(ch) == 'j') ? true:false; }.

abstract factory in C++: Anwendung
I SWT - Die Entwurfsphase - OOD (Grundlagen) Entwurfsmuster LE 30 abstract factory in C++: Anwendung int main(int argc, char **argv) { DialogFactory * F; if (argc == 2) F = new DialogFactoryW; else F = new DialogFactoryT; YesNo* q = F->newYesNo("Ihre Antwort"); cout << F->ask() << endl; }.

Entwurfsaspekte, die durch Entwurfsmuster variiert werden können
I SWT - Die Entwurfsphase - OOD (Grundlagen) Entwurfsmuster LE 30 Entwurfsaspekte, die durch Entwurfsmuster variiert werden können

3.10.4 Entwurfsmuster I SWT - Die Entwurfsphase - OOD (Grundlagen)
LE 30

Zusammenhänge OOD Ausgangspunkt: OOA-Modell
I SWT - Die Entwurfsphase - OOD (Grundlagen) Zusammenhänge LE 30 OOD Ausgangspunkt: OOA-Modell OOA  OOD: kein Strukturbruch Architekturentwurf Erweiterung des Modells um GUI + Datenhaltung Implementierungsentwurf Anpassen an die Programmiersprache Klassenbibliotheken einbinden Halbfabrikate einbinden Entwurfsmuster identifizieren und anwenden.

LE 30 Danke! Aufgaben Diese Präsentation bzw. Teile dieser Präsentation enthalten Inhalte und Grafiken des Lehrbuchs der Software-Technik (Band 1) von Helmut Balzert, Spektrum Akademischer Verlag, Heidelberg 1996

3 Die Entwurfsphase OOD (Grundlagen) Software-Technik

Ähnliche Präsentationen

Präsentation zum Thema: "3 Die Entwurfsphase OOD (Grundlagen) Software-Technik"— Präsentation transkript:

Ähnliche Präsentationen

Über Projekt

Feedback

Anmelden

Anmeldung über soziales Netzwerk:

3 Die Entwurfsphase OOD (Grundlagen) Software-Technik

Ähnliche Präsentationen

Präsentation zum Thema: "3 Die Entwurfsphase OOD (Grundlagen) Software-Technik"— Präsentation transkript:

Ähnliche Präsentationen

Über Projekt

Feedback