Objektorientierter Entwurf (OOD) Teil 2: Optimierung des OO-Modells

1. Objektorientierter Entwurf (OOD)Teil 2:Optimierung des OO-Modells Erweiterung des OOA-Modells und Anpassung an die Zielsprache: 1. Anpassung der Namen im Hinblick auf die Zielsprache 2. Konsequenter Einsatz der Stereotyp-Bezeichnungen: <<stereotyp>> 3. Konsequenter Einsatz von Bezeichnern für Klasseneigenschaften: {property} 4. Definition von Container-Klassen, sofern noch nicht gemacht 5. Definition von Schnittstellen-Klassen 6. Festlegen der Sichtbarkeiten, sowohl für Attribute als auch für Operationen 7. Vervollständigen der Signatur der Operationen 8. Definition von abstrakten Operationen 9. Angabe der Navigation bei den Assoziationen/Aggregationen 10. Konkretisieren der Vererbung (Polymorphismus, Mehrfachvererbung) 11. Definition von Paketen, sofern noch nicht gemacht 12. Konkretisierung der Zustandsdiagramme für Klassen (Lebenszyklus) 13. Heuristiken und Metriken Christoph Riewerts

2. Objektorientierter Entwurf (OOD)1. Namensvergabe Beispiele für die Namensvergabe bei Klassen-Attributen

3. Objektorientierter Entwurf (OOD)1. Namensvergabe Beispiele für die Namensvergabe bei Klassen-Operationen

4. Objektorientierter Entwurf (OOD)1. Namensvergabe • Konventionen für Bezeichner (problemnahe, natürlichsprachliche Namen): • Jeder Bezeichner (Identifier) beginnt mit einem Buchstaben, der Unterstrich (_) wird nicht verwendet • Bezeichner enthalten keine Leerzeichen (Ausnahme galt für OOA) • Generell ist Groß-/Kleinschreibung zu verwenden, jedoch dürfen sich zwei Bezeichner nicht nur bezüglich der Groß-/Kleinschreibung unterscheiden • Entweder die deutsche oder die englische Namensgebung verwenden (Ausnahme engl. übliche Begriffe wie push) • Wird die deutsche Namensgebung verwendet, dann ist auf Umlaute und »ß« zu verzichten (Ausnahme galt für OOA) • Besteht ein Bezeichner aus mehreren Worten, dann beginnt jedes Wort mit einem Großbuchstaben (z.B. AnzahlWorte), Unterstriche werden nicht zur Trennung eingesetzt • Hier findet man Richtlinien für Namenskonventionen für… • Java: //java.sun.com/docs/codeconv/ • .NET: //msdn.microsoft.com/library/DEU/cpgenref/html/cpconNETFrameworkDesignGuidelines.asp

5. Objektorientierter Entwurf (OOD)1. Namensvergabe • Konventionen für Bezeichner (problemnahe, natürlichsprachliche Namen): • Klassennamen... beginnen immer mit einem Großbuchstaben und sind ein Substantiv im Singular zu benennen (z.B. Seminar, Ausschreibung), GUI-Klassen enthalten das Suffix GUI (oder zumindest eine entspr. Stereotypbez.) • Objektnamen... beginnen immer mit einem Kleinbuchstaben, enden in der Regel mit dem Klassennamen (z.B. einKunde), beginnen bei anonymen Objekten mit ein, erster, a (z.B. aPoint, einRechteck) • Attributnamen… beginnen im Englischen immer mit einem Kleinbuchstaben, um eine Verwechslungsgefahr mit Klassen auszuschließen (z.B. hotWaterLevel) undbeginnen im Deutschen mit einem Großbuchstaben (z.B. ZeilenZähler) • Operationsnamen… beginnen immer mit einem Kleinbuchstaben, i.d.R. mit einem Verb, gefolgt von einem Substantiv (z.B.drucke, leseAdresse), sie heißen • getAttributname, wenn nur ein Attributwert eines Objektes gelesen wird • setAttributname, wenn nur ein Attributwert eines Objektes gespeichert wird • isAttributname, wenn das Ergebnis nur wahr (true) oder falsch (false) sein kann (z.B. isVerheiratet, isVerschlossen)

