Design - Enwurf Objekt/Klasse Attribut Operation Assoziationen Polymorphismus Vererbung Paket Szenario Zusatandsautomat

Basierend auf den Analyseergebnissen Softwarearchitektur festgelegen: - Schnittstellendefinitionen - Funktions- und Leistungsumfang der Komponenten Aufgabe des Entwurfs spezifische Anwendung auf einer Plattform unter den technischen Randbedingungen realisieren Entwufs und Implementierungsphasen sind eng miteinander verbunden, jede entworfene Klasse kann direkt implementiert werden. --> Programmiersprache festlegen

OOD-Modell OOD - Objektorientiertes Design - wird zu OOD-Modell, wenn die technische Lösung des zu realisierenden Systems mit grafischen und/oder textuellen Symbolen (UML) modelliert wird OOD Modell --> Spiegelbild des späteren Programms

Dreischichten Architektur Vorteil: einzelne Module ohne vollständige Aktualisierung des Systems austauschbar

Dreischichten Architektur

OOD-Modell statisches und dynamische Modell, wesentlich umfangreicher, als in der Analysephase. Statisches Modell alle Klassen beschreiben Pakete nicht nur zur Bildung von Teilsystemen, sondern auch zur Darstellung verschiedenen Schichten Dynamisches Modell sehr wichtig innerhalb des Entwurfs übersichtliche Beschreibung der komplexen Kommunikation der Objekte (mit Programmcode sehr schwer nachvollziehbar)

Objekt - Klasse Klassennamen immer mit Großbuchstaben beginnen Stereotypen zur Strukturierung Alle Klassen für die Benutzungsoberfläche Präfix UI (UserInterface) gefolgt von einem klassenbeschreibenden Substantiv (UIbutton)

Objekt - Klasse 'normale' Klasse Java: jede Klasse ist ein Datentyp Standard: im Paket sichtbar (nutzbar!) Modifier: public - Deklaration: global sichtbar (nutzbar!) final - Deklaration: keine Vererbung möglich abstract - Deklaration: siehe dort

Objekt - Klasse 'normale' Klasse Java: class Zaehler{ private int Zaehlerstand; public void inkrementieren() {...} public void initialisieren() public int getZaehlerstand() } public class Zaehler{}

Objekt - Klasse generische Klasse definieren eine Familie von Klassen ist eine Schablone zur Erzeugung von Klassen --> wieder verwertbarer Code Beschreibung der Klasse mit 1 - n Parametern (obligatorisch) Parameter bestehen immer aus Typ und Namen und werden mit Kommata getrennt Vorteil gegenüber Vererbung: kein typecast notwendig! Konzept z.Zt. in Java nicht umgestzt, soll mit JDK 1.5 Herbst 2003 kommen....

Objekt - Klasse generische Klasse Bsp C++ : template <class Element> class Warteschlange{ public: void anfügen(Element* i); void entnehmen(Element* i); ...; }; class Patient; class Pkw; ... Warteschlange<Patient> Wartezimmer; Warteschlange<Pkw> Stau;

Objekt - Klasse generische Klasse nie Oberklasse einer `normalen`Klasse, kann aber von Oberklasse abgeleitet werden Binden einer Klasse an eine generische Klasse: binding UML:<<bind>>

Objekt - Klasse Container Klasse Verwaltung von Objekten einer anderen Klasse (fehlte im Entwurf!) stellt Operationen bereit, um auf die zu verwaltenden Objekte zugreifen zu können Bsp: array, vector, ....

Objekt - Klasse Interfaces (Schnittstellen) Ausschnitte des vollständigen Verhalten einer Klasse Signaturen von Operationen (ohne Implementierung) Verwendung wie abstrakte Klasse keine Attribute (Java aber Konstanten: final Attribute) UML: <<interface>>+gestrichelter Vererbungspfeil

