Objektorientierter Entwurf

1. Objektorientierter Entwurf Wdh.: Basiskonzepte innerhalb des OOD Statische Konzepte im Entwurf: Assoziationen

3. OOD-Modell • Soll das spätere Programm widerspiegeln; aber: höhere Abstraktionsebene, Verdeutlichung des Zusammenwirkens einzelner Elemente • Erstellen eines statischen und dynamischen Modells/ Elaboration des bereits bestehenden OOA-Modell

4. Klasse Allgemein: Notation Name: Wie in der Analyse fett und zentriert, beginnend mit Großbuchstabe • Stereotypen verwenden, um Zugehörigkeit einer Klasse zu einer bestimmten Entwurfsschicht zu zeigen: <<interface>>, <<database>>, … Person <<interface>> UIButton

5. Klasse Parametrisierte Klasse (Template): Die parametrisierte Klasse Queue enthält ein Attribut queue, das mit Hilfe des Typs T und der Multiplizität [0..n] definiert wird; in den beiden Klassen, die Queue als Vorlage benutzen, wird dann Typ und Anzahl der maximalen Werte/Objekte bestimmt Queue queue: T[0..n] insert() delete() <<bind>> <Tfloat,n100> <<bind>> <TPerson,n100> FloatQueue Adressbuch

6. Klasse Container-Klasse • Verwaltung von Objekten einer anderen Klasse • stellt Operationen bereit, um auf die zu verwaltenden Objekte zugreifen zu können • Vordefiniert in Bibliotheken (z.B. C++  STL)

