Wer Software-Entwicklung im industriellen Massstab betreibt, kommt um eine Methodik nicht herum. Allerdings sind nur wenige objektorientierte Methoden ausgereift genug, um sich fuer komplexe Entwicklungen zu eignen. Rudolf Koster* beschreibt die Anforderungen, denen diese Methoden gewachsen sein muessen.

Objektorientierung ist in aller Munde; ueberwiegend wird jedoch immer noch ueber objektorientierte Programmierung diskutiert. Der Streit um die richtige OO-Programmiersprache wird oft mit dem Eifer religioeser Fanatiker gefuehrt. Erst langsam setzt sich die Erkenntnis durch, dass ueber die Qualitaet groesserer Programmsysteme ganz andere Faktoren entscheiden: Nur eine umfassende Analyse der zu loesenden Aufgabenstellung, gefolgt von einem sorgfaeltigen Systemdesign, kann zu gut strukturierten und damit robusten, weil aenderungsfreundlichen Programmen fuehren.

Dass der Einsatz objektorientierter Methoden auch und gerade in den fruehen Entwicklungsphasen zu besser aufgebauten Systemen verhilft, ist heute weitgehend unbestritten. Ein entscheidender Punkt wird bei der Diskussion um objektorientierte Entwicklungsmethoden jedoch oft vergessen: die Frage der Skalierbarkeit der jeweiligen Methode. Im Klartext: Wie verhaelt sich eine Methode mitsamt der eventuell vorhandenen unterstuetzenden Werkzeuge, wenn sie fuer die Entwicklung und Wartung grosser Programmsysteme eingesetzt wird?

Dieses Problem tritt insbesondere bei der industriellen Software- Entwicklung auf. Darunter wird hier die effiziente und hochgradig arbeitsteilige Entwicklung und Wartung grosser Systeme verstanden. Diese werden normalerweise von mehreren Entwicklungsteams erstellt, deren gleichzeitige Aktivitaeten koordiniert werden muessen. Deshalb ist in solchen Projekten eine methodische Vorgehensweise unbedingt erforderlich.

Brueche zwischen den Modellen

muessen vermieden werden

Sinnvollerweise besteht diese Vorgehensweise zunaechst in der Einteilung des Entwicklungszyklus in Phasen, in deren Verlauf Modelle des Systems entstehen. Der entstehende Programmcode ist dabei ein Modell unter mehreren - und keineswegs das wichtigste! Vorzuziehen sind in jedem Fall Methoden, bei deren Anwendung es nicht zu Bruechen zwischen den entstehenden Modellen kommt. Deshalb sind herkoemmliche strukturierte Analyse- und Design-Methoden problematisch.

Eine konsequente Anwendung objektorientierter Techniken in allen Entwicklungsphasen bietet hingegen die Moeglichkeit, Modelle zu entwickeln, die bruchlos auseinander hervorgehen und sich dabei von der Problemstellung immer mehr der Implementierung naehern. Hierbei haben die Entwickler den zusaetzlichen Vorteil, dass die Modelle lange Zeit nahe an der "Wirklichkeit" bleiben. Das bedeutet, dass sich die fuer das System grundlegenden Phaenomene idealerweise von der Analyse bis in den Programmcode (und umgekehrt!) verfolgen lassen.

Nun ist es aber keineswegs so, dass sich jede objektorientierte Methode zur industriellen Software-Entwicklung eignet. Die meisten lassen sich allenfalls gut zur Darstellung der eingesetzten objektorientierten Konzepte nutzen (die wichtigsten sind Objektidentitaet, Klassenbildung, Vererbung und Polymorphismus). Es gibt auch meist eine grafische Notation, um (statische) Objektstrukturen darzustellen. Wenn man Glueck hat, kann man mit diesen Methoden sogar die dynamische Interaktion zwischen unterschiedlichen Objekten veranschaulichen.

Was den meisten Methoden fehlt, ist eine klare Schritt-fuer- Schritt-Vorgehensweise, mit der sich ein komplexes System erstellen liesse. Darueber hinaus muss diese Komplexitaet waehrend der gesamten Systementwicklung und -wartung zuverlaessig beherrschbar sein. Deshalb sind verschiedene Strukturierungsmittel notwendig, die es erlauben, jeweils einen klar definierten Systemausschnitt zu betrachten.

Ohne CASE-Werkzeug ist die

Komplexitaet nicht beherrschbar

