Objektorientierte Analyse und Design

Objektorientierte Analyse und Design (OOAD) sind objektorientierte Varianten der zwei allgemeinen Tätigkeiten Anforderungsanalyse (objektorientierte Analyse) und Systementwurf (objektorientiertes Design) im Entwicklungsprozess eines Softwaresystems.

Dadurch, dass in den Entwicklungsphasen Analyse und Design bereits objektorientierte Techniken eingesetzt werden, wird der Übergang zur Implementierung in einer objektorientierten Programmiersprache erleichtert.

Als Standardnotation für objektorientierte Modelle hat sich die Unified Modeling Language (kurz UML) etabliert. Ein Vorgehensmodell, das speziell für objektorientierte Techniken und die UML entwickelt wurde, ist der sogenannte Rational Unified Process (RUP).

In der Analyse geht es darum, die Anforderungen zu erfassen und zu beschreiben, die das zu entwickelnde Softwaresystem erfüllen soll. In dieser Phase werden alle Fakten gesammelt, dargestellt und überprüft. Dies kann in Form eines textuellen Pflichtenheftes oder einer Software Requirements Specification geschehen. Ergebnis der Analyse ist ein allgemeines Produktmodell in Form eines objektorientierten Analyse-Modells (OOA-Modell). Diese fachliche Beschreibung mit objektorientierten Konzepten enthält verschiedene Artefakte wie Diagramme und Darstellungen von Kontrollstrukturen.

Beim objektorientierten Design wird das in der Analyse erstellte Domänenmodell weiterentwickelt und darauf aufbauend ein Systementwurf erstellt. Dabei wird das allgemeine Modell in eine konkrete Softwarearchitektur umgeformt, die Informationen über Details der technischen Umsetzung enthält und direkt als Vorlage für die Implementierung in einer Programmiersprache dient, die idealerweise objektorientierte Programmierung (OOP) unterstützt.

Vorgehensmodelle zur Softwareentwicklung

Wesentliche Aufgabe der Projektorganisation ist es, für ein konkretes Softwareprojekt einen geeigneten Entwicklungsprozess zu definieren und diesen entsprechend umzusetzen.Christian Aichele, Marius Schönberger: IT-Projektmanagement. Effiziente Einführung in das Management von Projekten. Springer, Wiesbaden 2014, S. 29; Manfred Broy, Marco Kuhrmann: Projektorganisation und Management im Software Engineering. Springer, Berlin 2013, S. 85. Ein Vorgehensmodell zur Softwareentwicklung dient dazu, diese übersichtlich und in der Komplexität beherrschbar zu machen. Bei allen Vorgehensmodellen geht es darum, neben der Abgrenzung der Phasen voneinander, die Umwandlung eines Konzeptes (bzw. eine Produktspezifikation) in ein lauffähiges Softwareprodukt zu realisieren.

mini|Das Wasserfallmodell Vorgehensmodelle spalten somit einzelne Aktivitäten auf verschiedene Phasen im Entwicklungsprozess auf. Diese werden dann – u. U. mit geringen Modifikationen – einmal (z. B. Wasserfallmodell) oder mehrmals durchlaufen (z. B. Spiralmodell). Bei mehrmaligen Durchläufen erfolgt eine iterative (d. h. wiederholte) Verfeinerung der einzelnen Softwarekomponenten. Um die optimalen Vorgehensmodelle herrscht Uneinigkeit. In der Regel unterscheiden sie beim Entwicklungsprozess mindestens zwei große Tätigkeitsgruppen: die (von der programmiertechnischen Realisierung unabhängige) Analyse von Geschäftsprozessen (Geschäftsprozessmodell und Datenmodell) einerseits und die EDV-technische Realisierung (Design und Programmierung) andererseits.

