Objektorientierter Entwurf Grundlagen des Software Engineerings
Lernziele } Verstehen, wie der Softwareentwurf als Menge von interagierenden Objekten dargestellt werden kann, die ihren eigenen Zustand und ihre Handlungen verwalten } Die wichtigsten Aktivitäten eines allgemeinen objektorientierten Entwurfsprozesses kennen } Die verschiedenen Modelle verstehen, die verwendet werden, um einen objektorientierten Entwurf zu dokumentieren } Mit den Darstellungen dieser Modelle mit Hilfe der Unified Modeling Language (UML) vertraut sein Folie 193
Objektorientierter Entwicklungsprozess } Objektorientierte Analyse } } Entwicklung eines objektorientierten Modells des Problembereichs und der Anwendung Objekte im Modell stellen Entitäten und Vorgänge des zu lösenden Problems dar } Objektorientierter Entwurf } } Entwicklung eines objektorientierten Modells eines Softwaresystems um festgelegte Anforderungen zu implementieren Enge Beziehung zu Problembereichs-Objekten, aber Umformungen und Ergänzungen notwendig } Objektorientierte Programmierung } Umsetzung des Softwareentwurfs unter Verwendung einer objektorientierten Programmiersprache (stellt Konstrukte für Definition von Objektklassen und Laufzeitumgebung zur Objekterzeugung zur Verfügung) Folie 194
System aus wechselwirkenden Objekten Folie 195
Idealer OO-Entwicklungsprozess } Übergänge zwischen Entwicklungsstufe nahtlos } Gleiche Notation in den Entwicklungsstufen } Schritt zur nächsten Stufe beinhaltet Verfeinerung der vorhergehenden Stufe } Hinzufügen von Details zu den Objektklassen } Bildung neuer Objektklassen } Z.B. detaillierte Entwurfsentscheidung zur Darstellung von Daten erst bei der Implementierung Folie 196
Vorteile von OO-Systemen } Einfach(er) zu ändern da Objekte unabhängig sind } Objekte können als alleinstehende Entitäten angesehen werden } Veränderung der Objektimplementierung und Hinzufügen von Diensten sollte andere Systemobjekte nicht beeinflussen } Objekte entsprechen Dingen } Oft deutliche Zuordnung zwischen Entitäten der realen Welt und deren Steuerobjekten im System } Bessere Verständlichkeit und Wartbarkeit des Entwurfes } Objekte sind potenziell wiederverwendbare Komponenten (Kapselung von Zustand und Operationen) Folie 197
Objekte und Objektklassen (Definition) } Ein Objekt ist eine Entität. Es besitzt einen Zustand sowie eine definierte Menge von Handlungsmöglichkeiten (Operationen), die auf diesem Zustand aufsetzen. Der Zustand wird als Menge von Objektattributen dargestellt. Die Operationen dieses Objekts bieten anderen Objekten (Clients) ihre Dienste an, um z.b. Berechnungen auszuführen. } Objekte werden gemäß der Definition einer Objektklasse erzeugt. Eine solche Klassendefinition ist sowohl eine Typspezifikation als auch eine Vorlage für die Erstellung von Objekten und beinhaltet Deklarationen aller Attribute und Operationen, die einem Objekt dieser Klasse zugeordnet werden sollten. Folie 198
Eine Mitarbeiterobjektklasse in UML Folie 199
Kommunikation zwischen Objekten } In dienstbasierten Systemen } Austausch von Textnachrichten (z.b. XML) } Innerhalb eines Programmes } Methodenaufrufe } Synchrone vs. asynchrone (nebenläufige) Dienstanforderung Folie 200
Vererbungshierarchie von Objektklassen in UML Folie 201
Beziehungen zwischen Objekten unterschiedlicher Klassen } Sogenannte Assoziationen } Allgemeine Beziehungen } Zeigen an, dass ein Objektattribut ein assoziiertes Objekt ist } Zeigt an, dass die Implementierung einer Objektmethode vom assoziierten Objekt abhängt } Beispiel: Aggregation (beschreibt, wie sich ein Objekt aus anderen Objekten zusammensetzt) Folie 202
Assoziationsmodell Folie 203
Beispiel: Aggregationsobjekt, das einen Kurs darstellt Folie 204
Ablauf eines objektorientierten Entwurfs } Verstehen und Definieren des Kontextes und der Verwendungsmodelle für das System } Entwurf der Systemarchitektur } Bestimmung der wichtigsten Objekte im System } Entwicklung von Entwurfsmodellen } Spezifizieren von Objektschnittstellen Folie 205
Beispiel: Wetterberichtssystem } Ein Wetterberichtssystem dient der regelmäßigen Erzeugung von Wetterkarten mit Hilfe von Daten, die von entfernten, unbeaufsichtigten Wetterstationen und anderen Datenquellen wie Wetterbeobachtern, Ballons und Satelliten erfasst werden. Die Wetterstationen übertragen ihre Daten als Antwort auf die Anfrage eines Bereichscomputers an diesen Rechner. } Der Bereichscomputer prüft die erfassten Daten auf Gültigkeit und integriert Daten aus verschiedenen Quellen. Die integrierten Daten werden archiviert, und mit Hilfe der Archivdaten und einer digitalisierten Kartendatenbank wird ein Satz lokaler Wetterkarten erstellt. Die Karten können für den Vertrieb auf einem speziellen Kartendrucker gedruckt oder in einer Vielzahl verschiedener Formate angezeigt werden. Folie 206
Beispiel: Schichtenarchitektur für ein Wetterberichtssystem Folie 207
Systemkontext und Verwendungsmodelle } Der Systemkontext ist ein statisches Modell, das die anderen Systeme in dieser Umgebung beschreiben. } Darstellung mithilfe von Assoziationen } Einfaches Blockdiagramm / erweitert um Subsystemmodell } Das Verwendungsmodell eines Systems ist ein dynamisches Modell, das beschreibt, wie das System tatsächlich mit seiner Umwelt zusammenspielt. } Anwendungsfalldiagramm Folie 208
Subsysteme des Wetterberichtssystems Folie 209
Anwendungsfälle der Wetterstation Folie 210
Entwurf der Architektur der Wetterstation } Schnittstellenschicht } Datenerfassungsschicht } Messgeräteschicht Folie 211
Ansätze zum Bestimmung der Objektklassen } Grammatikalische Analyse } Objekte und Attribute sind Substantive, Vorgänge und Dienste Verben } Verwendung greifbarer Entitäten } Verwendung eines Verhaltensansatzes } Unterschiedliches Verhalten wird verschiedenen Systemteilen zugeordnet } Durch Szenarioanalyse Folie 212
Beispiele für Objektklassen im Wetterstationssystem Folie 213
Entwurfsmodelle } Statische Modelle } Beschreiben statische Systemstrukturen in Form von Objektklassen und ihren Beziehungen (z.b. Verallgemeinerungs-, Verwendet/Wird-verwendet-von- oder Kompositionsbeziehungen) } Dynamische Modelle } Beschreiben die dynamische Systemstruktur und zeigen das Zusammenspiel zwischen Systemobjekten (nicht Klassen!) } z.b. Abfolgen von Dienstanfragen durch Objekte, Art der Verbindung zwischen Systemzustand und Objektinteraktionen } UML bietet zwölf verschiedene statische und dynamische Modelle Folie 214
Beispiel: Systemmodelle für die Wetterstation } Subsystemmodelle } Objektgruppierungen in zusammenhängenden Subsystemen à } Abfolgemodelle } Zeigen Ablauf von Objektinteraktion (Sequenz- oder Kooperationsdiagramme) } Zustandsmodelle } Zeigen, wie Objekte Zustand bei Ereignis ändern Folie 215
Zustandsdiagramm } Die in das Zusammenspiel einbezogenen Objekte werden waagerecht angeordnet, mit einer senkrechten gestrichelten Linie unter jedem Objekt. } Die Zeit wird senkrecht dargestellt, was bedeutet, dass die Zeit abwärts entlang der gestrichelten Linie der Lebenslinie des Objekts fortschreitet. } Die Interaktion zwischen Objekten wird durch beschriftete Pfeile dargestellt die die senkrechten Linien verbinden. } Das schmale Rechteck entlang der Lebenslinie eines Objekts stellt die Zeit dar, für die das Objekt das steuernde Objekt im System ist. Folie 216
Sequenzdiagramm für Datensammlung Folie 217
Zustandsdiagramm für Wetterstation Folie 218
Spezifikation der Objektschnittstelle } In UML mit Klassendiagrammen dargestellt, wobei es keinen Attributabschnitt gibt. } Der UML-Stereotyp <interface> sollte im Namensteil enthalten sein Folie 219
Weiterentwicklung des Entwurfs Folie 220
Zwei-Wochenaufgabe } Für den Fall, dass Ihr Projekt als objektorientiertes System ungesetzt werden soll, führen sie den objektorientierten Entwurf durch. } Email mit dem Objektentwurf bis Mittwoch in zwei Wochen an Hagen.Hoepfner@uni-weimar.de Folie 221