6. Objektorientierter Entwurf (OOD)2. Stereotypen • Stereotypen lassen sich in drei Kategorien einteilen: • "dekorative Stereotypen" (zur Gestaltung), • "deskriptive Stereotypen" (als Verwendungszusammenhangsbeschreibung oder auch zur Kommentierung, z.B. «entity», «control»), • "restriktive Stereotypen" (für formale Einschränkungen, Restriktionen und Eigenschaftsexistenzen, z.B. «interface») • Die Klassen zur Datenverwaltung, zur Realisierung der Benutzeroberfläche und zur Kennzeichnung der Use case Aktoren werden häufig durch Stereotypen gekennzeichnet: z.B. mit «DB» (data base), «GUI» (graphical user interface) und «actor». • Stereotypen werden oft mit Eigenschaftswerten oder auch Bedingungen verwechselt, obwohl diese in geschweiften Klammern stehen (z. B. {abstract}). • Werkzeuge können vom Stereotyp abhängigen Code generieren, z.B. generiert der Stereotyp «persistent» verschiedene Datenbankbefehle. • Jedoch: Namenskonventionen ist eine bessere Methode als Einsatz von Stereotypen: statt «getter» bei den Operationen ist besser, dem Operationsnamen den Begriff get voranzustellen: z.B «getter» SeminarsTaken() --> getSeminarsTaken()

7. Objektorientierter Entwurf (OOD)3. Eigenschaftswerte (benutzerdefiniert) Einige Beispiele für Eigenschaftswerte (Bedingungen) in Klassendiagrammen:

8. Objektorientierter Entwurf (OOD)3. Eigenschaftswerte Beispiel für die Verwendung der Bedingungen {mandatory} und {dynamic} in einem Klassendiagramm Mit der Bedingung {dynamic} wird gesagt, daß ein Objekt seine Klasse zur Laufzeit ändern kann. Natürlich könnte man der obigen Objektreferenz ein Objekt einer anderen Subklasse zuweisen. Hier handelt es sich jedoch um ein und dasselbe Objekt. Durch die Bedingung {mandatory} wird bestimmt, daß ein Objekt einen bestimmten Typ aus einer Menge A von einigen dieser Subtypen haben muß. Für weiblich/männlich wird somit neben den Vererbungspfeilen eine Auswahl erzwungen. Für Kunde/Bibliothekar kann die Auswahl zur Laufzeit wechseln. (Natürlich kann man das Geschlecht auch mit Hilfe eines Attributs festlegen.)

9. Objektorientierter Entwurf (OOD)3. Eigenschaftswerte Fragen zur UML-Syntax Was sind Klassen, Objekte und Notizen? Was bedeuten die gestrichelten Linien? Was bedeuten die geschweiften Klammern? Wieviel Assoziationen sind vorh.?

10. Objektorientierter Entwurf (OOD)4. Container-Klassen • Definition von Container-Klassen • Verwaltet Menge von Objekten einer Klasse • Stellt Operationen bereit, um auf die verwalteten Objekte zuzugreifen • Ein Objekt der Container-Klasse wird als Container bezeichnet • Typische Container sind Felder (arrays) und Mengen (sets) • Namenskonvention • Plural des Klassennamens, u.U. gefolgt von dem Namen Container • Beispiel: Für die Fachkonzept-Klasse Kunde heißt die zugehörige Container-Klasse Kunden oder KundenContainer.

11. Objektorientierter Entwurf (OOD)4. Container-Klassen Beispiel für die Arbeitsweise einer Containerklasse

