Objektorientierte Analyse und Design

Grundidee und Zweck

Objektorientierte Analyse und Design (OOAD) sind objektorientierte Varianten der Anforderungsanalyse und des Systementwurfs im Entwicklungsprozess eines Softwaresystems. In der Analyse werden die Anforderungen an ein neues System erfasst, beschrieben, dargestellt und überprüft. Im Design wird daraus ein technischer Entwurf entwickelt, der als Vorlage für die Implementierung dient. Weil in Analyse, Design und Implementierung ähnliche objektorientierte Konzepte genutzt werden, wird der Übergang zur Programmierung in einer objektorientierten Programmiersprache erleichtert.

Als Standardnotation für objektorientierte Modelle hat sich die Unified Modeling Language (UML) etabliert. UML-Modelle dienen im Softwareentwicklungsprozess als wichtiges Kommunikationsmittel zwischen Entwicklern und weiteren Beteiligten. Ein Vorgehensmodell, das speziell für objektorientierte Techniken und UML entwickelt wurde, ist der Rational Unified Process (RUP).

Vorgehensmodelle und RUP

Ein Vorgehensmodell zur Softwareentwicklung ordnet die Arbeit an einem Softwareprojekt in Phasen und macht die Komplexität besser beherrschbar. Ziel ist es, aus einem Konzept oder einer Produktspezifikation ein lauffähiges Softwareprodukt zu entwickeln. Manche Modelle durchlaufen die Phasen einmal, zum Beispiel das Wasserfallmodell, andere mehrfach, zum Beispiel das Spiralmodell. Bei mehrfachen Durchläufen werden Softwarekomponenten iterativ, also wiederholt, verfeinert. Über das optimale Vorgehensmodell besteht Uneinigkeit.

Objektorientierte Analyse- und Entwurfsmethoden haben seit Beginn der 1980er-Jahre an Bedeutung gewonnen. Ein früher Ansatz war „Object-Oriented Analysis“ (OOA) von Peter Coad und Edward Yourdon; „Object-Oriented Design“ (OOD) schließt daran an und behandelt den Übergang zum Entwurf.

Der Rational Unified Process (RUP) wurde für objektorientierte Techniken und UML entwickelt. Er ist ein kommerzielles Produkt der Firma Rational Software, die seit 2004 Teil von IBM ist. Federführend beteiligt waren Grady Booch, Ivar Jacobson und James Rumbaugh. Der RUP unterscheidet unter anderem die Disziplinen Geschäftsprozessmodellierung, Anforderungsanalyse, Analyse und Design, Implementierung, Test und Auslieferung. Ein Vorteil des RUP ist seine iterative Vorgehensweise: Im Gegensatz zu linearen Modellen können sich ändernde Anforderungen auch später noch berücksichtigt werden.

Objekte, Klassen und Vererbung

Die Grundidee der Objektorientierung ist, Zustand und Verhalten miteinander zu verbinden. Zustand meint Daten, Verhalten meint Funktionen auf diesen Daten. Ein Programmablauf wird als Zusammenspiel von Objekten und ihren Interaktionen verstanden. Objekte werden in Anlehnung an die reale Welt modelliert.

Eine Klasse fasst Objekte mit ähnlichen Eigenschaften zusammen. Sie ist eine abstrakte Schablone für Dinge mit gemeinsamen Eigenschaften und Verhaltensformen. Ein Objekt ist eine Instanz einer Klasse und wird während der Laufzeit erzeugt, also instanziiert. Objekte besitzen Attribute und Methoden. Attribute sind Variablen oder Konstanten, die Werte aufnehmen und das statische Wesen des Objekts beschreiben. Methoden beschreiben das dynamische Verhalten und enthalten die algorithmische Essenz des Objekts.

Ein Beispiel ist die Klasse car für ein Auto. Sie kann Attribute wie fuel für Benzin und maxSpeed für Höchstgeschwindigkeit besitzen. Methoden wie refuel() und drive() ändern den Zustand eines Autos. Die Klasse car ist nur der Bauplan; konkrete Objekte wären etwa polo, mini und beetle. Welche Attribute eine Klasse hat, hängt vom Kontext ab: Ein Autobauer, ein Händler und eine Zulassungsstelle würden die Klasse Auto unterschiedlich modellieren.

