Melden Sie sich hier an, um auf Kommentare und die Whitepaper-Datenbank zugreifen zu können.

Kein Log-In? Dann jetzt kostenlos registrieren.

Falls Sie Ihr Passwort vergessen haben, können Sie es hier per E-Mail anfordern.

Der Zugang zur Reseller Only!-Community ist registrierten Fachhändlern, Systemhäusern und Dienstleistern vorbehalten.

Registrieren Sie sich hier, um Zugang zu diesem Bereich zu beantragen. Die Freigabe Ihres Zugangs erfolgt nach Prüfung Ihrer Anmeldung durch die Redaktion.

12.11.1993 - 

Fundamente objektorientierter Systementwicklung

Mit der Analyse steht und faellt die Qualitaet der OO-Anwendung

Chancen und Nutzen objektorientierter Systementwicklung sind heute allgemein anerkannt. Wer darunter ausschliesslich die objektorientierte Programmierung versteht, betrachtet nur die Spitze eines Eisberges. Die Grundlage fuer eine stabile Systemarchitektur ist jedoch bei Analyse und Design zu legen.

Analyse und Design der konventionellen Systementwicklung sind gepraegt von deutlich getrennten Phasen, die gemaess Wasserfallmodell aufeinanderfolgen. Jede Phase hat ihre eigene Notation und Denkweise. Ein Phasenwechsel ist mit Aufwand verbunden und reduziert Leistungsfaehigkeit und Qualitaet des Entwurfs. Ein konventioneller Entwurf behandelt Datenmodell und Funktionenmodell getrennt voneinander. Eine spaetere Zusammenfuehrung wird durch notwendigen Abgleich beider Modelle erschwert.

Die objektorientierte Systementwicklung betrachtet Analyse (OOA) und Design (OOD) unter einem anderen Blickwinkel: Objektorientierung integriert Daten und Funktionen. Daraus resultiert ein Objektmodell, das den Objekten die Daten und Funktionen zuordnet. Grosse Uebersichtlichkeit und ueber lange Zeit stabile Objektstruktur sind qualifizierende Merkmale.

Typisches Kennzeichen von OOA und OOD ist das iterative Vorgehen ohne strenge Reihenfolge. Vom OOD ist ohne Aufwand zur OOA zurueckzukehren, um Detailaspekte wiederholt und tiefergehend zu analysieren. Dieses streng iterative Arbeiten laesst sich als Spirale beschreiben.

Das erarbeitete Objektmodell ist jederzeit erweiterbar. Der Entwickler kann aufgrund der Kapselung die Daten- und Funktionsbeschreibung unabhaengig von anderen Objekten aendern. Der Entwickler kann nach einer einheitlichen und vor allem durchgaengigen Denkweise ein System konstruieren. Gleiche Terminologie und Notation bei Analyse und Design vermeiden Reibungsverluste.

Aus diesen Gruenden sind objektorientierte Systeme nachweislich leichter zu warten als konventionelle. Ein Aspekt, der aufhorchen laesst, da fuer die Wartung normalerweise ein Vielfaches der Entwicklungskosten anfaellt.

Daten und Funktionen sind bei diesem Entwicklungsansatz nicht ueber das Programmsystem verteilt, sondern zentralisiert in einem Objekt verankert. In objektorientierten Systemen sind dadurch Aenderungen lokal begrenzt, Seiteneffekte sind nicht zu erwarten.

Bisherige Beobachtungen haben gezeigt, dass nicht nur eine stabile Objektarchitektur entsteht, sondern sich noch zwei weitere Vorteile ergeben. Einerseits ist die objektorientierte Denkweise leicht in die Analyse integrierbar, da sie zulaesst, Details zurueckzustellen, um sich auf das Wesentliche zu konzentrieren. Andererseits unterstuetzt die Analyse eine exakte Dokumentation der Ergebnisse schon in den ersten Schritten der Systementwicklung.

Die Analyse reduziert die Komplexitaet des Aufgabenbereichs und gewinnt ueberschaubare Teilbereiche. Das Ergebnis wird im Objektmodell dokumentiert.

