6. Objektorientierter Entwurfteam.fh-kl.de/uploads/media/SWE-06-Entwurf-OOD-v05.pdf · Zustandsmuster Ausführende ... Dienen dazu, das Vererbungskonzept voll auszunutzen,werden stets

6. Objektorientierter Entwurf

Software Engineering

Gliederung Vorlesung

� Einführung� V-Modell XT� Analyse und Anforderungsmanagement� Benutzungsoberflächen� Architektur� Entwurf� Entwurfsmuster� Persistenz� Implementierung� Konfigurationsmanagement� Testen� Abnahme, Einführung, Wartung und Pflege

Allweyer: Software Engineering

Entwurfsprinzipien

� KISS – Keep it simple and stupid● Möglichst einfache und klare Implementierung bevorzugen

� YAGNI – You ain‘t gonna need it● Keine Verallgemeinerungen einführen für Dinge, die vielleicht in Zukunft

einmal benötigt werden− Beispiel: Nicht von Vornherein Setter-Methoden für alle Attribute

� Geringe Kopplung● Zwischen verschiedenen Klassen/Paketen/Komponenten

● Zyklische Abhängigkeiten vermeiden

● Fachliche und technische Aspekte trennen

� Hohe Kohäsion● Innerhalb verschiedener Klassen/Pakete/Komponenten


Verantwortlichkeiten

� Eine Funktionalität sollte in der Klasse realisiert sein, die diese Aufgabe ohne weiteres Wissen bearbeiten kann

� Negativ-Beispiel: Allwissende Klasse


Quelle:Kleuker, Grundkurs Software Engineering mit UML.2. Aufl., Vieweg+Teubner 2011

Verantwortlichkeiten

� Besser: Verteilte Funktionalität


Quelle:Kleuker, Grundkurs Software Engineering mit UML.2. Aufl., Vieweg+Teubner 2011

Offen-Geschlossen-Prinzip

� Offen für Erweiterungen, geschlossen für Änderungen● Erweiterungen sollten leicht möglich sein

● Dabei sollte der vorhandene Code möglichst wenig geändert werden müssen

