Objektmodellierung Objekte und Klassen Ein Objekt ist ein

Objektmodellierung Objekte und Klassen • Ein Objekt ist ein Exemplar (Instanz) eines Gegenstandes oder Begriffs der Modellwelt; ein Objekt ist möglichst stark an Gegenstand oder Begriff der realen Welt angelehnt. • Ein Objekt hat – eine Identität, z. B. vom Benutzer vergebene Namen. – einen Zustand, definiert durch private Daten (Werte für Attribute), – ein Verhalten, spezifiziert durch eine Menge von Operationen (Methoden), die auf den privaten Daten agieren und Operationen anderer Objekte aufrufen können; – Beziehungen (Relationen) zu anderen Objekten. Prof. Dr. Gerhard Schmidt pres. by H. -J. Steffens Software Engineering SS 2009 1

Objektmodellierung • Unterscheidung in – passives Objekt • vergleichbar mit einem Datenobjekt; • Ausführung einer Methode geschieht nur auf Anforderung eines anderen Objekts; • hat kein eigenständiges Leben, d. h. dem Objekt ist kein Prozess zugeordnet. – aktives Objekt • Objekt hat zusätzlich einen Prozess zugeordnet, der die Ausführung der Methoden übernimmt; • Objekt beinhaltet einen eigenen Steuerfluss (thread). Dieser Prozeß muß stattfinden, während das aktive Objekt existiert. Prof. Dr. Gerhard Schmidt pres. by H. -J. Steffens Software Engineering SS 2009 2

Objektmodellierung • Klasse – Objekte mit gleichem Verhalten werden zu Klassen zusammengefasst. Ein Objekt "weiß", zu welcher Klasse es gehört. – Klassenattribute und –operationen beziehen sich nicht auf einzelnes Objekt, sondern auf die gesamte Klasse. • Attribut: Datenwert, den Objekte oder Klassen enthalten. • Operationen: Funktionen, die auf Objekte oder von Objekten anderer Klassen angewendet werden können. • Methode: Implementierung einer Operation; • Polymorphie: Implementierung von Methoden mit gleichem Namen, aber unterschiedlichen Parametern. Prof. Dr. Gerhard Schmidt pres. by H. -J. Steffens Software Engineering SS 2009 3

Objektmodellierung • Zugriffsrestriktionen – private: nur sichtbar und damit zugreif- und aufrufbar für die Klasse selbst – protected: nur sichtbar und damit zugreif- und aufrufbar für die Klasse selbst und für abgeleitete Klassen – public: für alle sichtbar und damit zugreif- und aufrufbar Prof. Dr. Gerhard Schmidt pres. by H. -J. Steffens Software Engineering SS 2009 4

