next up previous contents
Nächste Seite: 3. Entwurfsmuster und Frameworks Aufwärts: 2. Softwareentwicklung Vorherige Seite: 2.2 Softwareengineering   Inhalt

Unterabschnitte


2.3 Objektorientierte Softwareentwicklung

In Abschnitt 2.2.2 wurden die traditionellen Methoden der Softwareentwicklung vorgestellt. Ihr wesentlicher Nachteil ist der Strukturbruch zwischen Analyse und Entwurf. Objektorientierte Softwareentwicklungsmethoden zeichnen sich hingegen durch einen durchgängigen Entwicklungsprozeß von der Analyse bis zur Wartung aus. Ziel objektorientierter Methoden ist es, die Struktur des Problembereichs möglichst genau auf die Implementierung abzubilden. Softwaresysteme werden nicht mehr dadurch entwickelt, daß Funktionskomplexe in Prozeduren und Module zerlegt werden, sondern indem der Systemkern durch Abstraktionen der Realität gebildet wird. Die bekanntesten objektorientierten Softwareentwicklungsmethoden sind die von Shlaer/Mellor, Coad/Yourdon, Booch, Rumbaugh (OMT) und Jacobson sowie der Rational Unified Process.

Objektorientierte Softwareentwicklungsmethoden gliedern sich in die Phasen Objektorientierte Analyse (OOA), Objektorientierter Entwurf/Design (OOD) und Objektorientierte Programmierung/Implementierung (OOP), zum Teil auch noch Objektorientierter Test (OOT). Die Grenzen zwischen den einzelnen Phasen sind jedoch fließend. Aktivitäten, die in einigen Methoden zur Analyse zählen, werden in anderen Methoden schon dem Entwurf zugeordnet.

Viele objektorientierte Softwareentwicklungsmethoden basieren auf dem evolutionären Vorgehensmodell, bei dem die Phasen Analyse, Entwurf, Implementierung und Test iterativ und durch Erweiterung des Vorhandenen durchlaufen werden. Nach jedem Durchlauf entsteht ein funktionsfähiges Zwischenprodukt, das im nächsten Durchlauf um zusätzliche Funktionalität erweitert wird (siehe Abschnitt 2.2.1). Aufgrund der Eigenschaft der einfachen Erweiterbarkeit objektorientierter Systeme ist das evolutionäre Vorgehensmodell für die objektorientierte Softwareentwicklung geradezu prädestiniert.

Generelles Ziel der Softwareentwicklung ist die Erstellung eines Softwaresystems zur Lösung eines gegebenen Problems. Softwareentwicklung kann dabei als ein Prozeß angesehen werden, bei dem die Elemente des Problem- bzw. Anwendungsbereichs in Elemente des Lösungsraumes abgebildet werden. Bei der objektorientierten Softwareentwicklung wird diese Abbildung dadurch realisiert, daß zunächst das Anwendungsgebiet analysiert und modelliert wird. Dazu werden die charakteristischen Elemente des Anwendungsgebietes sowie ihre Eigenschaften, Verhaltensweisen und Beziehungen untereinander identifiziert. Das so entstandene Modell des Anwendungsgebietes wird dann gemäß vorgegebener Regeln in ein Modell des Lösungsraums - letztendlich ein Programm - überführt. Objektorientierte Programmiersprachen enthalten hierzu spezielle Konzepte und Konstrukte, die diese Transformation erleichtern. Das Programm kann als Abstraktion des Anwendungsgebietes betrachtet werden, dessen Elemente weitgehend den Elementen des Anwendungsgebietes entsprechen.


2.3.1 UML

Mit dem Ziel, den sogenannten ,,Methodenkrieg`` in der objektorientierten Softwareentwicklung zu beenden, haben sich die drei Protagonisten Booch, Rumbaugh und Jacobson der bis dahin verbreitetsten Methoden Mitte der 90er Jahre zusammengetan. Erstes Ergebnis ihrer gemeinsamen Aktivitäten war 1997 die Veröffentlichung der Unified Modeling Language (UML), einer vereinheitlichten Modellierungsnotation. UML kann in allen Methoden zum Festhalten von Entwürfen und als Kommunikationsgrundlage zwischen den Entwickler(inne)n genutzt werden. UML bildet auch die Grundlage einer vereinheitlichten Entwicklungsmethode.

Die UML stellt eine Vielzahl verschiedener Diagrammtypen zur Verfügung, die in den verschiedenen Phasen des Softwareentwicklungsprozesses eingesetzt werden können. Die Diagrammtypen dienen zur Spezifikation der Struktur und des Verhaltens des zu entwickelnden Systems sowie zur Dokumentation von Implementierungsaspekten.

Strukturdiagramme