7. Implementierung C++: template <class ElementType, int max> class Queue{ public: void insert(ElementType element) {...} }; typedef Queue<int,100> IntQueue; typedef Queue<string,100> StringQueue; IntQueue intQueue; StringQueue strQueue; strQueue.insert(„Meier"); intQueue.insert(5);

8. Klasse Schnittstelle (Interface) • Enthält Signaturen von Operationen (immer abstrakt) und evtl. Attribute • Verwendung wie abstrakte Klasse • Schlüsselwort <<interface>>

9. Beispiel:

10. Schnittstelle : Implementierung Java: Deklaration: interface ClassInfo{ public abstract String getClassName(); } Nutzung: class MyClass implements ClassInfo{ public String getClassName(){ return „MyClass“; } } C++: Mittels Klassenkonzept

11. Klasse Abstrakte Klassen • Oberklasse zu „realen“ Klassen • kann keine Objekte erzeugen • jede Klasse, die eine mit abstract gekennzeichnete Operation enthält muss ebenfalls abstract sein • UML: Oder: Medium Medium {abstract} erfasse() erfasse() {abstract}

12. Implementierung Java: - Kennzeichnung mittels „abstract“ - Eine Klasse, die eine abstrakte Operation besitzt, muss als abstrakt deklariert sein abstract class AbstClass1{ public void operation1(){} public abstract void operation2(){} } C++: - Keine spezielle Kennzeichnung

13. Attribute • UML erlaubt alle Zeichen im Attributnamen Name an Konvention Programmiersprache anpassen; beginnend mit Kleinbuchstaben • Sichtbarkeiten public sichtbar in allen Klassen UML: + protected sichtbar in der Klasse und allen Unterklassen UML: # private sichtbar in der Klasse UML: - package sichtbar für alle Klasse im gleichen Paket UML:~

14. Attribute Notation: Sichtbarkeit / name : Typ [Multiplizität] = Anfangswert {Eigenschaftswert} - Nur der Name des Attributs ist zwingend anzugeben; Standard: Sichtbarkeit, Name, Typ

15. Attribute Eigenschaftswerte: • UML bietet eine Reihe von vordefinierten Eigenschaftswerten, wie z.B.: {read only}  Attributwert unveränderbar {ordered}  Menge von Werten, geordnet ( vorname[1..3] {ordered} ) • Weitere Eigenschaftswerte dürfen nach Belieben definiert werden (ebenso Einschränkungen) rueckflug: Date {rueckflug > hinflug}

16. Attribute • Typen: UML erlaubt neben vordefinierten Typen die Definition beliebiger weiterer Typen  Typen der Programmiersprache, die verwendet werden soll, benutzen. • Abgeleitete Attribute: Abgeleitete Attribute ins OOD- Modell eintragen. Sie werden später als Attribute oder durch eine Operation realisiert, die den aktuellen Wert des abgeleiteten Attributs ermittelt.

17. Operationen • Name: beliebig, sollte mit Kleinbuchstaben beginnen; auch hier: Syntax der verwendeten Programmiersprache zu Grunde legen • Überladen von Operationen: Im OOD darf derselbe Operationsnamen innerhalb einer Klasse mehrfach vorkommen, allerdings mit verschiedenen Parametern

18. Operation Sichtbarkeiten : • public sichtbar in allen Klassen UML: + • protected sichtbar in der Klasse und in allen Unterklassen UML: # • privat sichtbar in der Klasse UML: - • package sichtbar im selben Paket UML: ~

19. Operationen • Signatur: Im OOD-Modell vollständig anzugeben Spezifikation: Sichtbarkeit name (Parameterliste) : Ergebnistyp {Eigenschaftswert} Für die Parameterliste gilt: Richtung parametername : Typ [Multiplizität] = Anfangswert {Eigenschaftswert} Auch hier ist nur die Angabe des Namens zwingend.

20. Operation Signatur: Richtung • in : bei reinen Eingabeparametern; nur lesender Zugriff der Operation möglich z.B. erfassen(in name: string) • out : bei reinen Ausgabeparametern; Operation erzeugt den Wert des Parameters und gibt ihn an die aufrufende Funktion zurück • inout : lesen, verändern, zurückgeben

21. Operation • Eigenschaftswerte: Analog zu Attributen gibt es in UML vordefinierte und die Möglichkeit, eigene zu definieren

22. Operation • Für abstrakte Operationen gilt dasselbe wie für abstrakte Klassen: - sie besteht nur aus der Signatur (ohne Wertangabe im OOD / ohne „aktive“ Implementierung) - sie werden im Rahmen von Generalisierungsstrukturen ins OOD-Modell eingetragen - UML: kursiv oder {abstract} - in Schnittstellen sind Operationen immer abstrakt und müssen nicht gesondert als abstrakt gekennzeichnet werden

23. Beispiel

24. Operation Erweiterung gegenüber Analyse: • vollständige Signatur • Namen und Typen aller Parameter • Ergebnistyp der Operation • Sichtbarkeiten

25. Assoziation Assoziationen im OOA-Modell • Welche Klassen kennen sich, zwischen welchen Objekten existieren Beziehungen? • Binäre Assoziationen • Multiplizitäten • Benennung/ Rolle

26. Assoziation Navigierbarkeit KlasseX KlasseY unspezifiziert KlasseX KlasseY unidirektional KlasseX KlasseY bidirektional Navigierbarkeit explizit ausgeschlossen KlasseX KlasseY  Navigierbarkeit kann auch in Objektdiagramme eingetragen werden

27. Assoziation • Implementierung • Mittels Zeigern • Multiplizität 0..1 oder 1: ein einzelner Zeiger • >1: Menge von Zeigern • * : Container • Beispiel Java: • class Angestellter • { • protected Abteilung arbeitetIn; • public void link(Abteilung abt) • {arbeitetIn=abt;} • public void unlink(Abteilung abt) • {... arbeitetIn=null;} • public Abteilung getlink() • {return arbeitetIn;} • }

28. Assoziation • Sichtbarkeit • Die Sichtbarkeit einer Assoziation kann im Entwurfsmodell eingetragen werden. • z.B.: • Eigenschaftswert • z.B.: KlasseX KlasseY + rolle passenger Flugzeug Fluggast {union} first {subset passenger} business {subset passenger} * {ordered}

29. Assoziation

30. Assoziation

31. Übung 1 • Ziel: Klassen und Assoziationen des OOA-Modells in den Entwurf abbilden. Aus einem Analysemodell resultiert folgendes Klassendiagramm: Student Firma matrikelnummer name immatrikulation anzahl name ort branche * 0..1 praktikant immatrikulieren() anmeldenPraktikum() erstelleListe() Entwickeln Sie dieses Diagramm als Teil des Entwurfsmodells weiter.

32. Komponentendiagramm • Wie ist die Struktur des Systems, wie wird sie erzeugt? • Komponente: Softwarebaustein, der über feste Schnittstellen verfügt, wobei das Innenleben der Komponente modifiziert werden kann  Vorteil: Austauschbarkeit • Komponentenbasierte Entwicklung: z.B. .NET, JavaBeans

33. Komponentendiagramm • Notation: Komponente und Schnittstelle <<component>> Komponente Komponente

34. Komponentendiagramm • Alternative Darstellung

35. Komponentendiagramm • Die einzelnen Komponenten sind über ihre Schnittstellen miteinander verbunden: <<component>> KomponenteB <<component>> KomponenteA <<component>> KomponenteC

36. Komponentendiagramm • Artefakte Artefakte sind physische Informationseinheiten, z.B. eine Quellcodedatei oder eine ausführbare Binärdatei Die Art des Artefakts kann durch Stereotypen spezifiziert sein: <<file>> =Datei <<document>> =Datei, die weder Quellcode noch ausführbaren Programmcode besitzt <<source>> =Datei mit Quellcode <<executable>> = ausführbare Datei <<library>> =Datei, die Bibliothek enthält (z.B. dll- Datei) <<artefact>> ArtefaktX

37. Komponentendiagramm Abhängigkeiten zwischen Artefakten und Komponenten Artefakt1 wird durch Komponente realisiert Keine näher spezifizierte Abhängigkeit Class-Datei wird automatisiert aus Java-Datei erstellt OOD-Modell wird aus OOA-Modell erstellt

38. Komponentendiagramm • Darstellung des Innenlebens einer Komponente

39. Komponentendiagramm Klasse Fahrzeug ist Exemplar der Klasse Fahrzeugtyp Kunden-Window besitzt Zugriffsrechte auf Klasse Kunde OOD-Klasse Kunde realisiert OOA-Klasse Kunde EditierbareListe ist durch Klasse Liste ersetzbar Klasse Bestellung benötigt für volle Funktionalität Artikel • Abhängigkeiten zwischen Modellelementen

40. Übung 2 Ziel: Komponentendiagramm erstellen Erstellen Sie ein Komponentendiagramm mit den folgenden Komponenten und den jeweils angegebenen Schnittstellen, die diese Komponenten zur Verfügung stellen und benutzen: - Online-Reservierung: benutzt Reservierung - Zimmerbelegung: bietet Zimmeranfrage und Buchung - Preisberechnung: bietet Preisliste und Sonderangebote - Zimmerreservierung: bietet Stornierung und Reservierung, benutzt Zimmeranfrage, Buchung, Preisliste und Sonderangebote.