Objektmodellierung • Beispiel: Klassendefinition public class circle { public double x, y; // Koordinaten der Kreismitte public double r; //Radius des Kreises // Konstruktor für die Erzeugung von Objekten public circle (double x-coord, double y-coord, double radius) {x = x-coord; y = y-coord; r = radius; } // Methoden, die Umfang und die Fläche als Ergebnis liefern public double umfang(){return 2 * 3. 14159 * r; } public double flaeche(){return 3. 14159 * r; } } Prof. Dr. Gerhard Schmidt pres. by H. -J. Steffens Software Engineering SS 2009 5

Objektmodellierung • Vorgehen bei der Modellierung – – – Identifikation von Klassen und Objekten Jede Klasse durch ein paar Sätze beschreiben; Attribute hinzufügen Kombination und Organisation der Klassen durch Vererbung Kandidaten für Objektklasse identifizieren ungeeignete Kandidaten entfernen, z. B. : • redundante, • irrelevante, • vage Klassen – CRC-Karten verwenden Prof. Dr. Gerhard Schmidt pres. by H. -J. Steffens Software Engineering SS 2009 6

Objektmodellierung • Motivation – – – einfach informell schnelle Ergebnisse durch Gruppendynamik flexibel Fördern das Verständnis des Modells • Definition: CRC: – Class (Klasse) – Responsibility (Verantwortung) – Collaboration (Zusammenarbeit) • Indizierte Karteikarte, die eine Klasse beschreibt – eindeutiger Klassenname – Liste aller Tätigkeiten, für diese Klasse verantwortlich ist – Liste aller Klassen, mit denen eine Zusammenarbeit stattfindet bzw. diese Klasse benötigt, um die eigenen Aufgaben erfüllen zu können. Prof. Dr. Gerhard Schmidt pres. by H. -J. Steffens Software Engineering SS 2009 7

Objektmodellierung • Syntax: – keine allgemein akzeptierte Syntax – notwendige Elemente: • Klassennname • Anzahl von Tätigkeiten, diese Klasse ausführt • Anzahl von Klassennname, mit denen die Klasse zusammenarbeitet – Grundmodell: • oberste Zeile: Klassenname • darunter: – abgeleitete Klasse – übergeordnete Klassen • Rest ist aufgeteilt in linke und rechte Seite – links: verantwortliche Tätigkeiten – rechts: Namen der Klassen, mit denen zusammengearbeitet wird Prof. Dr. Gerhard Schmidt pres. by H. -J. Steffens Software Engineering SS 2009 8

Objektmodellierung • Klassennamen bilden Vokabular, das zu lösende Problem hinreichend genau beschreibt. • Gut gewählte Klassennamen erhöhen das Verständnis für das Modell. • Liste der verantwortlichen Tätigkeiten dieser Klasse stellt Fähigkeiten und Service dieser Klasse dar den diese Klasse Anwendern bietet. • Die Bezeichnungen der verantwortlichen Tätigkeiten sollten immer kurz aber auch beschreibend sein und immer ein aktives Verb enthalten: – Sucht. Einträge – Kennt. Kontostand • Bezeichnungen der Klassen deren Zusammenarbeit eine Tätigkeit benötigt, werden genau gegenüber der Bezeichnung der Tätigkeit eingetragen. Dabei können dieselben Klassen mehrmals auf der Karteikarte auftreten. Prof. Dr. Gerhard Schmidt pres. by H. -J. Steffens Software Engineering SS 2009 9

Objektmodellierung Verknüpfungen und Assoziationen • Assoziation gehört zu zwei Klassen • Assoziation ist grundsätzlich bidirektional • Darstellung durch eine Linie zwischen den Klassen bzw. Objekten • Multiplizität: Anzahl der Instanzen einer Klasse, die mit der Instanz einer assoziierten Klasse verbunden sein können, z. B. – – – 1 0, 1 n. . * n. . m n, m Prof. Dr. Gerhard Schmidt pres. by H. -J. Steffens genau 1 0 oder 1 >= n, <= m genau n oder m Software Engineering SS 2009 10

Objektmodellierung • Assoziationen bestimmen – Kandidaten für Assoziationen identifizieren • Abhängigkeiten zwischen 2 oder mehreren Klassen aus Problemwissen oder Annahmen • Verweise von einer Klasse zu einer anderen – ungeeignete Kandidaten entfernen, z. B. • Assoziationen zwischen eliminierten Klassen • irrelevante Assoziationen • Assoziationen zwischen mehr als 2 Klassen (soweit möglich durch binäre darstellen) – abgeleitete Assoziationen • aus mehreren Assoziationen erzeugbar Prof. Dr. Gerhard Schmidt pres. by H. -J. Steffens Software Engineering SS 2009 11

Objektmodellierung • Aggregation – spezielle Assoziation, die „Teil – Ganzes“-Relation repräsentiert – Beispiel: PC, besteht aus • Bildschirm • Rechner, besteht aus – Gehäuse – CPU – RAM • Maus • Tastatur Prof. Dr. Gerhard Schmidt pres. by H. -J. Steffens Software Engineering SS 2009 12

Objektmodellierung • Komposition – spezielle Form der Aggregation – Teile existieren nicht unabhängig vom Ganzen – Beispiel: Rechnung, besteht aus • Rechnungsposition 1 • Rechnungsposition 2 • . . . Prof. Dr. Gerhard Schmidt pres. by H. -J. Steffens Software Engineering SS 2009 13

Objektmodellierung Generalisierung und Vererbung • dient dazu – Ähnlichkeiten verschiedener Klassen herauszufinden – Unterschiede verschiedener Klassen zu erhalten • gemeinsame Attribute und Methoden werden in einer Oberklasse zusammengefasst • Spezielle Details werden in Unterklassen berücksichtigt • Unterklassen erben Attribute und Methoden der Oberklasse • Instanz der Oberklasse ist gleichzeitig Instanz all ihrer Oberklassen • Unterklasse kann Methode der Oberklasse überschreiben, dient – der Verfeinerung – der Effizienzsteigerung • Parameter und Ergebnistypen dürfen nicht geändert werden Prof. Dr. Gerhard Schmidt pres. by H. -J. Steffens Software Engineering SS 2009 14

Objektmodellierung Abstrakte Klassen • hat keine direkten Instanzen; • dienen als Oberklasse für konkrete Klasse; • Methodendeklarationen werden festgelegt, Definition erfolgt in konkreter Klasse • konkrete Klasse ist instanzierbar; Prof. Dr. Gerhard Schmidt pres. by H. -J. Steffens Software Engineering SS 2009 15

Objektmodellierung • Bestimmung von Attributen – Kandidaten identifizieren • Substantive mit Genitiv • Wissen aus Anwendungsbereich – ungeeignete Kandidaten entfernen, z. B. • • • Objekte Qualifikationsangaben Identifikatoren Verknüpfungsattribute interne Zustände, die außen nicht sichtbar sind Details, die sich auf die meisten Operationen nicht auswirken Prof. Dr. Gerhard Schmidt pres. by H. -J. Steffens Software Engineering SS 2009 16

Objektmodellierung Überarbeiten des Objektmodells • Zugriffspfade testen • Gibt es für einen erwarteten eindeutigen Wert einen Pfad, der eindeutiges Ergebnis liefert? • Gibt es bei m-Multiplizitäten die Möglichkeit, eindeutige Werte herauszugreifen? • Gibt es sinnvolle Fragen, die nicht beantwortet werden können? • Doppelte Assoziationen den Oberklassen übertragen • Unterscheidung Objekt und komplexes Attribut Prof. Dr. Gerhard Schmidt pres. by H. -J. Steffens Software Engineering SS 2009 17

Dynamisches Modellieren • Aspekte eines Systems, die mit Zeit und Veränderungen zu tun haben, bilden das dynamische Modell • Gegensatz zum statischen oder Objektmodell • Ereignisse spielen zentrale Rolle, z. B. : – – – Signale Eingabe Entscheidungen Unterbrechungen Aktionen an oder von externen Objekten Prof. Dr. Gerhard Schmidt pres. by H. -J. Steffens Software Engineering SS 2009 18

Dynamisches Modellieren • Szenarien – Szenario: Folge von Ereignissen, die bei einer ganz bestimmten Ausführung eines Systems auftritt – Sequenzdiagramm stellt zusätzlich Sender- und Empfängerobjekte für jedes Ereignis dar Prof. Dr. Gerhard Schmidt pres. by H. -J. Steffens Software Engineering SS 2009 19

Dynamisches Modellieren • Szenarien erstellen: – Aufschreiben von typischen Dialogen zwischen Benutzer und System – Reihenfolge beachten: • • Normalfälle, keine ungewünschten Eingaben, keine Fehler Berücksichtigung von Sonderfällen Berücksichtigung von Benutzerfehlern zusätzliche Interaktionsarten – Für jedes Ereignis wird notiert: • das verursachende Objekt • Parameter – Jedes Szenario wird als Sequenzdiagramm dargestellt Prof. Dr. Gerhard Schmidt pres. by H. -J. Steffens Software Engineering SS 2009 20