Software Engineering. 6. Objektorientierter Entwurf

Transkript

1 Software Engineering 6. Objektorientierter Entwurf

2 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

3 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

4 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

5 Verantwortlichkeiten Besser: Verteilte Funktionalität Quelle: Kleuker, Grundkurs Software Engineering mit UML. 2. Aufl., Vieweg+Teubner 2011

6 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

7 Offen-Geschlossen-Prinzip Besser: Nach: Starke, Effektive Software-Architekturen. 3. Aufl., Hanser 2008

8 Entwurf der Fachkonzept-Schicht OOA-Modell bildet erste Version der Fachkonzept-Schicht Vorgehen: Diese muss nun verfeinert und überarbeitet werden, insbesondere hinsichtlich der Effizienz und der Wiederverwendbarkeit Vorteil von OOA/OOD: Es findet kein Paradigmenwechsel statt 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

9 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

10 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

11 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)

12 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

13 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

14 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

15 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

16 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

17 Typ-Parameter Generische Klasse Konstanten-Parameter (hier nicht bei der Typ-Definition, sondern als Parameter beim Konstruktor) 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]; }

18 Ableitung von Klassen aus generischen Klassen Konstante Gebundener Typ public class IntSchlange extends Warteschlange<Integer>{ } public IntSchlange(){ super(10); }

19 Generische Klassen - Verwendung Warteschlange untypisierteschlange = new Warteschlange(5); // Beliebige Objekte einfügen untypisierteschlange.fuegeein(5); untypisierteschlange.fuegeein("hallo"); Nutzung ohne Typ // Beim Auslesen Casting erforderlich String s = (String)untypisierteSchlange.getElement(1); Bindung an Typ String Warteschlange<String> stringschlange = new Warteschlange<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 der aus einem generischen Typ abgeleiteten Klasse

20 Collections sind generische Klassen ArrayList a1 = new ArrayList(); ArrayList<String> a2 = new ArrayList<String>(); ArrayList<Integer> a3 = new ArrayList<Integer>(); ArrayList<MeineKlasse> a4 = new ArrayList<MeineKlasse>(); Vector<String> v1 = new Vector<String>(); Typ-sichere Listen von Objekten Nützlich für die Implementierung von Assoziationen

21 - Enthalten Reihenfolge (Zugriff über Index) - Doppelte Einträge erlaubt Java Collections-Hierarchie Basisfunktionalität zum Einfügen, Erzeugen eines Iterators, u. ä. Keine doppelten Einträge möglich Sortierung Implementierung einiger Basisfunktionen Keine Duplikate Definiert einige Navigiermethoden Doppelt verkettete Liste (Wahlfreier Zugriff schneller) Dynamische Arrays (Einfügen u. Löschen schneller) Alle Methoden synchronisiert trotzdem häufig nicht ausreichend für Threadsichere Zugriffe Unsortierte Menge Sortierte Menge

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