Seit Beginn der 1980er-Jahre nehmen die Bedeutung und die Anzahl der objektorientierten Analyse- und Entwurfsmethoden ständig zu. Bei diesen werden die Ergebnisse der Phasen Analyse, Design und Implementierung objektorientiert erstellt. Für letzteren werden objektorientierte Programmiersprachen verwendet. Dadurch, dass in all diesen Phasen dieselben Techniken verwendet werden, wird eine bessere Durchgängigkeit bei den objektorientierten Techniken erreicht. In Analyse und Design wird sogar dieselbe Notation eingesetzt. Beim Übergang von der objektorientierten Analyse zum objektorientierten Design tritt somit kein Strukturbruch auf.Heide Balzert: Lehrbuch der Objektmodellierung. Analyse und Entwurf. Spektrum, Heidelberg / Berlin 1999, S. 2. Einer der ersten Ansätze zur Modellierung der Anforderungen an Systeme war „Object-Oriented Analysis“ (OOA) von Peter Coad und Edward Yourdon.Peter Coad, Edward Yourdon: Object-Oriented Analysis. 2. Auflage. Englewood Cliffs, NY, 1990. „Object-Oriented Design“ (OOD) schließt direkt daran an und behandelt den Übergang zum Entwurf.Peter Coad, Edward Yourdon: Object-Oriented Design. Englewood Cliffs, NY, 1991.

Als Standardnotation für objektorientierte Modelle hat sich die Unified Modeling Language (kurz UML) etabliert, die in den 1990er-Jahren insbesondere von Grady Booch, Ivar Jacobson und James Rumbaugh entwickelt wurde. Die Modelle in UML sind das wesentliche Kommunikationsmittel zwischen Entwicklern und weiteren Beteiligten im Softwareentwicklungsprozess.

mini|hochkant=1.4|Statische und dynamische Aspekte des Rational Unified Process. Die Fläche unter den Kurven zeigt den Umfang der jeweiligen Aktivitäten in den jeweiligen Disziplinen. Ein Vorgehensmodell, das speziell für objektorientierte Techniken und die UML entwickelt wurde, ist der sogenannte Rational Unified Process (RUP). Es handelt sich dabei um ein kommerzielles Produkt der Firma Rational Software, die seit 2004 Teil des IBM-Konzerns ist. Federführend bei der Entwicklung waren wiederum die drei Programmierer Grady Booch, Ivar Jacobson und James Rumbaugh.Philippe Kruchten: The Rational Unified Process. An Introduction. 2. Auflage. Addison-Wesley, 2004. Der RUP definiert die folgenden Disziplinen: Geschäftsprozessmodellierung (business modeling): Ein Verständnis für die Geschäftsprozesse wird erreicht. Anforderungsanalyse (requirements): Die Anforderungen werden erfasst, dokumentiert und organisiert. Analyse und Design: Die fachliche Architektur wird in ein technisches Design überführt. Implementierung: Es wird ein lauffähiges Softwaresystem erstellt. Test: Das Softwaresystem wird getestet. Auslieferung (deployment): Das Softwaresystem wird an den Kunden ausgeliefert. Ein Vorteil des RUP ist die iterative Vorgehensweise, wodurch im Gegensatz zu linearen Vorgehensmodellen (wie etwa dem Wasserfallmodell) sich ändernde Anforderungen auch zu einem späteren Zeitpunkt noch berücksichtigt werden können.

Der objektorientierte Ansatz

Die zugrunde liegende Idee der Objektorientierung ist es, Zustand (Daten) mit Verhalten (Funktionen auf diesen Daten) zu verbinden. Der Programmablauf soll dabei als ein Zusammenspiel von Objekten und ihren Interaktionen aufgefasst werden. Die Modellierung der Objekte erfolgt dabei in einer Anlehnung an die reale Welt, in der Objekte und ihre Interaktionen ein wesentlicher Bestandteil sind. Ergänzt wird dies durch das Konzept der Klasse, in der Objekte aufgrund ähnlicher Eigenschaften zusammengefasst werden. Man kann sich Klassen als abstrakte Schablonen für Dinge mit gemeinsamen Eigenschaften und Verhaltensformen vorstellen. Ein Objekt wird im Programmcode als Instanz oder Inkarnation einer Klasse definiert.

Das Kernstück jeder objektorientierten Überlegung bildet also das Objekt. Dieses ist ein Exemplar eines bestimmten Datentyps oder einer bestimmten Klasse und wird während der Laufzeit erzeugt (instanziiert). Objekte enthalten nun Attribute und Methoden. Dabei sind Attribute nur Variablen und Konstanten, die Werte aufnehmen können, und beschreiben damit das „statische Wesen“ des Objektes. Im Gegensatz dazu gibt es die „Methoden“ die das gesamte „dynamische Verhalten“ des Objektes oder einer Klasse charakterisieren; sie enthalten die „algorithmische Essenz“ des Objektes.

