© Helmut Balzert 1998 LE 30 1 Software-Technik 3 Die Entwurfsphase OOD (Grundlagen) Prof. Dr....

© Helmut Balzert 1998

LE 30

1Software-Technik

3 Die EntwurfsphaseOOD (Grundlagen)

Prof. Dr. Helmut Balzert

Lehrstuhl für Software-Technik

Ruhr-Universität Bochum

I SWT - Die Entwurfsphase - OOD (Grundlagen)

LE 30

2Einführung und Überblick

LE 1

V Unternehmensmodellierung

2 LE

1 Grundlagen

LE 24

2 ObjektorientierteUnternehmensmodellierung

LE 25

I SW-Entwicklung

32 LE

6 Die Wartungs- & Pflegephase

LE 33

5 Die Abnahme- undEinführungsphase

LE 33

4 Die Implementierungsphase

LE 32

3 Die Entwurfsphase

LE 23 – 31

2 Die Definitionsphase

LE 4 – 22

1 Die Planungsphase

LE 2 – 3

III SW-Qualitäts-sicherung

11 LE

6 Produktqualität– Systeme

LE 18 – 19

5 Produktqualität– Komponenten

LE 14 – 17

4 Prozeßqualität

LE 12 – 13

3 ManuellePrüfmethoden

LE 11

2 Qualitäts-sicherung

LE 10

1 Grundlagen

LE 9

II SW-Management

8 LE

6 Kontrolle

LE 8

5 Leitung

LE 6 – 7

4 Personal

LE 5

3 Organisation

LE 3 – 4

2 Planung

LE 2

1 Grundlagen

LE 1

IV Querschnitte und Ausblicke

4 LE

4 Sanierung

LE 23

1 Prinzipien& Methoden

LE 20

3 Wieder-verwendung

LE 22

2

LE 21


LE 30

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


LE 30

4Inhalt

3.10 Objektorientierter Entwurf3.10.1 Einführung und Überblick

3.10.2 Klassenbibliotheken und ihre Architektur

3.10.3 Halbfabrikate und ihre Schnittstellen

3.10.4 Entwurfsmuster.


LE 30

53.10 Objektorientierter Entwurf Zur Historie

Grady Booch*27.2.1955 in TexasChief ScientistRational 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++.


LE 30

63.10.1 Einführung und Überblick 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.


LE 30

73.10.1 Einführung und Überblick 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.


LE 30

83.10.1 Einführung und Überblick 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.

technischeAnwendungen


LE 30

93.10.1 Einführung und Überblick 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.


LE 30

103.10.1 Einführung und Überblick Entscheidungen bei OOD


LE 30

113.10.2 Klassenbibliotheken und ihre Architektur Klassenbibliotheken

Organisierte Softwaresammlungen, aus der der Entwickler nach Bedarf Einheiten verwendet

Bilden die Voraussetzung, um »Wiederverwendung im Kleinen« zu realisieren

Eigenentwicklung kommerziell.


LE 30

123.10.2 Klassenbibliotheken und ihre Architektur Anwendungsgebiete von Klassenbibliotheken

Fundamental-Klassenbibliotheken(foundationclasslibraries)GUI-KlassenbibliothekenGrafik-KlassenbibliothekenKlassenbibliothekenzumZugriffaufDatenbankenKlassenbibliothekenzurInterprozeß-kommunikationAnwendungs-spezifischeKlassenbibliotheken

fundamentale,allgemeinnutzbare,systemnaheKlassenwieListen,strings,bags,maps,queuesusw.KlassenfürgrafischeBenutzungs-oberflächen,wiewidgets,menu-bar,scrollbar,window,listbox,textedit

KlassenzurAnsteuerungvon(relationalen)Datenbank-systemenKlassenzurKommunikationzwischenProzessen:dispatcher,datarepresentation,messageheader,name-service

KlassenzurEntwicklungkom-plexer,interaktiverGrafikan-wendungen:Diagramme,spread-sheets,Skalen,VektorgrafikenKlassen-bibliotheken


LE 30

133.10.2 Klassenbibliotheken und ihre Architektur 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.


LE 30

143.10.2 Klassenbibliotheken und ihre Architektur 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.


LE 30

153.10.2 Klassenbibliotheken und ihre Architektur Grundlegende Bibliothekstopologien

EinegemeinsameWurzelklasseSmalltalk-ähnlicheKlassenstrukturWurzelklasseenthältallgemeineDienstewieLaufzeit-Typinformation,exceptionhandling,Persistenz-MechanismenLosegekoppelteBaumhierarchienZusammenfassungvonKlassenzueinzelnenunabhängigenKomponentenunabhängigeVerwendungjederKomponente

UnabhängigeKlassenGeneralisierungdurchparametrisierteKlassen(templates),nichtdurchVererbung(ADT)

Baum

Wald

Bausteine

Topologie


LE 30

163.10.2 Klassenbibliotheken und ihre Architektur Beispiele für Bibliothekstopologien

WurzelKlasseA KlasseB KlasseC KlasseD...

aBaum

bWald

cUnabhängigeKlassen

WurzelA WurzelB WurzelCKlasseA1 KlasseA2 KlasseB1 KlasseB2 KlasseC1 KlasseC2 KlasseC3KlasseA11KlasseA12 KlasseB11KlasseB12KlasseB13 KlasseC11

KlasseC3KlasseA1 KlasseA2 KlasseB1 KlasseB2 KlasseC1 KlasseC2

KlasseA KlasseEKlasseB

KlasseCKlasseD


aBaum

bWald





KlasseCKlasseD


aBaum

bWald





KlasseCKlasseD


LE 30

173.10.2 Klassenbibliotheken und ihre Architektur 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.


