Mit CASE liess sich die Softwarekrise nicht bewaeltigen Wiederverwendung heisst die Waffe im Kampf um Produktivitaet

28.01.1994

Das Tempo, in dem Bedarf an und Abhaengigkeit von Information in den Unternehmen wachsen, kann die Informationsverarbeitung vielerorts nicht mithalten. Der Grund fuer dieses Defizit liegt, so Walter Beisheim*, bei der Software, die immer weiter hinter den Leistungsmoeglichkeiten der Hardware zurueckbleibe. Eine Loesung verspricht die Objekttechnik. Deren Waffe bei der Aufholjagd nach Produktivitaet und Qualitaet ist die Wiederverwendung.

Die Unternehmen stecken derzeit in einem Dilemma: Sie werden einerseits immer abhaengiger von Informationen - so weit, dass fast kein Geschaeftsvorgang mehr ohne den kontinuierlichen Fluss von rechnergestuetzten Informationen moeglich ist; andererseits bereitet ihnen die Verwaltung der wachsenden Informationsmengen Kopfzerbrechen: Die Verarbeitungskapazitaet haelt nicht Schritt mit dem Informationswachstum, und die Unternehmen drohen an ihren eigenen Datenbestaenden zu ersticken.

Das Problem ist die sprichwoertliche Softwarekrise: Die Bestaende an eingefuehrter Software blockieren die Anpassung der Geschaeftsprozesse an neue Erfordernisse; eine wirksame Ueberarbeitung der Software ist aber aufgrund veralteter Technik nicht moeglich.

Der immer raschere wirtschaftliche Wandel verschaerft das Problem noch. Viele Applikationen sind wegen der zu langen Entwicklungszeiten bei ihrer Fertigstellung bereits reif fuer die Mottenkiste. Aus Untersuchungen geht hervor, dass nur fuenf Prozent der entwickelten Software im Produktionsbetrieb einsetzbar ist. Die restlichen 95 Prozent werden fuer untauglich befunden oder nie zu Ende geschrieben.

Die Leistungsdiskrepanz zwischen Hard- und Software ist kein neues Phaenomen- auch wenn sie durch die Performance-Explosion bei der Hardware in den letzten Jahren an Brisanz gewonnen hat. Ende der 60er Jahre bereits wurde ueber eine effizientere Software- Entwicklung nachgedacht. Ergebnis war die strukturierte Programmierung: Dabei wird das Programmdesign im Top-down- Verfahren entwickelt. Die Idee war, das Programm systematisch in Komponenten zu zerlegen, die sich - bis auf die Ebene primitiver Grundkomponenten - wiederum in Unterkomponenten unterteilen lassen. Daten und Funktionen werden dabei strikt getrennt.

Die strukturierte Programmierung brachte zwar gewaltige Verbesserungen in der Softwarequalitaet, weist aber auch Nachteile auf. Einer der gravierendsten ist, dass sich das Design eines Systems erst nach dessen Implementierung umfassend ueberschauen laesst. Hierdurch werden vor allem bei komplexen Softwaresystemen oft umfangreiche Nachbesserungen erforderlich. Die Trennung der Daten von den sie benutzenden Funktionen bewirkt, dass jede Aenderung der Datenseite eine Vielzahl von Anpassungen auf der Funktionsseite erfordert und umgekehrt.

Um diese Fehlerquelle zu umgehen, erfordern etwaige Aenderungen erheblichen Planungsaufwand.

Oft ist eine Aenderung ueberhaupt nicht moeglich, und es heisst resignierend: "Never touch a running system." Die juengste Errungenschaft der strukturierten Programmierung ist CASE. Dabei verwaltet der Rechner den Prozess der funktionalen Dekomposition. Allerdings laesst sich die Software-Entwicklung mit CASE nicht komplett automatisieren. Vielmehr uebersetzen CASE-Tools das grafisch vorliegende Design in den entsprechenden Programmtext. Das grafische Design muss der Entwickler also nach wie vor selbst erstellen, was bei komplexen Programmen in der Regel mit sehr viel Zeit und Arbeit verbunden ist.