Beispiel: Die Klasse car für ein Auto definiert zwei Attribute fuel (Benzin) und maxSpeed (Höchstgeschwindigkeit). Diese beschreiben den Zustand eines Autos. Mit Methoden wie refuel() (tanken) oder drive() (fahren) lässt sich der Zustand eines Autos ändern. Sie charakterisieren dadurch das dynamische Verhalten. Allerdings ist die Klasse car erst der (softwaretechnische) „Bauplan“ eines Autos. Um mit „konkreten“ Autos während der Laufzeit umzugehen, müssen Instanzen dieser Klasse erzeugt werden, beispielsweise Objekte polo, mini und beetle. Eine Klasse wird daher bisweilen auch mit einer Ausstechform verglichen, die dazu dient, viele einzelne Plätzchen herzustellen.

Eine Klassifizierung ist im Allgemeinen eine Einschränkung/Vereinfachung der realen Welt in einem ganz speziellen Kontext. Es wird also niemals „die“ Klassifizierung geben. Sie ist immer abhängig vom Ziel, das mit der Klassifikation erreicht werden soll. Während beispielsweise eine Klasse „Auto“ im Kontext eines Autobauers möglicherweise Attribute wie Räder und Farbe besitzen wird und seine Bauteile (in Form von Attributen oder Beziehungen) kennen wird, hat eine Klasse „Auto“ im Kontext eines Händlers Attribute wie Produktnummer, Preis, Verbrauch und Erstzulassungsdatum. Im Kontext einer Zulassungsstelle wird es Attribute wie Kennzeichen, zulässiges Maximalgewicht und den Halter geben.

Grady Booch et al. nennen drei wichtige Aspekte, die objektorientierte Programmierung ausmachen:Grady Booch, Robert A. Maksimchuk, Michael W. Engle, Bobbi J. Young, Jim Conallen, Kelli A. Houston: Object-Oriented Analysis and Design with Applications. 3. Auflage. Addison-Wesley, 2007, S. 41.

Objektorientierte Programme nutzen Objekte (und nicht Algorithmen) als fundamentale logische Bausteine. Jedes Objekt ist eine Instanz einer Klasse. Klassen können durch das Konzept der Vererbung mit anderen Klassen verbunden sein.

Objektorientierte Analyse

Das Ziel der Analyse ist es, die Anforderungen eines Auftraggebers an ein neues Softwaresystem zu ermitteln und zu beschreiben. Bei dieser Phase werden meistens alle Aspekte der Implementierung ausgeklammert. Es kann aber beispielsweise der Entwurf einer Benutzerschnittstelle (z. B. GUI-Entwurf) bereits in der Analyse durchgeführt werden, da für viele Anwender erst dadurch ein Bild der zukünftigen Anwendung entsteht.

Die objektorientierte Analyse geht von Objekten aus, die sich in der realen Welt befinden. Dies sind nicht nur Gegenstände, sondern auch Ereignisse und Begriffe aus dem Anwendungsbereich. Das zu realisierende Problem soll verstanden und in einem OOA-Modell beschrieben werden. Dieses Modell soll die essentielle Struktur und Semantik des Problems beschreiben, aber noch keine technische Lösung. Man spricht auch von einem Fachkonzept, welches aus einem statischen und einem dynamischen Modell besteht: Das statische Modell zeigt insbesondere die Klassen des Systems, die Beziehungen zwischen den Klassen und die Vererbungsstrukturen. Pakete dienen dazu, um bei großen Systemen einen besseren Überblick zu gewinnen. Das dynamische Modell beschreibt die Funktionsabläufe. Anwendungsfälle beschreiben die durchgeführten Aufgaben auf einem hohen Abstraktionsniveau. Diese können durch Aktivitätsdiagramme oder Zustandsdiagramme noch verfeinert werden. Das OOA-Modell muss alle Informationen enthalten, um daraus einen Prototyp der Benutzungsoberfläche abzuleiten.Gert Heinrich, Klaus Mairon: Objektorientierte Systemanalyse. Oldenbourg Verlag, München 2008, S. 57.

Requirements Engineering