Objekt - Klasse Interfaces (Schnittstellen) Java: Deklaration: interface ClassInfo{ public abstract String getClassName(); } Nutzung: class MyClass implements ClassInfo{ public String getClassName(){ return „MyClass“;

Objekt - 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: Klassenname kursiv

Objekt - Klasse abstrakte Klassen Java: abstract class AbstClass1{ public void operation1(){} public abstract void operation2(){} }

Attribute Name an Konvention Programmiersprache anpassen UML immer Substantiv beginnend mit Kleinbuchstaben Erweiterung: Sichtbarkeiten (Verwendung) public sichtbar in allen Klassen UML: + protected sichtbar in der Klasse/Paket und allen Unterklassen/außerhalb des Pakets UML: # privat sichtbar in der Klasse UML: -

Attribute Java: class Kreis{ int radius = 10; static String form = „rund“; //Klassenattribute }

Operationen Name an Konvention Programmiersprache anpassen; UML immer Verb mit Kleinbuchstaben Name muss nicht eindeutig sein, er kann mehrfach vorkommen, muss sich dann aber in der Parameterliste unterscheiden --> overloading Erweiterung gegenüber Analyse: vollständige Signatur Name der Operation Namen und Typen aller Paramerter Ergebnistyp der Operation Sichtbarkeiten

Operationen Sichtbarkeiten Sichtbarkeiten (Aufruf) public sichtbar in allen Klassen UML: + protected sichtbar in der Klasse/Paket und allen Unterklassen/außerhalb des Pakets UML: # privat sichtbar in der Klasse UML: -

Operationen abstrakte/Klassen Operationen abstrakte Operationen bestehen auch in der Implementation nur aus der Signatur: abstract void zeichnen(); Klassenoperationen dürfen nur auf 'static' Elemente zugreifen sind implizit 'final', da sie nicht überschrieben werden können --> nie 'abstract‘ Summe aller Signaturen = Interface (Schnittstelle) der Klasse

Operationen class Kreis{ public void zeichnen(){...} protected void loeschen(){...} privat void verschieben(Punkt neu){...} public static int getAnzahl(){...} //Klassenoperation }

Assoziationen Unterscheiden: unidirektionaler und bidirektionaler Welche Klassen muss/soll auf was zugreifen. --> Navigation der Assoziation Validieren über Operationen

Assoziationen Sichtbarkeiten public sichtbar in allen Klassen UML: + Name Assoziation/Rolle protected sichtbar in der Klasse/Paket und allen Unterklassen/außerhalb des Pakets UML: # Name Assoziation/Rolle privat sichtbar in der Klasse UML: - Name Assoziation/Rolle

Assoziationen Umsetzung von Kardinalitäten: <=1 mit ‚einfachen‘ Klassen class Angestellter{ protected Abteilung arbeitetIn; public void link(Abteilung abt){ arbeitetIn = abt; } public void unlink(Abteilung abt){ arbeitetIn = null; public Abteilung getlink(){ return arbeitetIn;

>1 Container Klasse z.B. Vector: class Abteilung{ protected Vector mitarbeiter; //Verwaltung Referenzen public void link(Angesteller ang){ mitarbeiter.addElement(ang); } public void unlink( Angesteller ang ){ mitarbeiter.removeElement(ang); Angesteller getlink(int pos){ Angesteller ang; .... ang=(Angesteller)mitarbeiter.elementAt(pos); return ang; }}

Assoziationen Umsetzung von Aggregationen: es muss sichergestellt sein, dass eine Navigation vom Ganzen zu den Teilen möglich ist. Umsetzung von Kompositionen: es muss sichergestellt sein, dass eine Navigation vom Ganzen zu den Teilen möglich ist Operationen, die das Ganze betreffen, müssen sich auch auf die Teile auswirken

Polymorphismus gehört zu den wesentlichen Grundpfeilern der Objektorientierung Grundsätzlich gilt: Polymorphismus ermöglicht den gleichen Namen für gleichartige Operationen zu verwenden, die mit Objekten unterschiedlicher Klassen auszuführen sind. So wird erreicht, das dieselbe Botschaft an Objekte unterschiedlicher Klassen gesendet werden kann, die darauf auf ihre Weise unterschiedlich reagieren. Dieser Mechanismus ersetzt aufwendige switch-Anweisungen, bei denen je nach Objekttyp eine bestimmte Aktion ausgeführt wird.

Polymorphismus 'dynamische' oder 'späte Binden‘ zum Zeitpunkt der Übersetzung (kompilieren) noch nicht geklärt ist, welche Operation ausgeführt werden wird. Erst zur Laufzeit steht der Typ des Objektes fest und so wird das Objekt 'spät' an eine bestimmte Operation gebunden

abstract class Grafikobjekt{ public abstract void zeichnen(); ... } class Kreis extends Grafikobjekt{ public void zeichnen(); class Rechteck extends Grafikobjekt{ --------------------------------------------------------- Grafikobjekt eineGrafik; eineGrafik = new Kreis(); eineGrafik.zeichnen() //zeichnet einen Kreis eineGrafik = new Rechteck (); eineGrafik.zeichnen() //zeichnet ein Rechteck

Vererbung Oberklassen häufig abstrakten Klassen gemeinsame Eigenschaften und Operationen für die Unterklassen festlegen Einfach- oder Mehrfach? Einfachvererbung --> Struktur, in der jede Klasse (außer der Wurzel) genau eine Oberklasse besitzt. -->Baumstruktur

Vererbung Mehrfachvererbung --> Struktur, in der jede Klasse (außer der Wurzel) mehrere Oberklasse besitzen kann. azyklischer Graph Problem dabei: Klasse kann von ihren unterschiedlichen Oberklassen Attribute und Operationen erben, die namensgleich, aber unterschiedlichen Inhalts sind. Keine Beispiele, da in Java nicht erlaubt! Spaghetti Vererbung --> extrem unverständliche Strukturen

Vererbung Überschreiben Unterklasse implementiert eine signaturgleiche Operation der Oberklasse neu, sie überschreibt diese:

Überladen eine Klasse verfügt über mehrere namensgleiche Operationen, die sich aber in der Parameterliste unterscheiden.

Vererbung In Java: class Grafikobjekt{...} class Kreis extends Grafikobjekt{...} Mehrfachvererbung in Java grundsätzlich nicht möglich, aber: class B1{...} interface B2{...} interface B3{...} class X extends B1 implements B2, B3{...}

Pakete in der Analysephase nur zur Einteilung, im Enwurf wesentlich wichtiger: Klassen zu Gruppen zusammenfassen Darstellung verschiedener Entwürfe Bsp: für verschiedene Pattformen Pakete werden ineinander verschachtelt Paketinhalte Sichtbarkeitselemente

Pakete public sichtbar in allen Paketen, die das betreffende Paket importieren UML: + protected sichtbar in allen Paketen, die das betreffende Paket spezialisieren UML: # privat sichtbar nur im betreffende Paket UML: -

Pakete Importieren Beziehung zwischen zwei Paketen P2 importiert P1

Pakete Paketvariationen Vergleichbar mit der Klassen-Vererbung werden Paketvariationen dargestellt:

Pakete in Java Achtung: kein Standardpackage mehr! Erstellung eines Paketes: Unterverzeichnis im Projektverzeichnis anlegen, das den gleichen Namen trägt, wie das Paket Jede Klasse des Pakets als eigene Datei (beginnend mit package Paketname;) in dieses Verzeichnis legen Pakete importieren: import Paketname.*; importieren von einzelnen Klassen anderer Pakete: import Paketname.Klassenname.*;

Sequenzdiagramme nur geringe Erweiterungen gegenüber Analysephase: Operationsnamen durch genaue Parameterangaben erweitern Rückgabewerte von Operationen an den gestrichelten Rücklaufpfeil Extrem wichtig für die Übersicht über ein Programm: Das dynamische Verhalten wird nur in den Sequenzdiagrammen abgebildet und ist bei der Implementation für die Abfolge der Operationsaufrufe enorm wichtig, kann aber nicht direkt in Code übersetzt werden

Zustandsautomaten im Entwurf oft sinnvoll für die Modellierung der Benutzungsoberfläche liefert präziese Vorgaben für die Programmierung.

Zustandsautomaten Beispiel Manipulation eines Dokumentes mit der Maus:

Zustandsautomaten zusätzliche nicht triviale Lebenszyklen im Enwurf werden nicht direkt in eine Programmiersprache übersetzt, sondern liefern folgende Informationen: jede involvierte Klasse erhält zur Feststellung des aktuellen Zustandes folgendes Attribut: private classState jede involvierte Operation muss als erstes dieses Attribut abfragen und bei Zustandsänderungen das Attribut anpassen Lebenszyklus Klassen müssen Operation zur Verfügung stellen, die aufgrund des aktuellen Zustandes eines Objektes, die entsprechende Verarbeitungsschritte auslöst: wenn im Zustand1, dann bearbeiten1(), wenn im Zustand2, dann bearbeiten2()