CASE hat die Erwartungen der Industrie weder hinsichtlich Produktivitaet noch hinsichtlich Softwarequalitaet erfuellt. Die Umsaetze der CASE-Anbieter stagnieren. Einer der Gruende mag darin liegen, dass dieses Konzept keinen perfekten Uebergang zwischen Planung und Implementierung bietet. Als Folge driften die dokumentierte Programmstruktur und die tatsaechliche Implementierung auseinander, was wiederum einen beachtlichen Zeitverlust bei der Programmpflege nach sich zieht.

Ein weiterer Ansatz zur Automatisierung der Programmierung sind die 4GLs. Sie stellen diverse Tools zur Verfuegung, die die automatische Entwicklung routinemaessiger Geschaeftsanwendungen - einschliesslich Formularen, Berichten und Menues - unterstuetzen. Sie bieten eine Reihe von Vorteilen, so etwa den, dass theoretisch auch Personen ohne Programmierkenntnisse damit Anwendungen generieren koennen.

Allerdings lassen sich mit 4GLs nur einfache Programme entwickeln - und diese auch nur fuer hinlaenglich bekannte Standardprobleme. Die derzeit verbreiteten 4GL-Pakete stossen oft auf unueberwindliche Grenzen, wenn etwas programmiert werden muss, das vom Standard abweicht. Da waehrend der Lebenszeit eines Programmpakets dessen Komplexitaet haeufig ueber das urspruenglich geplante Mass hinaus zunimmt, besteht das latente Risiko, dass eine 4GL-Entwicklung zu einem nicht vorhersehbaren Zeitpunkt ploetzlich ersetzt werden muss.

Trotz der sich verbessernden Methoden zur Programmentwicklung steigert sich das Ausmass der Softwarekrise von Jahr zu Jahr. Vierzig Jahre nach Erfindung der Subroutine werden Softwaresysteme immer noch per Hand entwickelt. Zwar koennen die Entwickler mittlerweile auf verbesserte Methoden zur Unterstuetzung des Entwurfsprozesses zurueckgreifen, fuer die Entwicklung grosser Softwaresysteme sind diese aber haeufig untauglich. Zudem produzieren die Methoden allzuoft fehlerbehaftete Software, die sich ueberdies nur schwer modifizieren und warten laesst.

Mehr Flexibilitaet und Zuverlaessigkeit

Eine durchgreifende Loesung verspricht heute die Objektorientierung, die - obwohl zum ersten Mal bereits Ende der 60er Jahre in der Programmiersprache Simula verfuegbar gemacht - erst in den letzten Jahren im Markt an Bedeutung gewonnen hat. Sie ermoeglicht die effiziente Entwicklung grosser wie kleiner Systeme, die zudem zuverlaessig, flexibel, wartungsfreundlich und an veraenderte Anforderungen anpassbar sind.

Eine Zuverlaessigkeit ruehrt daher, dass jedes Objekt externen Agents gegenueber den Charakter einer Black box hat. Die gesteigerte Flexibilitaet ergibt sich aus der abstrakteren Modellierung des Realweltproblems, die das Modell fuer unterschiedliche Problemstellungen einsetzbar macht.

Die Programme sind ausserdem uebersichtlicher und lesbarer. Da Daten und Programme gemeinsam abgelegt werden, lassen sich objektorientierte Programme leichter nachvollziehen. Ueberdies koennen viele Realweltobjekte aufgrund der hierarchischen Struktur der objektorientierten Programmierung auf natuerliche Weise abgebildet werden, weil die aufeinanderfolgenden Schichten Detailebenen mit zunehmenden Tiefenstufen entsprechen. Dies erleichtert nicht nur die Entwicklung, sondern auch die Pflege objektorientierter Programme.

Einer der wichtigsten Nutzeneffekte ist jedoch die Moeglichkeit zur Wiederverwendung, also wiederholten Benutzung von Objektklassen: In einem objektorientierten System kann jede Unterklasse oder Instanz eines Objekts den fuer die gesamte Klasse entwickelten Programmcode (die Methode) nutzen. Das schliesst sowohl die komplette Uebernahme von Softwaremodulen als auch den erneuten Gebrauch vorhandener Konstrukte zwecks Modifikation ein. An allen Softwaresystemen muessen Aenderungen und Erweiterungen vorgenommen werden. Bei den konventionellen Programmiertechniken ist die Software dann meist neu zu entwickeln, da sie fuer die Loesung ganz spezifischer Probleme geschrieben wurde. Im Gegensatz dazu laesst sich ein objektorientiertes Programm erweitern, indem man neue Variationen eines Grundkonzeptes hinzufuegt.