� Beispiel:void draw(){

if (type.equals("circle")

drawCircle();

else if (type.equals("square")

drawSquare();

}


Nach:Starke, Effektive Software-Architekturen.3. Aufl., Hanser 2008

Offen-Geschlossen-Prinzip

� Besser:


Nach:Starke, Effektive Software-Architekturen.3. Aufl., Hanser 2008


Entwurf der Fachkonzept-Schicht

� OOA-Modell bildet erste Version der Fachkonzept-Schicht● Diese muss nun verfeinert und überarbeitet werden, insbesondere

hinsichtlich der Effizienz und der Wiederverwendbarkeit

● Vorteil von OOA/OOD: Es findet kein Paradigmenwechsel statt

� Vorgehen:1. Modifikation der Klassenstruktur

2. Verfeinern der Attribute

3. Verfeinern der Operationen

4. Verfeinern von Assoziationen

5. Verfeinern der Vererbung

Quelle:Starke, Effektive Software-Architekturen.3. Aufl., Hanser 2008


1. Modifikation der Klassenstruktur

� Hinzufügen von Container-Klassen● Objektverwaltung wurde in der Analyse als inhärente Eigenschaft der Klassen

angesehen. Im Entwurf muss diese mit Hilfe sog. Container-Klassen modelliert werden.

� Zerlegen komplexer Klassen● Die meisten OOA-Klassen werden 1:1 übernommen● Wird die funktionale Komplexität zu hoch, sollten Teilaufgaben an detailliertere

Klassen delegiert werden� Zusammenfassen von Klassen mit starker Interaktion

● Aus Performance-Gründen können u. U. Klassen mit hoher Kopplung zusammengefasst werden

� Hinzufügen von Klassen zum Modellieren von Zwischenergebnissen● Bündelung abgeleiteter Attribute in gemeinsame Klassen

� Transformation von assoziativen Klassen zu normalen Klassen● Assoziative Klassen können nicht direkt implementiert werden und sind daher

aufzulösen


2. Verfeinern der Attribute

� Detailliertere Beschreibung● Sichtbarkeiten, Datentypen, Anfangswerte, ...

� Abgeleitete Attribute des OOA-Modells übernehmen oder in Operationen wandeln

● Dynamische Berechnung abgeleiteter Attribute− Operation zur Berechnung vorsehen

● Speicherung der abgeleiteten Attribute− Wenn komplexe Berechnungen gespart werden und sich die Ursprungsdaten

nicht häufig ändern

− Realisierung von Update-Operationen (wenn sich die Ursprungsdaten ändern, müssen die abgeleiteten Attribute automatisch mit geändert werden)

� Neue abgeleitete Attribute einführen● Zur Speicherung von Zwischenergebnissen


3. Verfeinern der Operationen

� Detailliertere Beschreibung● Sichtbarkeiten, Datentypen, Anfangswerte, ...

� Komplexe Operationen in einfache, interne Operationen zerlegen

● Beispiel: Untergliedern einer Erfassungsoperation in eine Operation zur Eingabeprüfung und eine Operation zur Speicherung

● Ggf. müssen neue Klassen identifiziert werden

� Transformieren von Lebenszyklen in Algorithmen oder Zustandsmuster

● Ausführende Operation kann vom jeweiligen Objektzustand abhängen

● Der Algorithmus muss daher entsprechende Abfragen enthalten oder – in komplexen Fällen – wird der Lebenszyklus mit Hilfe eigener Klassen modelliert (Zustandsmuster)


4. Verfeinern der Assoziationen

� Prüfen, welche Assoziationen unidirektional modelliert werden können

● In der Analyse: alle Assoziationen bidirektional● Aus Effizienzgründen ist für jede Assoziation zu prüfen, ob eine

Navigationsrichtung ausreicht.● In diesem Fall ist die Navigationsrichtung durch einen Pfeil zu markieren

� Zugriffspfade optimieren● In der Analyse: Vermeidung redundanter Assoziationen● Im Entwurf: Optimalen, effizienten Zugriff auf Objekte sicherstellen, ggf.

können hierfür redundante Assoziationen erforderlich sein● U. U. sind anschließend Assoziationen aus der Analyse überflüssig und

können entfernt werden● Für jede Operation ist zu prüfen, welche Assoziationen sie jeweils

durchlaufen muss, um an die jeweilige Information zu kommen


5. Verfeinern der Vererbung (1)

� Abstrakte Operationen für einheitliche Schnittstellen hinzufügen

● Identifizieren von ähnlichen Operationen, prüfen ob gemeinsame abstrakte Operationen gebildet werden können

� Hinzufügen von abstrakten Oberklassen

● Dienen dazu, das Vererbungskonzept voll auszunutzen,werden stets künstlich in das Modell eingefügt

● Umgekehrt ist zu prüfen, ob sinnlose Oberklassen gebildet wurden. Indiz: Klassenname ohne Aussagekraft, steht in keiner Beziehung zu Attributen und Operationen

� Maximierung des Polymorphismus

● Operationen so hoch wie möglich in die Vererbungshierarchie einordnen

● Nutzung eines einzigen Namens für konzeptionell gleiche Operationen,z. B. drucken(), erfassen()

● Alle Operationen sind in der Schnittstelle so allgemein wie möglich zu halten


5. Verfeinern der Vererbung (2)

� Komprimieren von Vererbungsstrukturen● Umgekehrt kann es in konkreten Fällen auch sinnvoll sein, eine

Vererbungsstruktur wieder zu einer Klasse zusammenzufassen.

● Dadurch wird ein Teil der im statischen Modell spezifizierten Semantik in das dynamische Modell übernommen

● (Siehe Beispiel auf der nächsten Folie)

� Wiederverwenden existierender Klassen● Im Ggs. zur Analyse spielt Wiederverwendung (reuse) im Entwurf eine

große Rolle

● Zugunsten der Wiederverwendung können die Anforderungen an „gute“ Vererbungsstrukturen reduziert werden− Z. B. Nutzung von Oberklassen, wobei in der Unterklasse nicht alle Operationen

und Attribute benötigt werden


OOD-Modell

� OOD = Object Oriented Design

� Grundlage für OOD-Modell ist das OOA-Modell● Insbesondere Klassendiagramm

� OOD-Modell soll Spiegelbild des Programms sein● Namen, Datentypen etc. des OOD-Modells sollten denen der verwendeten

Programmiersprache entsprechen

● Häufig: Verwendung englischer Namen und Bezeichnungen− Kürzere Bezeichnungen

− Durchgängigkeit zu den meist englischsprachigen Klassenbibliotheken


Objekt / Klasse

� Stereotypen ● Können z. B. eingesetzt werden, um die Zugehörigkeit zu bestimmten

Entwurfskomponenten zu kennzeichnen

● Beispiele:− <<DB>> für Datenverwaltungsklassen

− <<UI>> für User Interface

Generische Klasse


public class Warteschlange<T> {private Object[] warteschlange;private int position=0;

public Warteschlange(int maxlaenge){warteschlange = new Object[maxlaenge];

}

public void fuegeEin(T t){warteschlange[position] = t;position++;

}

public T getElement(int position){return (T)warteschlange[position];

}}

Typ-Parameter

Konstanten-Parameter(hier nicht bei der Typ-Definition, sondern als Parameter beimKonstruktor)

Ableitung von Klassen aus generischen Klassen


public class IntSchlange extends Warteschlange<Integer>{

public IntSchlange(){super(10);

}}

Gebundener TypKonstante

Generische Klassen - Verwendung


Warteschlange untypisierteSchlange = new Warteschlan ge(5);// Beliebige Objekte einfügen

untypisierteSchlange.fuegeEin(5);untypisierteSchlange.fuegeEin("Hallo");

// Beim Auslesen Casting erforderlichString s = (String)untypisierteSchlange.getElement( 1);

Warteschlange<String> stringSchlange = new Warteschl ange<String>(3);// Hier kann man nur Strings einfügen:

stringSchlange.fuegeEin("Hallo"); // Beim Auslesen kein Casting erforderlich:

String s1 = stringSchlange.getElement(0);

IntSchlange intschlange = new IntSchlange();// Hier kann man nur Integer einfügen:

intschlange.fuegeEin(5);// Beim Auslesen kein Casting erforderlich:

int i1 = intschlange.getElement(0);

Nutzung ohne Typ

Bindung an Typ String

Nutzung deraus einemgenerischen Typabgeleiteten Klasse

Collections sind generische Klassen

� Typ-sichere Listen von Objekten

� Nützlich für die Implementierung von Assoziationen


ArrayList a1 = new ArrayList();ArrayList<String> a2 = new ArrayList<String>();ArrayList<Integer> a3 = new ArrayList<Integer>();ArrayList<MeineKlasse> a4 = new ArrayList<MeineKlas se>();Vector<String> v1 = new Vector<String>();

Java Collections-Hierarchie


- Enthalten Reihenfolge(Zugriff über Index)

- Doppelte Einträgeerlaubt

Keine doppeltenEinträge möglich

Basisfunktionalitätzum Einfügen, Erzeugen einesIterators, u. ä.

Alle Methoden synchronisiert – trotzdem häufig nicht ausreichend für Thread-sichere Zugriffe

DynamischeArrays(Einfügen u.Löschen schneller)

Sortierung

Implementierungeiniger Basisfunktionen

Keine Duplikate

Unsortierte Menge

Sortierte Menge

Definierteinige Navi-giermethoden

Doppeltverkettete Liste(Wahlfreier Zugriff

schneller)

Auswahl von Collections

� Benötigte Eigenschaften● z. B. Reihenfolge, doppelte Einträge, wahlfreier Zugriff etc.

� Speicherbedarf und Perfomance● Je nach Größe und verwendeten Operationen eignen sich unterschiedliche

Implementierungen

● Soll ein Zugriff über bestimmte Schlüssel erfolgen, eignen sich statt der Collections Implementierungen des Interface "Map" (z. B. HashMap, TreeMap).


Nutzung von Interfaces und abstrakten Klassen

� Wo keine bestimmte Implementierung erforderlich ist, kann man in der Deklaration ein Interface oder eine abstrakte Klasse verwenden

� Es kann dann eine beliebige Implementierung verwendet werden.


public static void eineMethode(List<String> eineListe){// ...

}

AbstractList<String> liste = new ArrayList<String>();eineMethode(liste);

Interface "List" als Parameter-Typ

Übergabe einer ArrayList


Container-Klasse

� In der Analyse wurde vereinfachend davon ausgegangen, dass jede Klasse ihre Objekte selbst verwaltet

� Im Entwurf muss diese Objektverwaltung realisiert werden

� Container-Klasse ● Verwaltet eine Menge von Objekten einer anderen Klasse

● Stellt Operationen bereit, um auf die verwalteten Objekte zuzugreifen

� Realisierung mit Hilfe von Arrays oder Collections


Schnittstellen (Interface)

� Eine Schnittstelle spezifiziert einen Ausschnitt aus dem Verhalten einer Klasse

� Besteht nur aus den Signaturen von Operationen● Besitzt keine Implementierung, Attribute, Zustände oder Assoziationen

� Ist äquivalent zu einer abstrakten Klasse, die ausschließlich abstrakte Operationen besitzt

� Implementierung einer Schnittstelle durch eine Klasse wird durch einen gestrichelten Vererbungspfeil gekennzeichnet


Schnittstelle (Interface)

«interface»Schnittstelle

Klasse 1 Klasse 2

Aufrufende Klasse nutzt die Schnittstelle

Schnittstelle wirdimplementiertvon Klasse 2

AufrufendeKlasse

Schnittstelle wirdimplementiertvon Klasse 1

Klasse 1 und Klasse 2 müssen beide je über eine Implementierung aller beiSchnittstelle definierten abstrakten Operationen verfügen, wobei sich dieImplementierungen voneinander unterscheiden können.

<<use>>


Beispiel für Schnittstelle

berechnePraemie(Versicherungssumme : double)

«interface»VersicherungInterface

berechnePraemie(VSumme : double)berechneSonderpraemie(VSumme : double)

Versicherung 1

berechnePraemie(VSumme : double)

Versicherung 2

ermittlePraemie()

VersicherungGUI

Unterschiedliche Implementierungender Operation berechnePraemie

<<use>>

ermittlePraemie()

VersicherungGUI

Schnittstellen – alternative Darstellung



Versicherung 1

ermittlePraemie()

VersicherungGUI


Versicherung 1

VersicherungInterface




Assoziationen

� In der Analyse:● Alle Assoziationen bidirektional

● Navigation in beide Richtungen möglich

� Im Entwurf:● Explizite Angabe über Navigation erforderlich

● Unidirektionale Assoziationen sind einfacher zu implementieren


Navigierbarkeit

+druckeGehaltsliste()

#Bezeichnung

Abteilung

+druckeGehalt()

#Name#Personalnr#Gehalt

Angestellter

1 *

+druckeGehaltsliste()

#Bezeichnung

Abteilung

+druckeGehalt()+druckeAusweis()

#Name#Personalnr#Gehalt

Angestellter

1 *

Unidirektional

Bidirektional

(Wenn kein Pfeil eingetragen ist, ist dieNavigierbarkeit nicht definiert)

Abteilung sollmit ausgedrucktwerden, daherist Kenntnis überdie Abteilungerforderlich


Realisierung von Assoziationen über Referenzen

� Jedes Objekt kennt die assoziierten Objekte� Multiplizität 1 oder 0..1: einzelne Referenz� Multiplizität > 1: Menge von Referenzen

(Collection, z. B. ArrayList).

Abteilung Angestellter1 *

: Abteilung : Angestellter

: Angestellter: Abteilung

: Abteilung: Angestellter

Klassen:

Objekte:


Realisierung mittels Assoziationsobjekt

Abteilung Angestellter1 *

Abteilung AngestellterAbteilung/Angestellter* *

Klassen:

Objekte:

: Abteilung

: Abteilung

: Abteilung

: Angestellter

: Angestellter

: Angestellter

: Abteilung/Angestellter

...

Assoziationsobjekt – weiß, wer mit wem verbunden ist.

Ermöglicht Assoziationen zu Klassen, die nicht verändert werden können (z. B. aus Bibliotheken)

1 1


Weitere Möglichkeiten für Assoziationen

� Merkmale für Assoziationen● {ordered}

− Geordnete Assoziationen (z. B. Sortierung nach Kundennr)

− Realisierung über eine Container-Klasse, die Ordnung der Elemente berücksichtigt, z. B. ArrayList

● {unique}− Stellst sicher, dass jedes Element nur einmal vorkommt, z. B. durch Verwendung eines

Set

− Oft wird davon ausgegangen, dass eine Assoziation diese Eigenschaft hat, eindeutig gefordert wird dies aber nur durch die {unique}-Angabe

● {frozen} − Objektverbindung kann weder hinzugefügt, gelöscht noch geändert werden, wenn sie mit

dem Erzeugen des entsprechenden Objekts einmal angelegt wurde

● {addOnly}− Es dürfen nur neue Verbindungen hinzugefügt, vorhandene aber nicht gelöscht werden


Aggregation / Komposition

� Aggregation wird genauso realisiert wie eine normale Assoziation, wobei

● stets das Ganze seine Teile kennen muss (Navigierbarkeit vom Aggregat zur Komponente!)

● Keine Zyklen in der Objektstruktur auftreten dürfen

� Komposition ebenso wie Aggregation, zusätzlich:● Bei der Definition von Operationen ist zu berücksichtigen, dass Operationen,

die das Ganze betreffen, häufig auch die Teile betreffen.● Zugriff und Erzeugen der Teile erfolgen über das Aggregatobjekt● Realisierungsmöglichkeiten:

− Über eine Referenz (wie eine gewöhnliche Assoziation)− Über Methoden sicherstellen, dass Änderungen immer über das Aggregat erfolgen

− Über Enthaltensein (Inner Class)− Vorteil: Erzeugen, Löschen und Kopieren findet automatisch gemeinsam statt− Nachteil: Direkter Zugriff von Außen auf ein Teil schwierig


Pakete (Packages)

� Entwurfsmodelle wesentlich umfangreicher als Analysemodelle, daher ist die Strukturierung mit Hilfe von Paketen noch wichtiger

� Schachtelung von Packages ermöglicht die Modellierung des Systems auf verschiedenen Abstraktionsebenen

Paketdiagramm

� <<access>>● Privater Import: Die importierten Pakete sind im importierenden Paket private

� <<ímport>>● Öffentlicher Import: Importierte Pakete sind auch nach außen sichtbar

� Öffentlich sichtbare Elemente lassen sich von außen ohne Import-Beziehung über vorangestellten Paketnamen referenzieren, z. B. "P2::B"

Allweyer: Software Engineering Quelle: UML 2 glasklar


Schachtelung von Packages

UML-Komponentendiagramme

� Komponente● Modularer Systemteil

● Kommunikation nur über Schnittstellen

● In einer Komponente wirken mehrere Klassen zusammen

� Komponentendiagramm● Darstellung der physischen Struktur eines Systems

● Bestandteile

● Interne Struktur von Komponenten

● Wechselbeziehungen zwischen Komponenten


Komponente


Bereitgestellte Schnittstelle

Komponente

Port (optional),dient zur Gruppierung vonSchnittstellen

Quelle:Seemann/Gudenberg, Software Entwurf mit UML 2.2. Aufl., Springer 2006

Benötigte Schnittstellen


Komponente(alternative Darstellung)

Benötigte Schnittstelle


Zusammengesetzte Komponenten



Alternative Darstellung


In Anlehnung an:Seemann/Gudenberg, Software Entwurf mit UML 2.2. Aufl., Springer 2006

Implementierung


Artefakt(physisch vorhanden, z. B. Datei)

Komponente(logisches Konstrukt)

Komponente(logisches Konstrukt)


Verschiedene Darstellungen


Nach: UML 2 glasklar

Teilnehmer

Verwaltungs-metadaten

UML-Komponentendiagramm – Beispiel


Quelle: Suhl, Bizer (FU Berlin)

Beispiel Komponentenstruktur und Interfaces


Quelle: Suhl, Bizer (FU Berlin)

Elemente des Komponentendiagramms


Quelle: UML 2 glasklar

UML Verteilungsdiagramm (Deployment Diagram)

� Hardware-Umfeld (Hardware-Topologie)

� Verteilung der Software auf die Hardware (Deployment)


Verteilungsdiagramm (Deployment Diagram)






Knoten (node):Betriebsmittel, das Verarbeitungs- und/oder Speicherkapazität zur Verfügung stellt (z. B. ein Computer, Router, Sensor, …)

Kommunikationspfad, gerichtet oder ungerichtet:Darstellung als Assoziation (auch Angaben von Multiplizitäten sind möglich)

Verteilungsbeziehung:Artefakt wird auf Knotendeployed

Alternative Darstellungder Verteilungsbeziehung



Allgemeine Abhängigkeitsbeziehung


Documents

6. Objektorientierter Entwurfteam.fh-kl.de/uploads/media/SWE-06-Entwurf-OOD-v05.pdf · Zustandsmuster Ausführende ... Dienen dazu, das Vererbungskonzept voll auszunutzen,werden stets