Grady Booch et al. nennen drei wichtige Aspekte objektorientierter Programmierung: Objektorientierte Programme nutzen Objekte als fundamentale logische Bausteine, jedes Objekt ist eine Instanz einer Klasse, und Klassen können durch Vererbung miteinander verbunden sein.

Analyse und Anforderungen

Ziel der objektorientierten Analyse ist es, die Anforderungen eines Auftraggebers an ein neues Softwaresystem zu ermitteln und zu beschreiben. Meist werden technische Implementierungsdetails zunächst ausgeklammert. Das zu realisierende Problem soll verstanden und in einem OOA-Modell beschrieben werden. Dieses Modell beschreibt die wesentliche Struktur und Semantik des Problems, aber noch keine technische Lösung. Es wird auch Fachkonzept genannt und besteht aus einem statischen und einem dynamischen Modell. Das statische Modell zeigt Klassen, Beziehungen und Vererbungsstrukturen; das dynamische Modell beschreibt Funktionsabläufe, zum Beispiel durch Anwendungsfälle, Aktivitätsdiagramme oder Zustandsdiagramme.

Requirements Engineering bedeutet, Anforderungen zu ermitteln, zu spezifizieren, zu analysieren, zu validieren und daraus eine fachliche Lösung beziehungsweise ein Produktmodell abzuleiten. Anforderungen legen fest, was von einem Softwaresystem erwartet wird. Personen oder Organisationen, die Interesse an der Softwareentwicklung haben oder vom System betroffen sind, heißen Stakeholder.

Der IEEE Standard 830 unterscheidet funktionale und nichtfunktionale Anforderungen. Funktionale Anforderungen beschreiben bereitzustellende Funktionen oder Services und können Statik, Dynamik oder Logik des Systems betreffen. Nichtfunktionale Anforderungen, auch technische Anforderungen oder Quality of Service (QoS), betreffen unter anderem Zuverlässigkeit, Verfügbarkeit, Nebenläufigkeit, Konsumierbarkeit, Internationalisierung, Informationssicherheit, Service-Anforderungen und Support. Sie beeinflussen die Softwarearchitektur stark und können sich widersprechen, etwa Sicherheit und Benutzbarkeit oder Speichereffizienz und Laufzeiteffizienz.

Nach Balzert soll eine einzelne Anforderung korrekt, eindeutig, vollständig, konsistent, nach Wichtigkeit klassifizierbar, nach Stabilität klassifizierbar, überprüfbar und verfolgbar sein. Ein Lastenheft ist nach DIN 69901 die vom Auftraggeber festgelegte Gesamtheit der Forderungen an Lieferungen und Leistungen. Ein Pflichtenheft enthält nach DIN 69901 vom Auftragnehmer erarbeitete Realisierungsvorgaben auf Basis des Lastenhefts. Beide helfen beim Erstellen des OOA-Modells, sind aber weniger detailliert als dieses.

Strukturelle und dynamische UML-Modelle

Zur strukturellen Modellierung werden Strukturdiagramme genutzt. Die wichtigsten Diagrammtypen des objektorientierten Designs sind Klassendiagramm und Objektdiagramm. Ein Klassendiagramm zeigt beteiligte Klassen und ihre Beziehungen. In UML werden Klassen als dreigeteilte Rechtecke dargestellt: Klassenname, Attribute sowie Operationen und Eigenschaften. Eine Operation ist die abstrakte Definition einer Funktionalität; eine Methode ist ihre konkrete Implementierung.

Eine Assoziation modelliert Verbindungen zwischen Instanzen einer oder mehrerer Klassen und wird meist als Linie dargestellt. Kardinalitäten geben an, wie viele Objekte beteiligt sein können oder müssen. Eine Aggregation ist eine Teil-Ganzes-Beziehung und wird mit einer nicht ausgefüllten Raute am Ganzes-Ende gekennzeichnet. Eine Komposition ist eine stärkere Aggregation: Ein Teilobjekt gehört immer nur zu einem Ganzen, wird mit diesem gelöscht, und die dynamische Semantik des Ganzen gilt auch für die Teile. Sie wird mit einer gefüllten Raute dargestellt. Vererbung zeigt dauerhafte Beziehungen zwischen Basisklasse und abgeleiteter Klasse; in UML zeigt ein Pfeil mit dreieckiger Spitze von der abgeleiteten Klasse zur Basisklasse.