Dies geschieht durch Einfuehrung zusaetzlicher Unterklassen. Hierbei muss im Gegensatz zu konventionellen Techniken kein Programmcode geaendert werden, wodurch einschlaegige Fehler ausgeschlossen sind.

Auch die Qualitaet laesst sich vererben

Zudem bewirkt die Vererbungshierarchie zwischen den Klassen, dass Fehler in konzeptionell hoeherliegenden Ebenen schneller gefunden werden koennen. Deren Korrektur - entsprechendes gilt fuer andere Programmverbesserungen - beruehrt einen grossen Bereich der Anwendung, so dass auch Qualitaet vererbt wird.

Der Nutzen der bei der Objekttechnik moeglichen Wiederverwendung von in sich geschlossenen Softwaremodulen resultiert aus der Steigerung der Softwarequalitaet und der Produktivitaet. Konkret bedeutet das beispielsweise: verbesserte Wirtschaftlichkeit durch Vermeidung von Mehrfachentwicklungen, weniger Fehler durch Verwendung bereits getesteter Module, hohe Konsistenz durch Nutzung derselben Geschaeftsregeln und Berechnungsverfahren in allen Anwendungen sowie weniger redundanter Programmcode.

Waehrend bei herkoemmlichen Programmiertechniken die Wiederverwendbarkeit von Softwaremodulen nur schwer realisierbar ist, macht die Objekttechnologie sie bereits von vornherein verfuegbar: Jede Klasse kann ueber das Vererbungsprinzip prinzipiell als Superklasse anderer Klassen fungieren. Je abstrakter ein Modul geschrieben wird, um so hoeher kann es in der Klassenhierarchie angeordnet werden - und um so hoeher ist auch seine Wiederverwendbarkeitsquote.

In einer objektorientierten Umgebung, die auf dem Vererbungskonzept basiert, lassen sich aber nicht nur individuelle Komponenten, sondern - ueber sogenannte Rahmenkonzepte - komplette Anwendungen wiederverwenden. Die Rahmenkonzepte umfassen mehrere abstrakte Superklassen. Diese definieren die Zusammenarbeit der Subklassen, die konkrete Operationen implementieren. Ein Rahmenkonzept laesst sich wiederverwenden, indem neue Subklassen entwickelt und vorhandene neu kombiniert werden.

Rahmenkonzepte tradieren folglich das strukturelle Design von Software-Objekten, die fuer einen gegebenen Anwendungsfall entwickelt wurden. Im Zuge ihrer Weiterentwicklung und Wiederverwendung in den Unternehmen definieren die Rahmenkonzepte schliesslich das gesamte Know-how des Unternehmens.

Das Konzept steht und faellt mit den Klassen. Diese muessen so definiert werden, dass sie universell einsetzbar und leicht wiederzuverwenden sind. Das ist aber leichter gesagt als getan. Bei der Entwicklung sind die unterschiedlichsten Dinge zu beruecksichtigen. Dazu zaehlen kuenftige Verwendungsmoeglichkeiten sowie die dazu benoetigten Dienste. Die Aufgabe besteht darin, die Klasse so umfassend festzulegen, dass sie allen antizipierten Anforderungen nachkommt, sie gleichzeitig aber auch einfach und unabhaengig von anderen Klassen zu gestalten, damit eine gute Modularitaet gewaehrleistet ist.

Heute gibt es bereits fertige wiederverwendbare Klassen, die entweder direkt mit der Programmiersprache ausgeliefert oder von Softwarehaeusern bereitgestellt werden, die sich auf dieses Gebiet spezialisiert haben. Smalltalk ist ein Beispiel fuer eine objektorientierte Sprache, die eine Bibliothek wiederverwendbarer Klassen verfuegbar macht.

Die Wiederverwendbarkeit von Software ist einer der wesentlichen Gruende fuer den durch die Objekttechnologie erzielbaren Produktivitaetsgewinn. Dieser Zuwachs wurde mittlerweile in diversen Projekten quantifiziert. Die objektorientierte Software- Entwicklung verspricht dieselben Vorteile, die in der modernen Fertigungspraxis anvisiert werden: schnellere Produktion, hoehere Qualitaet und leichtere Wartbarkeit - und das alles zu reduzierten Kosten.