Die Analyse ist der wichtigste Part einer objektorientierten Systementwicklung. Hier wird der Grundstein gelegt fuer eine ueber Jahre hinweg stabile Architektur. Fuer jedes Objekt muss erfasst werden, welche internen Daten, Funktionen und welche externen Schnittstellen vorliegen. Die den Objekten zugrundeliegenden Beschreibungen (Klassen) aendern sich kaum.

Das Design liefert eine Spezifikation fuer die Implementierung. Nachdem der Aufgabenbereich analysiert ist, wird eine effiziente Umsetzung unter Beruecksichtigung der Gegebenheiten der Implementierungssprache vorgenommen. Als Ergebnis entsteht ein detailliertes Objektmodell, das der direkten Umsetzung bei der Implementierung dient.

Die Objektorientierung gestattet es, gezielt und direkt in Analyse, Design und Implementierung einzugreifen.

Objektorientierte Analyse im Detail

Allen objektorientierten Analysemethoden ist eines gemeinsam: Sie gehen von einer generellen Aktivitaetenliste aus, die in freier Reihenfolge zu bearbeiten ist. Auch innerhalb der Analyse wird das iterative Abarbeiten folgender Punkte betont:

- Identifikation von Objekten. Das Erkennen der Objekte setzt die Beherrschung des Aufgabengebietes und Erfahrung im Umgang mit der Objektorientierung voraus. Objekte mit vergleichbarem internen Aufbau sind zu einer Klasse zusammenzufassen. Diese Klassifizierung liefert eine Beschreibung fuer gleichartige Objekte. Zur Bezeichnung der Klassen wird die Terminologie aus dem Aufgabenbereich verwendet. Wenn die Klassifikation abgeschlossen ist, wird nicht mit den Objekten, sondern mit ihren Klassen gearbeitet.

- Die Klassen werden untereinander in Relation gestellt. Die Verallgemeinerung und Spezialisierung (auch Vererbung) legt fest, welche Klasse eine Vergroeberung oder Verfeinerung einer anderen ist. Dadurch lassen sich gemeinsame Merkmale herausfiltern und allgemeine Klassen bilden. Unter vielen, aber nicht unter allen Klassen des Aufgabenbereichs kann dieser Relationstyp definiert werden. Eine weitere wesentliche Relation beschreibt das Verhaeltnis zwischen einem Ganzen und seinen Bestandteilen.

Mit der Erstellung der statischen Struktur ist der Rahmen des Aufgabenbereichs analysiert und der erste und wesentliche Schritt der OOA abgeschlossen. Im weiteren sind die dynamischen Aspekte des Aufgabenbereichs zu erfassen.

- Objekte tauschen untereinander Informationen aus. Dieser Vorgang wird als Nachrichten senden bezeichnet. Sender- und Empfaengerobjekt sowie der Typ (synchron, asynchron, zeitgesteuert ...) der Nachricht muessen bestimmt werden. Das Definieren der Nachrichten erfolgt in den Klassen.

- Daten und Funktionen sind zur Analyse des internen Klassenaufbaus zu identifizieren. Die in den Klassen definierten Funktionen (Methoden) legen das Verhalten der Objekte fest. Zur Funktionsspezifikation werden Vorgehensweisen aus der konventionellen Systemanalyse eingesetzt, aber nur lokal auf eine Klasse angewendet. Die Daten (Attribute) sind ebenfalls konventionell zu analysieren und zu beschreiben. Je nach Analyseziel kommen weitere Aktivitaeten hinzu: Ermittlung der Zustaende, der Zustandsuebergaenge, der Ereignisse etc..

- Mehrere Klassen koennen zu sogenannten Clustern verbunden werden. Ein Cluster kann nahezu unabhaengig von anderen Clustern durch ein Projektteam bearbeitet werden, modulares und paralleles Arbeiten wird unterstuetzt.