23 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. Interface "List" als Parameter-Typ public static void einemethode(list<string> eineliste){ //... } AbstractList<String> liste = new ArrayList<String>(); einemethode(liste); Übergabe einer ArrayList

24 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

25 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

26 Schnittstelle (Interface) Aufrufende Klasse nutzt die Schnittstelle AufrufendeKlasse <<use>> «interface» Schnittstelle Schnittstelle wird implementiert von Klasse 1 Schnittstelle wird implementiert von Klasse 2 Klasse 1 Klasse 2 Klasse 1 und Klasse 2 müssen beide je über eine Implementierung aller bei Schnittstelle definierten abstrakten Operationen verfügen, wobei sich die Implementierungen voneinander unterscheiden können.

27 Beispiel für Schnittstelle VersicherungGUI ermittlepraemie() <<use>> «interface» VersicherungInterface berechnepraemie(versicherungssumme : double) Versicherung 1 berechnepraemie(vsumme : double) berechnesonderpraemie(vsumme : double) Versicherung 2 berechnepraemie(vsumme : double) Unterschiedliche Implementierungen der Operation berechnepraemie

28 Schnittstellen alternative Darstellung Versicherung 1 berechnepraemie(vsumme : double) berechnesonderpraemie(vsumme : double) VersicherungInterface VersicherungGUI ermittlepraemie() VersicherungInterface Versicherung 1 berechnepraemie(vsumme : double) berechnesonderpraemie(vsumme : double) VersicherungInterface VersicherungGUI ermittlepraemie()

29 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

30 Navigierbarkeit Abteilung #Bezeichnung +druckegehaltsliste() Unidirektional 1 * Angestellter #Name #Personalnr #Gehalt +druckegehalt() Abteilung #Bezeichnung +druckegehaltsliste() Bidirektional 1 * Angestellter #Name #Personalnr #Gehalt +druckegehalt() +druckeausweis() Abteilung soll mit ausgedruckt werden, daher ist Kenntnis über die Abteilung erforderlich (Wenn kein Pfeil eingetragen ist, ist die Navigierbarkeit nicht definiert)

31 Realisierung von Assoziationen über Referenzen Klassen: Objekte: Abteilung 1 * Angestellter : Abteilung : Angestellter : Abteilung : Abteilung : Angestellter : Angestellter Jedes Objekt kennt die assoziierten Objekte Multiplizität 1 oder 0..1: einzelne Referenz Multiplizität > 1: Menge von Referenzen (Collection, z. B. ArrayList).

32 Realisierung mittels Assoziationsobjekt Klassen: Abteilung 1 * Angestellter Objekte: Abteilung : Abteilung * 1 Abteilung/Angestellter 1 * : Abteilung/Angestellter Angestellter : Angestellter : Abteilung : 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)

33 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} {frozen} 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 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

34 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

35 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

36 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" Quelle: UML 2 glasklar

37 Schachtelung von Packages

38 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

39 Komponente Bereitgestellte Schnittstelle Komponente Quelle: Seemann/Gudenberg, Software Entwurf mit UML Aufl., Springer 2006 Port (optional), dient zur Gruppierung von Schnittstellen

40 Benötigte Schnittstellen Komponente (alternative Darstellung) Benötigte Schnittstelle Quelle: Seemann/Gudenberg, Software Entwurf mit UML Aufl., Springer 2006

41 Zusammengesetzte Komponenten Quelle: Seemann/Gudenberg, Software Entwurf mit UML Aufl., Springer 2006

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

43 Implementierung Komponente (logisches Konstrukt) Komponente (logisches Konstrukt) Artefakt (physisch vorhanden, z. B. Datei) In Anlehnung an: Seemann/Gudenberg, Software Entwurf mit UML Aufl., Springer 2006

44 Verschiedene Darstellungen Teilnehmer Verwaltungsmetadaten Nach: UML 2 glasklar

45 UML-Komponentendiagramm Beispiel Quelle: Suhl, Bizer (FU Berlin)

46 Beispiel Komponentenstruktur und Interfaces Quelle: Suhl, Bizer (FU Berlin)

47 Elemente des Komponentendiagramms Quelle: UML 2 glasklar

48 UML Verteilungsdiagramm (Deployment Diagram) Hardware-Umfeld (Hardware-Topologie) Verteilung der Software auf die Hardware (Deployment)

49 Verteilungsdiagramm (Deployment Diagram) In Anlehnung an: Seemann/Gudenberg, Software Entwurf mit UML Aufl., Springer 2006

50 Verteilungsdiagramm (Deployment Diagram) Kommunikationspfad, gerichtet oder ungerichtet: Darstellung als Assoziation (auch Angaben von Multiplizitäten sind möglich) Verteilungsbeziehung: Artefakt wird auf Knoten deployed Alternative Darstellung der Verteilungsbeziehung Knoten (node): Betriebsmittel, das Verarbeitungs- und/oder Speicherkapazität zur Verfügung stellt (z. B. ein Computer, Router, Sensor, ) Quelle: UML 2 glasklar

51 Verteilungsdiagramm (Deployment Diagram) Allgemeine Abhängigkeitsbeziehung Quelle: UML 2 glasklar