Klassendiagramme bilden den zentralen Bestandteil eines UML-Modells. Mit ihnen werden der Aufbau einzelner Klassen und Objekte (Attribute, Methoden) sowie Beziehungen zwischen den Klassen bzw. Objekten dargestellt. Bei den Beziehungen werden sogenannte Assoziationsbeziehungen, bei denen die beteiligten Klassen gleichwertig sind, Aggregations- bzw. Kompositionsbeziehungen, bei denen eine Klasse Bestandteil einer anderen Klasse (,,Ganzes-Klasse``) ist, und Vererbungsbeziehungen unterschieden.

Abbildung 2.3: UML-Klassendiagramm eines TicTacToe-Programms
\begin{figure}\centerline{\epsffile{Bilder/abb5.4.eps}}\end{figure}

In Abb. 2.3 wird das Klassendiagramm eines TicTacToe-Programms skizziert. Die Kästchen repräsentieren die Klassen mit ihren Attributen und Methoden, die Linien zwischen den Klassen die Beziehungen. Aggregationsbeziehungen sind durch die Raute am Ende der ,,Ganzes-Klasse`` gekennzeichnet (Klasse TTTBrett besteht aus mehreren Instanzen der Klasse TTTFigur). Vererbungsbeziehungen enden mit einem Pfeil an der Oberklasse (Klasse TTTProgramm wird von Klasse TTTSpieler abgeleitet).

Paketdiagramme dienen zur Strukturierung großer Systeme. Dabei werden mehrere Klassen unter bestimmten Gruppierungsaspekten zu Paketen zusammengefaßt und Abhängigkeiten zwischen den Paketen definiert.


Verhaltensdiagramme

Anwendungsfalldiagramme - eher unter dem Namen Use-Case-Diagramme bekannt - stellen das externe Systemverhalten dar. Sie beschreiben, welche Akteure welche Aktivitäten mit dem System durchführen können. Akteure können dabei sowohl Menschen als auch andere Programme/Systeme sein.

Interaktionsdiagramme, von denen zwei Arten - nämlich die Sequenz- und die Kollaborationsdiagramme - existieren, illustrieren zeitliche Abläufe in einem System. Während bei den Sequenzdiagrammen der zeitliche Ablauf beim Aufruf von Methoden im Vordergrund steht, dienen Kollaborationsdiagramme primär dazu, die Zusammenarbeit der Objekte zu verdeutlichen.

In Abb. 2.4 werden ausschnittsweise ein Sequenzdiagramm und ein Kollaborationsdiagramm der Methode spielen der Klasse TTTSpiel eines TicTacToe-Programms angedeutet. In Sequenzdiagrammen werden Objekte durch vertikale, Methodenaufrufe durch horizontale Linien dargestellt. Die Zeit verläuft von oben nach unten. In Kollaborationsdiagrammen wird der zeitliche Verlauf der Kommunikation durch entsprechende Numerierung der Methodenaufrufe verdeutlicht. Der Aufruf weiterer Methoden innerhalb einer Methode wird durch Unternummern gekennzeichnet.

Zustandsdiagramme demonstrieren, welche Zustände ein Objekt während seiner Lebenszeit einnehmen kann und durch welche Ereignisse und unter welchen Bedingungen Zustandsänderungen ausgelöst werden.

Aktivitätsdiagramme beschreiben Abläufe von Aktivitäten in einem Anwendungsfall oder einer Klasse. Sie sind auch für die Modellierung von möglicherweise zeitgleich stattfindenden Arbeitsabläufen geeignet.

Abbildung 2.4: UML-Interaktionsdiagramme eines TicTacToe-Programms
\begin{figure}\centerline{\epsffile{Bilder/abb5.5.eps}}\end{figure}

Implementierungsdiagramme

Implementierungsdiagramme, zu denen die Komponenten- und Einsatzdiagramme zählen, illustrieren implementierungsspezifische Aspekte. Komponentendiagramme können zur Festlegung von Abhängigkeiten zwischen Compiler und Laufzeitsystem bzw. Quellcode und Maschinencode eingesetzt werden, während Einsatzdiagramme dazu dienen, die Verteilung von Objekten auf verschiedene Rechner und Abhängigkeiten zwischen den Rechnern zu beschreiben.


2.3.2 Objektorientierte Analyse

Hauptaufgabe der OOA ist die Untersuchung des Problem- bzw. Anwendungsbereiches des zu entwickelnden Softwaresystems. Ziel dieser Phase ist die Erstellung eines Modells, das ein Abbild des statischen Aufbaus des Anwendungsgebietes sowie der dynamischen Abläufe innerhalb des Anwendungsgebietes darstellt. Leider sind die Aktivitäten der OOA nicht ,,mechanisierbar``. Vielmehr verlangen sie vom Entwicklungsteam viel Intuition, Fingerspitzengefühl und insbesondere praktische Erfahrung.