Wichtigste Erkenntnis: Die Objektorientierung beginnt bereits bei der Analyse. Sie schafft die Grundlage fuer Flexibilitaet der Architektur und Wiederverwendung der Entwurfsergebnisse.

Beim Design steht das Ziel im Vordergrund: Das Analyseergebnis optimal unter Einbeziehung der Kosten und Performance in eine Implementierungsvorschrift umzusetzen.

Analog zur Analyse orientiert sich das Design an einer Reihe von Aktivitaeten:

- Das Ergebnis der OOA muss abhaengig von der Zielplattform umgesetzt werden: Ist eine objektorientierte oder eine konventionelle Programmiersprache geeigneter? Beide Wege wurden erfolgreich begangen. Im zweiten Fall wird die Idee der Objektorientierung radikal konvertiert und konventionell weiterentwickelt.

- Zur Forcierung der Wiederverwendbarkeit ist die Benutzung von Klassenbibliotheken erforderlich. Man kann sie entweder kaufen oder auf in anderen Projekten erstellte Loesungen zurueckgreifen. Typische Einsatzbereiche fuer Bibliotheken sind Benutzeroberflaechen, aber auch komplexe Datenstrukturen oder Schnittstellen zu externen Systemen.

- Mit dem Design findet eine Bewertung der Analyse statt. Auftretende Abweichungen koennen im Prinzip jederzeit behoben werden.

Die Bewertung prueft: Vererbungshierarchie (Tiefe und Uebersichtlichkeit), Relationen, Einsatz des Polymorphismus, Nachrichten senden, Zuordnung der Klassen zu Tasks und Prozessoren. Die exakte Definition der klasseninternen Datenstrukturen, Funktionen, Systemdienste und Oberflaeche ist hier zu treffen.

- Erste Prototypen koennen vorgestellt werden. Wenn ihre Maengel festgestellt sind, werden sie nicht verworfen, sondern bis zum Zielsystem verfeinert.

Das Ergebnis ist ein komplettes Objektmodell, das sich bei der Implementierung umsetzen laesst.

Das Management muss sich bei Einfuehrung der Objektorientierung Fragen stellen zu Trends, Standards, Akzeptanz und Durchfuehrbarkeit. Als Vorgehensweise kann empfohlen werden: entweder Pilotprojekt mit objektorientierten Methoden oder Weiterentwicklung in der Standardsoftware-Umgebung unter sukzessivem Umstieg auf Objektorientierung.

Bei der Einfuehrung sollte ein Stufenplan mit folgenden Aktionen beachtet werden:

- Oeffentlichkeitsarbeit durch das Management,

- Festlegen der unternehmensspezifischen Anwendungsarchitektur (strategisch und fachlich),

- Objektmodell begruenden auf der Basis von unternehmensweiten Datenmodellen und Anwendungsarchitekturen,

- Konzept der Entwicklungsumgebung festlegen und passende Tools waehlen sowie

- Mitarbeiter informieren und trainieren.

Objektorientierte Systementwicklung ist insofern flexibler als konventionelle, als sie auch Architekturen wie Client-Server- Systeme unter Unix oder Windows NT in hoeherem Masse beruecksichtigt. Eine Reihe von Methoden fuer Analyse und Design steht bereit. Die Umsetzung in wirkungsvolle Tools ist in vollem Gange. Die Tools sind in der Regel fuer Unix konzipiert, aber auch fuer Windows mehren sich die Angebote; die Unterstuetzung fuer Windows NT muss noch beobachtet werden. Die Unterschiede in Qualitaet und Funktionalitaet sind betraechtlich. Es ist aber eine Konsolidierung bezueglich Funktionalitaet auf dem Markt erkennbar.

Die Object Management Group (OMG) forciert unter anderem die Standardisierung auf dem Gebiet der Objektorientierung und macht auch Vorschlaege zur objektorientierten Systementwicklung. Bis diese Bemuehungen jedoch greifen, muessen wir mit der Vielzahl von Tools und ihren Auspraegungen leben. Aber das Zeitalter der Objektorientierung hat erst begonnen.