Von entscheidender Bedeutung fuer die industrielle Software- Entwicklung ueber mehrere Teams ist eine gute Werkzeugunterstuetzung. Ohne ein CASE-Werkzeug, das zumindest Analyse und Design abdecken sollte, kann die Komplexitaet eines grossen Systems nicht beherrscht werden. Neben der Mehrbenutzerfaehigkeit und der Moeglichkeit, (Teil-)Modelle zu importieren beziehungsweise zu exportieren, ist auch der Einsatz eines maechtigen Dokumentationssystems sinnvoll.

Objektorientierte Techniken sind in der Software-Entwicklung nichts Neues; schon die Programmiersprache Simula besass - vor immerhin 25 Jahren - alle grundlegenden objektorientierten Merkmale von Cii. Ebenfalls vor einem Vierteljahrhundert und in Skandinavien entwickelte Ivar Jacobson bei Ericsson eine objektbasierte Analyse- und Designmethode, die mit Erfolg zum Entwurf von Telekommunikationssystemen eingesetzt wurde. Die Programmierung erfolgte zunaechst in Assembler, spaeter in objektbasierten Sprachen wie Ada, wo es beispielsweise keine Vererbung gibt.

Das System laesst sich durch

Anwendungsfaelle beschreiben

Ein wesentliches Merkmal industrieller Software-Entwicklung ist die Aufteilung der Entwicklungsarbeit auf mehrere Teams. Damit die Abgrenzung der Aufgaben und die Kommunikation zwischen diesen Teams so reibungslos wie moeglich klappt, sind klare Schnittstellen erforderlich. Sie bestehen zum einen zwischen den bereits erwaehnten Modellen; so bekommt zum Beispiel eine Designerin als Ergebnis der vorhergehenden Analysephase ein genau definiertes Ergebnis in Form eines Analysemodells, das nach bestimmten Regeln und Heuristiken durch Einbeziehung der Implementierungsumgebung zu einem Designmodell weiterentwickelt wird.

Zum anderen sind auch innerhalb der einzelnen Modelle Schnittstellen und vor allem Strukturen notwendig. Bei groesseren Projekten wird es nur ganz wenige Personen geben, die einen Ueberblick ueber ein bestimmtes Modell in seiner Gesamtheit - also ueber alle zugehoerigen Objekte und deren Beziehungen - haben. Um nicht von der Komplexitaet erschlagen

zu werden und ein Hilfsmittel bei der Einteilung der Entwicklungsaktivitaeten zu haben, brauchen die Entwickler ein Strukturierungswerkzeug.

Hier hat sich das Mittel der "Anwendungsfaelle" als sehr maechtig erwiesen. Ein Anwendungsfall ist eine logisch zusammenhaengende, abgeschlossene Art, das zu entwickelnde System zu nutzen. Das System wird von der ersten Analysephase an mit Hilfe einer Sammlung von Anwendungsfaellen beschrieben. Dies geschieht in der Sprache des Auftraggebers und spaeteren Benutzers, weshalb die Gefahr von Missverstaendnissen ueber die Systemanforderungen nur gering ist.

Alle im weiteren Verlauf entstehenden Modelle sind auf natuerliche Weise durch die Anwendungsfaelle strukturiert. Betrachtet werden jeweils ein Anwendungsfall fuer sich und die zu ihm gehoerenden Objekte. Im Laufe der Systementwicklung entstehen so mehrere Beschreibungen mit zunehmendem Detaillierungsgrad - bis hin zum Programmcode in der gewaehlten Programmiersprache.

Wichtig ist dabei, dass die Moeglichkeit besteht, Objekte beziehungsweise Klassen jederzeit modelluebergreifend zu verfolgen, und zwar in beiden Richtungen. Beispielsweise muss der Entwickler feststellen koennen, welche Designobjekte aus einem bestimmten Analyseobjekt entstanden sind, oder mit welchem Designobjekt eine Klasse in der gewaehlten Programmiersprache korrespondiert.

Mit einer Entwicklungsmethode, deren Modelle bruchlos auseinander hervorgehen, kann also prinzipiell jede Implementierungsentscheidung bis zur zugrundeliegenden Anforderung des Auftraggebers zurueckverfolgt werden.

Die Kommunikation zwischen der Projektleitung und dem Auftraggeber, aber auch zwischen den Entwicklern untereinander erfolgt vor allem durch den Austausch von Modellen. Deshalb kommt einer aussagekraeftigen Dokumentation der Modelle entscheidende Bedeutung zu. Es muss moeglich sein, Objektstrukturen und dynamische Interaktion zwischen Objekten grafisch zu veranschaulichen.