Ein Objektdiagramm ist ein Sonderfall des Klassendiagramms. Es zeigt tatsächlich erzeugte Objekte, ihre Attributwerte und ihre Beziehungen in einem begrenzten Zeitraum der Laufzeit. Eine konkrete Beziehung zwischen Objekten heißt Link oder Objektbeziehung. Das Verhalten objektorientierter Systeme wird durch Botschaften beschrieben, mit denen Objekte kommunizieren. Eine Botschaft besteht aus einem Selektor, einer Liste von Argumenten und geht an genau einen Empfänger.

Zur dynamischen Modellierung gehören Anwendungsfälle, Sequenzdiagramme, Kommunikationsdiagramme und Zustandsdiagramme. Anwendungsfälle beschreiben extern beobachtbare Funktionen eines Systems. An jedem Anwendungsfall ist mindestens ein Akteur beteiligt, jeder hat einen fachlichen Auslöser und liefert ein fachlich relevantes Ergebnis. Sequenzdiagramme zeigen den zeitlichen Austausch von Nachrichten zwischen Objekten über Lebenslinien. Synchrone Nachrichten blockieren die ausgehende Lebenslinie bis zur Antwort, asynchrone nicht. Kommunikationsdiagramme zeigen, wie Objekte für eine bestimmte Operation zusammenarbeiten. Zustandsdiagramme modellieren Zustände und Übergänge eines Objekts; ein Zustandsautomat besitzt genau einen Startzustand und kann Endzustände enthalten.

Objektorientiertes Design

Objektorientiertes Design zielt auf die Systemplanung mit Objekten, die sich gegenseitig beeinflussen, und auf die Lösung der Programmierprobleme. Anders als das Pflichtenheft berücksichtigt der Design-Entwurf technische Aspekte und richtet sich auf die Realisierung der Anforderungen, bleibt aber abstrakter als die spätere Implementierung.

Beim Übergang von der Analyse zum Design werden Analysemodell und Klassen erweitert und verbessert. Nach Coad und Yourdon wird OOD in vier Komponenten zerlegt: Problembereichskomponente, Kommunikationskomponente, Datenmanagementkomponente und Taskmanagement-Komponente.

In der Problembereichskomponente werden Klassen für die Implementierung vorbereitet. Attribute, Objektbeziehungen und Klassen können ergänzt oder gestrichen werden. Ziel sind abgeschlossene Klassen angemessener Komplexität. Wichtige Qualitätsbegriffe sind Kopplung und Kohäsion. Kopplung beschreibt die Stärke der Abhängigkeiten zwischen Klassen und soll möglichst gering, aber so hoch wie nötig sein. Kohäsion beschreibt, wie gut eine Klasse eine logische Aufgabe oder Einheit abbildet. Das Single-Responsibility-Prinzip fordert, dass jede Klasse genau eine fest definierte Aufgabe erfüllt. Das DRY-Prinzip („Don't Repeat Yourself“) soll Code-Duplizierung vermeiden.

Die Kommunikationskomponente betrifft die Mensch-Computer-Kommunikation: Sie legt fest, wie Benutzer das System bedienen und wie das System Ergebnisse präsentiert. Die Datenmanagementkomponente behandelt das Speichern und Wiederfinden von Objekten. Wichtige Aspekte sind Integrität, also Schutz vor unautorisierter Änderung, und Konsistenz, also Korrektheit gespeicherter Daten. Persistente Objekte können in Textdateien, in Tabellen relationaler Datenbanksysteme oder in objektorientierten Datenbanken aufbewahrt werden. Die Taskmanagement-Komponente koordiniert paralleles Verhalten oder asynchrone Kommunikation zwischen Objekten. Tasks können üblicherweise die Zustände „running“, „suspended“ oder „terminated“ annehmen.