Der Traum ist fast so alt wie die Software-Entwicklung selbst: Durch wiederverwendbare Komponenten ließe sich Software in vielen Anwendungsbereichen wesentlich rascher entwickeln. Änderungen würden durch den Austausch der Komponenten ermöglicht. Viele der bekannten Nachteile handwerklicher Fertigung wie stark variierende Qualität, teure Produktion und schlechte Wartbarkeit ließen sich durch eine klug konzipierte "Industralisierung" der Software weitgehend vermeiden. Warum aber verharrt die "Zukunftsindustrie" jahrzehntelang wider besseres Wissen in solch atavistischen Produk- tionsmodellen?
Die traditionelle Software-Entwicklung läßt sich grob in zwei Lager aufteilen. Das eine ist davon gekennzeichnet, daß es dem Kunden exakt auf seine Bedürfnisse zugeschnittene Einzellösungen verspricht. Entwicklungen dieser Art können durchaus von Vorteil sein, etwa dann, wenn es gelingt, die Software ideal an das spezifische Geschäftsmodell anzupassen. Allerdings sind bei maßgeschneiderter Software die Vorteile bloß potentiell, die Nachteile hingegen erfahrungsgemäß fast garantiert. Zwei typische Gefahrenzonen: das Risiko, daß die Software nie fertiggestellt wird, und das Problem, die Software nicht rechtzeitig an die rasch wechselnden Geschäftsbedingungen anpassen zu können.
Einen anderen Weg beschreitet die zweite Gruppe: Man versucht dort durch den bewußten Einkauf von Standardsoftware, wie etwa Basispaketen ê la Microsoft Office bis hin zu Gesamtlösungen wie SAP R/3, die genannten Probleme zu verlagern. Die Kosten scheinen fix kalkulierbar zu sein. Der Softwarehersteller gewährt auch die weitere Evolution der Programme. Seine astronomischen Budgets für Aktualisierung und Entwicklung der Programmpakete können dem Einzelkunden egal sein, und die Gewährleistung der Interoperabilität ist Aufgabe des Herstellers. So könnte man also schlußfolgern, daß das Problem gelöst ist, weil es Bill Gates und Co. überantwortet wurde.
Es gilt allerdings zu bedenken, daß der Einsatz von Standardsoftware sehr oft eine weitgehende Reorganisation der Geschäftsprozesse erfordert. Außerdem ist Standardsoftware eben ein Standard. Das bedeutet, daß sie die Konkurrenz ebenfalls verwendet. Somit sind durch ihren Einsatz kaum größere Wettbewerbsvorteile zu erzielen. Ein weiterer Aspekt schließlich kann fatale Folgen für die Zukunft eines Unternehmens haben: Da Standardsoftware nicht unter der lokalen Kontrolle eines Kunden entstanden ist, kann sie möglicherweise nicht so einfach an die sich kontinuierlich verändernden Erfordernisse angepaßt werden.
Umdenken bei der Software-Entwicklung
Hier schließt sich der Kreis. Der Ausweg aus diesem Dilemma kann in einer konsequenten Hinwendung zu einer wirklich industriellen Konstruktion und Produktion von Software zu finden sein. Daß diese Evolution zur industriellen Herstellungsweise auch möglich wird, dazu bedarf es eines tiefgreifenden Umdenkens in der Strukturierung und Konzeption von Software. Die magische Bezeichnung, unter der dieser neuartige Mittelweg firmiert, lautet "Component Frameworks". Vereinfacht ausgedrückt, geht es dabei um die Arbeit mit Softwarebausteinen, die, egal in welcher Programmiersprache, komfortabel realisiert, idealerweise visuell-interaktiv, zu größeren Einheiten zusammengefügt werden können (Plug and work).
Voraussetzung dafür ist, daß das raffinierte Zusammenspiel der Komponenten durch ein solides Architekturrahmengerüst, das Framework, vordefiniert ist. Dessen Technologie ergänzt bestehende Objekt- beziehungsweise Komponentenstandards wie etwa COM/Active X, Java beans oder Corba und ermöglicht den Mittelweg zwischen maßgeschneiderter und Standardsoftware. Ein Framework ist unabhängig von seiner Größe eine Sammlung von zum Teil austauschbaren Einzelkomponenten, die bereits nach einem vordefinierten Schema interagieren, um eine bestimmte Aufgabe zu lösen.
Wiederverwendung statt "from the scratch"
Ein Anwendungsbeispiel sind Reservierungssysteme etwa für Hotels oder Mietwagenfirmen, die sich in diversen Details wie etwa bei der Abrechnung unterscheiden, sich in ihrer Grundstruktur aber weitgehend entsprechen. Bei der konventionellen, maßgeschneiderten Software-Entwicklung müßten dennoch beide Systeme getrennt voneinander nahezu von Anfang an programmiert werden, während ein Framework quasi als Halbfertigfabrikat ein Grundgerüst anbietet, das etwa an ein spezifisches Hotelreservierungssystem angepaßt werden kann. Die im Framework verwendete Platzhalterkomponente "Mietgegenstand" wird etwa durch den spezialisierten Baustein "Hotelzimmer" ausgetauscht (Plug and work). Analog wäre die Platzhalterkomponente "Mietgegenstand" durch ein "Fahrzeug" zu ersetzen. Dabei wäre unter anderem auch die Komponente zur Berechnung des Preises neu zu definieren und umzustecken.
Eine der Schwierigkeiten bei der Framework-Entwicklung ist das Auffinden adäquater "Hot Spots": Platzhalterkomponenten, deren Definition fundierte Kenntnisse des jeweiligen Anwendungsbereichs verlangt. Sind zuwenig Hot Spots vorhanden, ist das ebenso unerwünscht wie ein Framework, das Flexibilität um ihrer selbst willen bietet.
Frameworks sind ferner kein Wundermittel gegen die bekannten Schwächen der Software-Entwicklung. Ein Grund für ihre nur langsam fortschreitende Verbreitung könnte darin liegen, daß ihre Entwicklung eine erhebliche Investition bedeutet. Die entsprechenden Kosten liegen signifikant höher als jene zur Erstellung einer einzigen spezialisierten Anwendung. Aufgrund der in Framework-Projekten gesammelten Erfahrungen ist mit einem Faktor zwischen etwa vier und zehn zu rechnen. Die Kosten der Framework-Herstellung amortisieren sich daher erst mittel- bis langfristig, wenn mehrere Anwendungen durch Adaption eines Frameworks produziert werden.
Auch der Entwurf von Frameworks ist nach wie vor sehr schwierig, da der Erfolg eines Projekts fast ausschließlich davon abhängt, ob zumindest ein paar erfahrene Framework-Entwickler im Team sind.
Entwurfsmuster (Design Patterns) für Framework-Entwicklung leisten hier einen wichtigen Beitrag, um die grundlegenden Konzepte von Frameworks zu verstehen. Da sich Entwurfsmuster aber auf eine kleine Gruppe von Komponenten beziehen, in der Regel ein bis vier, geben sie bei der Entwicklung größerer Systeme nur eine geringe Hilfestellung.
Frameworks lassen sich nicht koppeln
Ein gravierendes Problem bei der Software-Entwicklung kann ferner auftreten, wenn zwei oder mehr solcher Rahmenwerke von unterschiedlichen Teams hergestellt wurden und diese sich nur sehr schwer untereinander koppeln lassen. Da ein Framework meist zentrale Aspekte einer Anwendung dominiert, etwa die Behandlung von internen oder externen Ereignissen, ist es mit anderen nicht koppelbar, da sich fundamentale Mechanismen stören oder nicht zusammenpassen würden. Hinzu kommt die Gefahr, daß beim Framework-Einsatz das sogenannte Fragile-Base-Class-Problem auftritt. Dieses entsteht, wenn durch Veränderungen an einer der Basisklassen grundlegende Entwurfsentscheidungen eines Frameworks über den Haufen geworfen werden und dies wiederum einen Dominoeffekt auf die Unterklassen beziehungsweise auf bereits erstellte Anwendungen bewirkt.
Wenn man schließlich noch berücksichtigt, daß die meisten Werkzeuge zur Unterstützung der Entwicklung von Frameworks Forschungsprototypen sind und nur wenige von ihnen komfortable Werkzeuge zur Adaptierung bieten, könnte das Versprechen, einen Mittelweg zwischen Custom-made- und Standardsoftware durch Frameworks zu finden, als reine Zukunftsmusik abgetan werden. Tatsächlich ist die Framework- und Komponententechnik längst aus dem Teststadium heraus. Gerade neue, wenn auch teilweise noch nicht ausgereifte Technologien wie Java, das mit seinen schlanken und stimmigen Konzepten eine gute Basis zur Realisierung von Frameworks bietet, sind schon heute von großer Bedeutung.
So stützt sich etwa IBM im "San-Francisco"-Projekt auf diese Sprache, um diverse Frameworks für den kommerziellen Einsatz etwa im Bankenbereich und im Handel zu bauen. Damit dürfte die Hoffnung verknüpft sein, durch diese beachtliche Investition mittel- bis langfristig eine softwaretechnisch überlegene Alternative etwa zum weitgehend konventionell implementierten SAP R/3 zu bieten, das ein kommerzell sehr erfolgreiches Framework darstellt. Letzteres setzt primär auf Parametrisierung durch externe Parameter statt auf Konfiguration durch Umstecken von Softwarekomponenten. Die Komplexität der San-Francisco-Artefakte, die bereits über mehrere tausend Klassen verfügen, stellt allerdings eine Hürde für Entwickler dar, die diese Rahmenwerke adaptieren sollen.
Kleine und mittlere Software-Firmen sollten zudem versuchen, mehrere gut koppelbare, aber sehr kleine Frameworks, sogenannte Framelets, zu bauen. Erste Anwendungen solcher Mini-Gerüste, die quasi die Wiederverwendung von Komponenten mit dem Vorteil von Halbfertigfabrikaten verbinden, wurden beispielsweise in einer Kooperation zwischen der Software & Web Engineering Gruppe der Universität Konstanz, Nokia und den Softwarehäusern der Raiffeisenbank Oberösterreich entwickelt.
Schließlich ist das Web ein Anwendungsgebiet, auf dem Framework-Technologie bereits eine entscheidende Rolle spielt und in Zukunft weiter an Bedeutung gewinnen wird. Um die Erstellung von Electronic-Commerce-Anwendungen zu automatisieren, wurden bereits 1995/96 Frameworks wie etwa Apples "Webobjects" angeboten. Intelligente Agenten und Jini sind weitere Beispiele, wo Framework-Technologie sich nutzbringend anwenden ließe.
Der Weg aus der Softwarekrise scheint angesichts der geschilderten Entwicklung durch Component Frameworks somit erstmals möglich. Leicht ist er nicht. Der oft beträchtliche Mehraufwand zur Konstruktion flexibler Rahmengerüste (also Frameworks, die Halbfertigfabrikate darstellen) wird sich aber auch im Bereich der Software bezahlt machen und es dann erlauben, den Begriff "modern" in Zusammenhang mit Softwareproduktion zu verwenden.
Angeklickt
Component Frameworks erlauben das raffinierte Zusammenspiel von Komponenten durch ein vordefiniertes Architekturrahmengerüst und versprechen eine industrielle Konstruktion und Produktion von Software. Ihre Technologie ergänzt bestehende Objekt- beziehungsweise Komponentenstandards wie etwa COM/Active X, Javabeans oder Corba, und eröffnen dem Anwendungsentwickler eine Alternative zu maßgeschneiderten Insellösungen oder eine tief in die Geschäftsprozesse eingreifende Standardsoftware. Für den erfolgreichen Aufbau von Komponentensystemen sind aber fundierte Kenntnisse des jeweiligen Anwendungsbereiches ebenso nötig wie der Aufbau von Know-how bezüglich des Entwurfs und Aufbaus des Rahmenwerkes.
*Wolfgang Pree ist Professor für Informatik an der Universität Konstanz und leitet die dortige Software & Web Engineering Gruppe.