12. Objektorientierter Entwurf (OOD)5. Schnittstellen-Klassen • Definition von Schnittstellen-Klassen • Besteht nur aus Operationssignaturen und besitzt keine Operationsrümpfe und Attribute • Äquivalent zu einer Klasse, die keine Attribute und ausschließlich abstrakte Operationen besitzt • Verschiedene Klassen können dieselbe Schnittstelle unterschiedlich implementieren • Für die aufrufende Klasse ergibt sich dadurch keine Änderung, da Schnittstelle unverändert.

13. Objektorientierter Entwurf (OOD)5. Schnittstellen-Klassen • Beispiel einer Schnittstellen-Klasse • Schnittstellenname ist am Ende um ein großes I für Interface ergänzt. • Notation s.a. abstrakte Klassen.

14. Objektorientierter Entwurf (OOD)5. Schnittstellen-Klassen Vergleich zwischen Schnittstelle und abstrakter Klasse

15. Objektorientierter Entwurf (OOD) Beispiele für die Implementierung in Java: abstrakte Klasse, Interface-Klasse, Objekterzeugung. • Hinweis: Klassen können mit final gekennzeichnet werden • Dann keine Unterklassen ableitbar • Eine Klasse darf nicht gleichzeitig als abstract und als final deklariert sein. • abstract class Abstract1 • { public void operation1() {...} • public void operation2() {...} • public abstract void operation1(); • } • interface ClassInfo • { public String getClassName(); • } • class MyClass implements ClassInfo • { public String getClassName() { return "MyClass"; • } • ... • } Zaehler einZaehler; //Referenz einZaehler einZaehler = new Zaehler(); //Objekt der Klasse Zaehler erzeugen, auf das einZaehler verweist.

16. Objektorientierter Entwurf (OOD)6. Sichtbarkeit Sichtbarkeit für Attribute und Operationen

17. Objektorientierter Entwurf (OOD)7. Signatur der Operationen • Vervollständigen der Signatur der Operationen • OOD fordert für jede Operation eine vollständige Signatur (UML-Syntax), wobei die Merkmalsliste optional ist: • Sichtbarkeit Operation (Parameterliste): Ergebnistyp {Merkmalsliste} • Für jeden Parameter der Parameterliste gilt: • [in | out | inout] Name:Typ = Anfangswert • Name steht für den formalen Parameter (alphanumerische Zeichen, kleingeschrieben, Wortanfänge groß) • Mehrere Parameter in der Liste werden durch Kommata getrennt • Übergabeart: in = Eingabewerteparameter, inout = Eingabe-Referenzparameter, out = Ausgabe-Referenzparameter; Übergabeart ist auch optional • Typ (wie Attributtypen)

18. Objektorientierter Entwurf (OOD) Übung zur Sichtbarkeit und Namensvergabe bei Einsatz der Sprache Java • Wandeln Sie die Klasse Order aus der Analyse um in eine Klasse Order in OOD: • Berücksichtigen Sie die Namenskonventionen von OOD • Geben Sie die notwendigen Typbezeichnungen aus Java an: Date, int und Currency • Vervollständigen Sie die Operationssignatur, indem sie u.a. spezifizieren, daß die Steuerberechnung länderspezifisch erfolgen soll (country) • Tragen Sie die Sichtbarkeit ein, so daß auf alle Attribute nur von den Instanzen derselben Klasse zugegriffen werden kann und die Operationen in Java als protected programmiert werden sollen • Erweitern sie die Attributliste, so daß Sie die Steuern (Taxes) und die Gesamtkosten (Total) abspeichern können.