LE 30

183.10.2 Klassenbibliotheken und ihre Architektur 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.


LE 30

193.10.2 Klassenbibliotheken und ihre Architektur 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.


LE 30

203.10.2 Klassenbibliotheken und ihre Architektur »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.


LE 30

213.10.2 Klassenbibliotheken und ihre Architektur 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.


LE 30


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.


LE 30


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.


LE 30


KnotenklasseA

Schnittstelle

KnotenklasseB

konkreteKlasseA1 konkreteKlasseA2

abstrakteKlasse DientalsWurzelklasse

Spezialisierung

AnpassungankonkretenVerwendungszweck

Schnittstellen-klassemodifizierteSchnittstelle


LE 30

253.10.3 Halbfabrikate und ihre Schnittstellen 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.


LE 30

263.10.3 Halbfabrikate und ihre Schnittstellen 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.


LE 30

273.10.3 Halbfabrikate und ihre Schnittstellen 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.


LE 30

283.10.3 Halbfabrikate und ihre Schnittstellen 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.


LE 30

293.10.3 Halbfabrikate und ihre Schnittstellen Das CORBA-Modell


LE 30

303.10.3 Halbfabrikate und ihre Schnittstellen 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.


LE 30

313.10.3 Halbfabrikate und ihre Schnittstellen 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();

};.

Person

NameVorname

Drucken


LE 30

323.10.3 Halbfabrikate und ihre Schnittstellen 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.


LE 30


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.


LE 30


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.


LE 30


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.


LE 30

363.10.3 Halbfabrikate und ihre Schnittstellen 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.


LE 30


Beispiel: Verknüpfung von OCX-Komponenten


LE 30


Beispiel: Visual Basic-Code Rechtschreibprogramm

von Excel integrieren

Private Sub Rechtschreibung_Click()Dim x As ObjectSet x = CreateObject("Excel.Sheet")x.Cells(1,1).Value = Text1.Textx.Visible = Truex.CheckSpellingText1.Text = x.Cells(1,1).Valuex.Application.QuitSet x = Nothing

End Sub

Excel-Objektdeklarieren

und erzeugenZelle mit Inhaltfüllen, anzeigen

Rechtschreibungprüfen

Wert zurückschreiben,Excel beenden undObjekt vernichten.


LE 30

393.10.3 Halbfabrikate und ihre Schnittstellen 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.


LE 30

403.10.3 Halbfabrikate und ihre Schnittstellen 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!

IUnknown

AddRefReleaseQueryInterface


LE 30

413.10.3 Halbfabrikate und ihre Schnittstellen 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.


LE 30

423.10.3 Halbfabrikate und ihre Schnittstellen 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.


LE 30

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


LE 30

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


LE 30

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


LE 30

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


LE 30

473.10.4 Entwurfsmuster Klassifikation von Entwurfsmustern

ZweckerzeugendesMuster strukturellesMuster VerhaltensmusterGültig- Klassefactorymethod adapterclass interpreterkeits- templatemethodbereichObjektabstractfactory adapter(object) chainofresponsibilitybuilder bridge commandprototype composite iteratorsingleton decorator mediatorfacade mementoflyweight observerproxy statestrategyvisitor


LE 30

48Beziehungen zwischen Entwurfsmustern

builder

decorator

strategystate

prototype

singleton

flyweight

abstractfactory

iterator

composite

interpreter

templatemethod

facade

memento

visitor

factorymethod

adapter proxybridgecommand

chainofresponsibility

observer

creatingcomposites enumeratingchildren

savingstateofiteration

addingresponsibilitiestoobjects

avoidinghysteresis

composedusingdefiningtraversals

sharingcomposites defininggrammar addingoperations

addingoperations

sharingterminalsymbols

changingskinversusgutssharingstrategies

definingthechain

mediator complexdependencymanagementdefiningalgorithmssteps oftenusesconfigurefactorydynamicallysingleinstance singleinstance

implementusing


LE 30

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


LE 30


Motivation Konkrete Unterklassen implementieren die

Schnittstelle für die einzelnen Fenstersysteme:

ClientWidgetFactoryCreateScrollBar()CreateWindow()MotifWidgetFactoryCreateScrollBar()CreateWindow()

Win95WidgetFactoryCreateScrollBar()CreateWindow()Objekterzeugung

ReferenzWindow

MotifWindowWin95Window

Win95ScrollBar MotifScrollBarScrollBar


LE 30


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.


LE 30


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.


LE 30


Struktur

ClientAbstractFactoryCreateProductA()CreateProductB()ConcreteFactory1CreateProductA()CreateProductB()

ConcreteFactory2CreateProductA()CreateProductB()

AufforderungzumKreiereneinesProdukts

ProductA1ProductA2

ProductB2 ProductB1

AbstractProductA

AbstractProductBErzeugtkonkretesProdukt


LE 30

543.10.4 Entwurfsmuster

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.


LE 30


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.


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.


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.


LE 30

583.10.4 Entwurfsmuster 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;

};.


LE 30

593.10.4 Entwurfsmuster 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; };.


LE 30

603.10.4 Entwurfsmuster 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;

}.


LE 30

613.10.4 Entwurfsmuster 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;

}.


LE 30

62

Entwurfsaspekte, die durch Entwurfsmuster variiert werden können



LE 30



LE 30

66Zusammenhänge 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

67

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

© Helmut Balzert 1998 LE 30 1 Software-Technik 3 Die Entwurfsphase OOD (Grundlagen) Prof. Dr....

Documents

Transcript of © Helmut Balzert 1998 LE 30 1 Software-Technik 3 Die Entwurfsphase OOD (Grundlagen) Prof. Dr....