Niemand wird eine gleichzeitige Darstellung aller im System vorhandenen Objekte ueberschauen koennen. Der Ueberblick ueber die jeweils zu einem Anwendungsfall gehoerenden Objekte ist jedoch bereits hilfreich.

In der Regel wird eine Grafik erst zusammen mit einer textlichen Darstellung des Sachverhalts wirklich verstaendlich. In der Dokumentation sollte die textliche Beschreibung fuer gleichartige Konzepte immer gleich aufgebaut sein; also sollten sich die Entwickler zu Beginn eines Projekts darauf einigen, wie sie Anwendungsfaelle oder einzelne Objekte beschreiben. Wichtig ist hier das Prinzip der Vollstaendigkeit: Jedes relevante Konzept muss sozusagen beim Entstehen ausfuehrlich dokumentiert werden.

Die Erstellung komplexer Modelle und die Erhaltung ihrer Konsistenz ist ohne Unterstuetzung durch mindestens ein CASE- Werkzeug nicht sinnvoll moeglich. Moderne Werkzeuge arbeiten in der Regel auf einem zugrundeliegenden Datenbestand (Repository), der die verschiedenen Sichten auf die Modelle integriert. Egal ob die grafische oder die textliche Darstellung eines Objekts veraendert wird, die Aenderung wird an genau einer Stelle im Repository vorgenommen.

Ein leistungsfaehiges Dokumentationssystem foerdert stark die Kommunikation im industriellen Entwicklungsumfeld. Gute Systeme produzieren eine uebersichtlich gedruckte Darstellung der Modelle, die als fertige technische Dokumentation des Systems dienen kann. Idealerweise sind die Dokumente aber auch am Rechner (online) als Hypertext-Dokumente verfuegbar. Auf diese Weise hat jeder an der Entwicklung Beteiligte einfache Navigationsmoeglichkeiten im Text und kann sich zum Beispiel bei Bedarf aus einem Ueberblicksdokument heraus die Detailspezifikation eines Objekts ansehen.

Modell und Dokument

jederzeit konsistent

Solch ein Hypertext-Dokument verwendet, um ein Objekt in einem Dokument zu erwaehnen, eine Objektreferenz anstelle eines normalen Textes. Auf diese Weise entsteht ein zusaetzlicher Vorteil: Modell und Dokument sind jederzeit konsistent. Immer wenn sich eine Eigenschaft des betreffenden Objekts (beispielsweise sein Name) aendert, wirkt sich dies durchgaengig auf alle Dokumente mit den entsprechenden Objektreferenzen aus.

Der Erfolg von Softwareprojekten im industriellen Massstab haengt stark von der angewandten Methodik ab. Objektorientierte Techniken koennen mit grossem Gewinn - vor allem an Qualitaet - in allen Phasen eines Projektes eingesetzt werden. Die oft genannte Zeitersparnis durch Wiederverwendung ist ein weiterer Vorteil; sie setzt jedoch meist erst nach einer Reihe von solcherart durchgefuehrten Projekten ein, da die firmenuebergreifende Wiederverwendung von Modellen mangels Standardisierung noch in den Kinderschuhen steckt.

Integration von Werkzeugen

ist absolut unverzichtbar

Nur wenige objektorientierte Methoden sind detailliert und ausgereift genug, um sich fuer Entwicklungen im industriellen Massstab zu eignen. Um in der Praxis einsetzbar zu sein, muss die Unterstuetzung durch ein mehrbenutzerfaehiges Werkzeug hinzukommen, das leicht an die Gegebenheiten vor Ort anzupassen ist. Unverzichtbar ist auch die Moeglichkeit zur Integration mit anderen Werkzeugen zum Konfigurations und Projekt-Management etc.

Der Markt bietet heute bereits ausgereifte Loesungen fuer die angesprochenen Probleme. Der verstaerkte Einsatz von Objektorientierung zusammen mit erprobten Grundsaetzen des Software-Engineerings gibt also Anlass, auf eine spuerbare Produktivitaetssteigerung bei der Entwicklung von Software zu hoffen.

*Rudolf Koster ist stellvertretender

Leiter des Bereichs Projekte bei der

Interface Computer GmbH, Muenchen, dort verantwortlich fuer die eingesetzte Projektmethodik.