19. Objektorientierter Entwurf (OOD)8. Abstrakte Operationen • Definition von abstrakten Operationen in Klassen • Abstrakte Operationen werden verwendet, um für Unterklassen eine gemeinsame Schnittstelle zu definieren • Abstrakte Operation besteht nur aus der Signatur und besitzt keine Implementierung • Abstrakte Operationen dürfen nur in Klassen deklariert werden, die ebenfalls abstractsind und müssen in einer Unterklasse implementiert werden (Abstrakte Klassen werden durch den Eigenschaftswert {abstract} oder durch einen kursiv gesetzten Klassennamen markiert. Das Aussehen des Vererbungspfeils ändert sich nicht.) • Abstrakte Operationen dürfen nicht die Sichtbarkeit privatebesitzen

20. Objektorientierter Entwurf (OOD) Übung: Wandeln Sie bitte diese Java-Klasse um in eine OOD-Klasse: class Kreis { protected Punkt Mittelpunkt; protected int Radius; protected boolean istSichtbar; protectedstatic int Anzahl; //Klassenattribut public Kreis(){...} //Konstruktor 1 public Kreis(int x, int y) {...} //Konstruktor 2 publicabstract void zeichnen() public void verschieben (Punkt neu) {...} public void vergroessern (int faktor) {...} public void verkleinern (int faktor) {...} protected void loeschen() {...} public static int getAnzahl() {...} //Klassenoperation }.

21. Objektorientierter Entwurf (OOD)9. Navigation • Angabe der Navigation bei den Assoziationen • Assoziationen sind im Normalfall in beiden Richtungen navigierbar (d.h. werden auf beiden Seiten wie ein Attribut behandelt). • Im Entwurf wird festgelegt, ob Assoziationen uni- oder bidirektional (mit Hilfe von Zeigern) implementiert werden • Man spricht von der Navigation der Assoziation, d.h. in diesem Fall, daß Reifen die Methoden von Reifentyp aufrufen kann und nicht umgekehrt. Beispiel für eine unidirektionale Assoziation

22. Objektorientierter Entwurf (OOD)9. Navigation • Realisierung mittels Zeigern • Jede Richtung einer Assoziation kann mittels Zeigern zwischen Objekten realisiert werden • Dann kennt jedes Objekt seine assoziierten Objekte • Durch die Operationen muss sichergestellt werden, dass alle Verbindungen konsistent auf- und abgebaut werden • Eine Kardinalität von 0..1 oder 1 wird dabei durch einen einzelnen Zeiger realisiert • Beispiel in Java • Attribut derReifentyp enth. die Referenz • link als setter-Methode • getlink als getter-Methode class Reifen {protected Reifentyp derReifentyp; public void link(Reifentyp rtyp) { derReifentyp = rtyp; } public void unlink(Reifentyp rtyp) { ... derReifentyp = null; } public Reifentyp getlink() { return derReifentyp; } }

23. Objektorientierter Entwurf (OOD) • Liegt eine Kardinalität größer 1 vor, dann muss eine Menge von Zeigern gespeichert werden; wenn keine Ordnung der Assoziation definiert ist, dann können Container-Klassen wie Set, Bag etc. verwendet werden • Bsp. in Java (Assoziation mit Kardinalität > 1): • “(Reifen)” steht für die Typumwandlung; addElement, ... sind Methoden von Vector class Reifentyp { protected Vector ProduzierteReifen = new Vector(); //verwaltet eine Menge von Referenzen public void link(Reifen einReifen) { ProduzierteReifen.addElement(einReifen);} void unlink(Reifen einReifen) { ProduzierteReifen.removeElement(einReifen);} Reifen getlink(int pos) { Reifen einReifen; ... einReifen=(Reifen)ProduzierteReifen.elementAt(pos); return einReifen; } }.

24. Objektorientierter Entwurf (OOD)10. Vererbung • Prüfung, ob die Vererbung im Analysemodell richtig verwendet wurde: • optionale Bestandteilen sind keine Vererbung • Vorsicht bei Klassen, die nur ein einziges Objekt haben • Übung: Verbessern Sie die folgenden Beispiele:

25. Objektorientierter Entwurf (OOD)10. Vererbung • Polymorphismus • ermöglicht flexible und leicht änderbare Softwaresysteme zu entwickeln, indem gleiche Namen für gleichartige Operationen verwendet werden, die auf Objekten verschiedener Klassen auszuführen sind: • Der Sender muss nur wissen, dass ein Empfängerobjekt das gewünschte Verhalten besitzt • Er muss nicht wissen, zu welcher Klasse das Objekt gehört • Polymorphismus und spätes Binden (late binding) sind untrennbar verbunden • Ist zur Übersetzungszeit die Klasse des Objekts nicht bekannt, dann kann noch nicht bestimmt werden, welche Operation ausgeführt wird • Spätes Binden: Operation wird erst zur Ausführungszeit an ein bestimmtes Objekt gebunden

26. Objektorientierter Entwurf (OOD)10. Vererbung • Beispiel für Polymorphismus • Es wird ein Zeiger pGrafik deklariert: Grafikobjekt pGrafik; • Operationsaufruf pGrafik.zeichnen() kann unterschiedliche Wirkungsweisen besitzen: • Gilt pGrafik = new Kreis, dann wird die Operation Kreis.zeichnen() aktiviert • Gilt pGrafik = new Rechteck, dann wird Rechteck.zeichnen() ausgeführt • Erst zur Laufzeit wird bestimmt, ob der Zeiger pGrafik auf ein Kreis- oder Rechteck-Objekt zeigt.

27. Objektorientierter Entwurf (OOD)10. Vererbung Beispiel für die Implementierung in Java: Polymorphismus class Grafikobjekt { public void zeichnen(); ...} class Kreis extends Grafikobjekt { public void zeichnen(); ...} class Rechteck extends Grafikobjekt { public void zeichnen(); ...} Grafikobjekt eineGrafik; eineGrafik = new Kreis(); eineGrafik.zeichnen(); //zeichnet einen Kreis eineGrafik = new Rechteck(); eineGrafik.zeichnen(); //zeichnet ein Rechteck.

28. Objektorientierter Entwurf (OOD)10. Vererbung • Mehrfachvererbung • Da das Konzept der Mehrfachvererbung in Java nicht realisiert ist, muss die Mehrfachvererbung ggfs. eliminiert werden, z.B. durch die Aggregation von Rollen:

29. Objektorientierter Entwurf (OOD)10. Vererbung • Mehrfachvererbung • Eine andere Alternative für die Transformation der Mehrfachvererbung auf die Einfachvererbung ist das Abflachen der Hierarchie: • Bei Sprachen ohne Vererbung (z.B. ADA) muss die Vererbung vollständig eliminiert werden:

30. Objektorientierter Entwurf (OOD)10. Vererbung • Mehrfachvererbung in Java auch über Schnittstellen möglich (mit Einschränkung): • Konzept der Mehrfachvererbung ist in Java nicht realisiert • Als Ersatzmechanismus dienen die Schnittstellen (interfaces) • Können nur abstrakte Operationen und Konstanten weitergeben, nicht aber Attribute und Implementierungen von Operationen • Nicht mit der Mehrfachvererbung gleichzusetzen • class B1 { ...} • interface B2 { ...} • interface B3 { ...} • class D extends B1 implements B2, B3 • {...}.

31. Objektorientierter Entwurf (OOD)11. Pakete • Definition von Paketen • Pakete dienen dazu, (Modell-) Elemente – insbesondere Klassen – zu Gruppen zusammenzufassen und als Ganzes zu behandeln • Sie unterstützen die Darstellung von alternativen Entwürfen oder von Entwürfen für verschiedene Plattformen • Import-Funktion: in der Abb. importiert Paket2 das Paket1, d.h., dass Paket2 die public-Klasse Klasse1 sieht und für Paket3 die Klassen in Paket 1 und 2 unsichtbar sind, weil keine import-Beziehung besteht • Die UML definiert für Pakete eine Reihe von Standardstereotypen • subsystem: Das betreffende Paket modelliert ein unabhängiges Teilsystem • system: Das betreffende Paket repräsentiert das gesamte System

32. Objektorientierter Entwurf (OOD)12. Zustandsdiagramm • Konkretisierung der Zustandsdiagramme für Klassen (Lebenszyklus) • Lebenszyklen für OOD überarbeiten und mit den entsprechenden Operationen ergänzen • Jede Klasse mit einem Lebenszyklus erhält im Entwurf ein private-Attribut classStatIn diesem Attribut wird der aktuelle Zustand des Objekts gespeichert • Jede Operation, die im Lebenszyklus aufgeführt ist, muss dieses Attribut abfragen, bevor sie ihre Verarbeitung durchführt • Ist mit dieser Operation ein Zustandswechsel verbunden, dann muss sie das Zustandsattribut aktualisieren.

33. Objektorientierter Entwurf (OOD)12. Zustandsdiagramm • Konkretisierung der Zustandsdiagramme für Klassen (Lebenszyklus)

34. Objektorientierter Entwurf (OOD) • Beispiel für die Implementierung in Java: Zustandsautomat (einfache Realisierung) • In Java gibt es keinen benutzerdefinierbaren Aufzählungstyp • Die Zustände werden daher als ganzzahlige Konstanten definiert • class Schublade • { final static int OFFEN = 1; • final static int ZU_UNVERSCHLOSSEN = 2; • final static int ZU_VERSCHLOSSEN = 3; • private int classState; • public void oeffnen() • { if (classState == ZU_UNVERSCHLOSSEN) • classState = OFFEN; ... • } • }.

35. Objektorientierter Entwurf (OOD)Heuristiken und Metriken • Use Cases nicht zu granular, besser mit activity diagrams verfeinern: • kleines System (2-5 PJ Aufwand) hat 3-20 Use Cases • mittleres System (10-100 PJ Aufwand) hat 10 - 60 Use Cases • großes System (> 100 PJ Aufwand) hat hunderte von Use Cases • Anzahl der Instanzmethoden in einer Klasse • < 12 für eine Geschäftsklasse • < 25 für eine GUI-Klasse • Anzahl der Attribute in einer Klasse • < 3 für eine Geschäftsklasse • < 9 für eine GUI-Klasse • Anzahl der Klassenmethoden in einer Klasse • < 4 Klassenmethoden • < 20% der Instanzvariablen • Anzahl der Klassenvariablen in einer Klasse (vergleichbar mit Globalen) • < 3 Klassenvariablen

36. Objektorientierter Entwurf (OOD)Heuristiken und Metriken (für Vererbung und Aggregation) • Anzahl abstrakter Klassen: • 10% bis 15% aller Klassen sollten abstrakt sein • Anzahl der Gliederungsstufen bei einer Vererbungshierarchie • < 4, da sonst fast unmöglich ist zu testen • Anzahl überschriebener Methoden • < 3 Methoden sollten pro Klasse überschrieben werden • Anzahl zusätzlicher Methoden in einer Subklasse • > 1, um die Existenz der Klasse zu rechtfertigen • Anzahl der Ebenen bei einer Aggregationshierarchie • < 6 Ebenen, da Hierarchie sonst zu komplex

37. Objektorientierter Entwurf (OOD)Anhang: Lösungen der Übungen Seite 18

38. Objektorientierter Entwurf (OOD)Anhang: Lösungen der Übungen Seite 20 Kreis # Mittelpunkt: Punkt # Radius: int # istSichtbar: boolean # Anzahl: int + zeichnen() {abstract} + verschieben (neu:Punkt) + vergrößern (faktor:int) + verkleinern (faktor: int) # löschen() getAnzahl() : int

39. Objektorientierter Entwurf (OOD)Anhang: Lösungen der Übungen Seite 24: falsche Verwendung der Vererbung; statt dessen Objekte oder Aggregation