Die wesentliche Aktivität der OOA besteht im Auffinden von Klassen bzw. Objekten des Anwendungsgebietes, ihren Attributen und Methoden sowie Beziehungen zwischen den Klassen. Hierzu existieren in den einzelnen Entwicklungsmethoden unterschiedliche Ansätze. Einen Einstieg bildet z.B. die grammatikalische Untersuchung der Problembeschreibung. Substantive deuten auf mögliche Klassen hin, Adjektive auf Attribute und Verben auf Methoden. Sätze, in denen mehrere Klassenkandidaten auftreten, charakterisieren häufig Beziehungen zwischen den Klassen.

Bei größeren Projekten wird häufig die CRC-Methode eingesetzt. In gemeinsamen (Brainstorming-)Sitzungen bzw. Workshops erarbeiten Auftraggeber, Fachleute aus dem Anwendungsgebiet, spätere Benutzergruppen des zu entwickelnden Systems und das Entwicklungsteam einen umfassenden Überblick über die Begriffswelt des Anwendungsbereiches und halten die Ergebnisse auf Karteikarten - sogenannten CRC-Karten (Klassen (Classes), deren Aufgaben (Responsibilities) und Beziehungen zu anderen Klassen (Collaboration)) - fest.

Auf der Basis des erarbeiteten Klassendiagramms wird in Verhaltensdiagrammen das dynamische Verhalten der Objekte im Anwendungsbereich beschrieben.


2.3.3 Objektorientierter Entwurf

Die Grenzen zwischen der OOA und dem OOD sind fließend. Während sich die OOA jedoch ausschließlich mit dem Problembereich beschäftigt, ist die Hauptaufgabe beim OOD die Abbildung des OOA-Modells auf den Lösungsraum. Die OOD-Phase dient damit als konkrete Vorbereitung der Implementierung.

Das OOA-Modell wird in der OOD-Phase um weitere Klassen und die Klassen werden um zusätzliche Attribute und Methoden ergänzt, die im Problembereich nicht auftreten bzw. nicht relevant sind, bei der Implementierung aber unerläßlich sind, wie z.B. Klassen oder Methoden zur Speicherung oder Darstellung von Objekten. Des weiteren wird beim OOD die Softwarearchitektur festgelegt, indem Klassen zu Modulen (Paketen) zusammengefaßt werden. Weitere Aspekte, die es in der Entwurfsphase zu berücksichtigen bzw. festzulegen gilt, sind das dem System zugrundeliegende Betriebssystem, die Programmiersprache, die Art der Datenverwaltung (evtl. Anschluß von Datenbanken) und die Benutzungsoberfläche des Systems.

In der Entwurfsphase finden praktisch alle Diagrammtypen der UML Verwendung. Das Klassendiagramm und die Verhaltensdiagramme des OOA-Modells werden durch Erweiterungen bzw. Verfeinerungen von einem Modell des Anwendungsgebietes zu einem Modell des zu entwickelnden Systems (OOD-Modell) transformiert. Anwendungsfalldiagramme beschreiben typische Anwendungsszenarien späterer Benutzer mit dem System. Paket- und Implementierungsdiagramme bereiten die konkrete Umsetzung des Systemmodells in eine Implementierung vor.

Ein aktuelles Thema im Bereich des OOD sind die Entwicklung und Verwendung sogenannter Entwurfsmuster (Design Pattern). Entwurfsmuster beschreiben allgemeingültige Entwurfslösungen, die von erfahrenen Softwareentwickler(inne)n gefunden wurden und in unterschiedlichen Kontexten vor allem von anderen Entwicklungsgruppen wiederverwendet werden können. Sie helfen damit insbesondere Anfängern und Anfängerinnen beim Erlernen der objektorientierten Softwareentwicklung.


2.3.4 Objektorientierte Programmierung

In der OOP-Phase erfolgt die Umsetzung des OOD-Modells in eine konkrete Programmiersprache. Besonders geeignet sind hierfür natürlich objektorientierte Programmiersprachen. Die Nutzung anderer Programmiersprachen ist jedoch nicht generell auszuschließen. In der Regel müssen nicht alle Klassen des OOD-Modells (vollständig) implementiert werden. Für fast jede Sprache existieren sogenannte Klassenbibliotheken, die oft benötigte Klassen zur Verfügung stellen.


2.3.5 Objektorientierter Test und Wartung

Für den Test objektorientierter Software können traditionelle Testmethoden fast unverändert übernommen werden. Zunächst werden die einzelnen Klassen für sich und anschließend ihr Zusammenspiel getestet. Treten während des Betriebs des Systems Fehler auf oder soll das System später erweitert werden, kommen die Vorteile objektorientierter Software (Datenkapselung, Erweiterbarkeit, Wiederverwendbarkeit) voll zur Geltung. Außerdem leisten die UML-Diagramme als Dokumentation gute Dienste für eine bessere Verständlichkeit des Systems - gerade für Personen, die nicht selbst im Entwicklungsprozeß involviert waren.


next up previous contents
Nächste Seite: 3. Entwurfsmuster und Frameworks Aufwärts: 2. Softwareentwicklung Vorherige Seite: 2.2 Softwareengineering   Inhalt
Ditrich Boles 2005-09-09