Objektorientierter Entwurf. Grundlagen des Software Engineerings

Transkript

1 Objektorientierter Entwurf Grundlagen des Software Engineerings

2 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

3 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

4 System aus wechselwirkenden Objekten Folie 195

5 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

6 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

7 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

8 Eine Mitarbeiterobjektklasse in UML Folie 199

9 Kommunikation zwischen Objekten } In dienstbasierten Systemen } Austausch von Textnachrichten (z.b. XML) } Innerhalb eines Programmes } Methodenaufrufe } Synchrone vs. asynchrone (nebenläufige) Dienstanforderung Folie 200

10 Vererbungshierarchie von Objektklassen in UML Folie 201

11 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

12 Assoziationsmodell Folie 203

13 Beispiel: Aggregationsobjekt, das einen Kurs darstellt Folie 204

14 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

15 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

16 Beispiel: Schichtenarchitektur für ein Wetterberichtssystem Folie 207

17 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

18 Subsysteme des Wetterberichtssystems Folie 209

19 Anwendungsfälle der Wetterstation Folie 210

20 Entwurf der Architektur der Wetterstation } Schnittstellenschicht } Datenerfassungsschicht } Messgeräteschicht Folie 211

21 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

22 Beispiele für Objektklassen im Wetterstationssystem Folie 213

23 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

24 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

25 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

26 Sequenzdiagramm für Datensammlung Folie 217

27 Zustandsdiagramm für Wetterstation Folie 218

28 Spezifikation der Objektschnittstelle } In UML mit Klassendiagrammen dargestellt, wobei es keinen Attributabschnitt gibt. } Der UML-Stereotyp <interface> sollte im Namensteil enthalten sein Folie 219

29 Weiterentwicklung des Entwurfs Folie 220

30 Zwei-Wochenaufgabe } Für den Fall, dass Ihr Projekt als objektorientiertes System ungesetzt werden soll, führen sie den objektorientierten Entwurf durch. } mit dem Objektentwurf bis Mittwoch in zwei Wochen an Hagen.Hoepfner@uni-weimar.de Folie 221