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.

03.03.1995

Objektorientierung mit Netz und doppeltem Boden Frameworks liefern den Rohbau fuer feinste Anwendungssoftware

Was sind Frameworks - Konkurrenz oder Korsett der objektorientierten Software-Entwicklung? Antwort auch auf diese Frage gibt Walter Bischofberger*. Neben einer Definition des Begriffs haelt er Erlaeuterungen bereit, die Verwendungszweck und - moeglichkeiten abstecken sowie Tips zur Erstellung eines solchen Rahmenwerks liefern.

Im Gegensatz zu einer problemspezifischen Loesung ist ein Framework eine Standardloesung fuer eine Klasse verwandter Probleme. Es entsteht, indem iterativ die generischen und spezifischen Aspekte einer Loesung voneinander getrennt und die generischen Aspekte als Ganzes wiederverwendbar gestaltet werden.

Die Objekttechnologie bietet die notwendigen Mechanismen, mit denen ein System als eine Menge kooperierender Objekte modelliert werden kann. Anwendungsspezifische Details koennen dabei hinter Objekt-Schnittstellen verborgen werden. Ein Framework besteht aus den Objekten, die die generischen Teile der Loesung realisieren, sowie aus den Schnittstellen der Objekte, die die anwendungsspezifischen Details implementieren. Ein Objekt, das sich hinter solch einer Schnittstelle verbirgt, kann spaeter durch ein anderes, welches die anwendungsspezifische Funktionalitaet realisiert, ersetzt werden.

Die Flexibilitaet und Generizitaet eines Frameworks beruht auf der Trennung von generischen und spezifischen Teilen. Waehrend die generischen konkret implementiert sind, wird bei der Einbindung der spezifischen Teile von der Art und Weise der Realisierung abstrahiert. Die Entwickler spezifizieren lediglich das, was getan werden soll.

Ein Framework ist folglich nicht nur eine Anzahl wiederverwendbarer Klassen. Es enthaelt auch eine generalisierte, wiederverwendbare Systemarchitektur fuer das jeweilige Anwendungsgebiet.

Das Macintosh-Framework "Macapps" beispielsweise beschreibt die Gemeinsamkeiten von interaktiven, dokumentbasierten Werkzeugen wie Text- und Grafik-Editoren. Daneben ist die gesamte Logik fuer das Oeffnen, Schliessen und Speichern von Dokumenten, fuer die Revision von Befehlen, fuer das Rollen und Splitten von Fenstern sowie fuer das Verwalten von Menuebalken enthalten.

Das Entwickeln eines Frameworks geschieht nicht linear. Fuer die Programmierer ist damit ein iterativer, zyklischer Lernprozess verbunden, bei dem sie auf der Basis von konkreten Loesungen neue Ideen fuer wiederverwendbare Abstraktionen finden. Die Qualitaet dieser Abstraktionen laesst sich leicht anhand des mehr oder weniger geringen Aufwands in einer neuen Anwendung ablesen. Mit guten Frameworks gelingt es haeufig, einen Wiederverwendungsgrad von 70 Prozent und hoeher zu erzielen.

Das Erarbeiten spezifischen Wissens ist in der Regel mit erheblichem Aufwand verbunden. Insofern dienen Frameworks zur Absicherung dieser Investitionen; denn waehrend frueher dieses Wissen zusammen mit den Entwicklern die Firma verliess, liegt es nun als abstrahierte, wiederverwendbare Software-Architektur vor.

Frameworks finden auf verschiedenen Ebenen Anwendung und koennen auf anderen basieren. Sie sind nicht darauf beschraenkt, das Zusammenspiel

der Objekte innerhalb eines Prozesses zu modellieren. Die Objekte koennen ueber mehrere Prozesse verteilt sein, wie bei den Frameworks zum Erstellen von OLE-2.0- oder Opendoc-Anwendungen.

Im Vergleich zu Funktionsbibliotheken, die Funktionen anbieten, um Algorithmen fuer einzelne Anwendungsgebiete zu realisieren, gehen Frameworks weiter. Sie kapseln die gesamte Architektur einer Standardloesung. Waehrend beim Einsatz einer Funktionsbibliothek die gesamte applikatorische Logik neu implementiert werden muss, kann diese durch ein Application-Framework zu einem grossen Teil wiederverwendet werden. Das hat zur Folge, dass sich der Benutzer nicht mehr darum kuemmern muss, wie das Framework gesteuert wird. Er passt es lediglich seinen spezifischen Beduerfnissen an.

Frameworks sind in Software gegossene Konzepte und Loesungen. Sie helfen einem Entwickler beim Modellieren seines Anwendungsgebiets und beim Erkennen der relevanten Beziehungen unter den Objekten, da die zentralen Objekte, Beziehungen und Schnittstellen bereits modelliert sind. Ein unerfahrener Entwickler ist in der Lage, Anwendungen zu schreiben, ohne das Sachgebiet vollstaendig verstanden zu haben. Er findet einen grossen Teil des Grundwissens als integralen Bestandteil des Frameworks.

Ein gutes Framework ermoeglicht Anwendungsentwicklung ohne den Zwang zu Kenntnissen ueber jedes Systemdetail. Einzelheiten zu Fenster- und Betriebssystemen, Interprozesskommunikation und Datenbanken sind typischerweise hinter domaenenspezifischen Schnittstellen vor dem Entwickler verborgen. Das Schreiben von OLE-2.0-faehigen Anwendungen auf Ebene von Application Programming Interfaces (APIs) ist ein extrem komplexes Unterfangen. Die Verwendung von Microsoft Foundation Classes (MFCs) erleichtert die Entwicklung hingegen erheblich. Ausserdem werden durch die Verwendung von Frameworks viele Fehlerquellen ausgeschlossen. Der Quelltext wurde bereits in mehreren Applikationen getestet.

Im Gegensatz zum linearen Software-Entwicklungsprozess, wie er etwa von Boehm mit seinem Wasserfallmodell beschrieben wurde, beruht die Framework-basierte Software-Entwicklung auf mehreren, sich gegenseitig beeinflussenden, zyklischen Entwicklungsprozessen (siehe Abbildung).

Die Entwickler des Frameworks sind auf Anregungen und Kritik der Anwendungsentwickler angewiesen, um zum einen Schwachstellen im Framework zu identifizieren, und zum anderen weitere generalisierbare Aspekte zu finden. Umgekehrt koennen die Anwendungsentwickler von Zeit zu Zeit auf neue Versionen des Frameworks wechseln und profitieren von dessen Weiterentwicklung.

Die Entwicklung von grossen und hochwertigen Frameworks ist langwierig und teuer. Investitionen rentieren sich erst mittelfristig. Zudem ist sie in vielen Faellen aufgrund mangelnder Erfahrung risikobehaftet. Zu fordern ist deshalb ein Umdenken in der Projektorganisation.

Zunaechst bedarf es eines Teams aus talentierten und erfahrenen Software-Entwicklern. Doch insbesondere begabte Programmierer werden haeufig von der technischen Arbeit wegbefoerdert, bevor sie genug Erfahrung gesammelt haben. Dies haengt damit zusammen, dass es in vielen Firmen kaum technische Karrieremoeglichkeiten gibt. Talentierte Leute werden dadurch geradezu ins Management gezwungen.

Darueber hinaus ist das konventionelle, am Wasserfallmodell ausgerichtete Projekt-Management an unmittelbare Zielvorgaben gebunden. Der Arbeitsfortgang sowie die Leistung der Entwickler werden an Meilensteinen gemessen. Diese Vorgehensweise verhindert jegliche Wiederverwendung der Software. Das Entwickeln, Bekanntmachen und Warten von wiederverwendbaren Bausteinen ist weder vorgesehen, noch wird es belohnt.

Dagegen stellt die Entwicklung auf der Grundlage bereits vorhandener Frameworks den herkoemmlichen Software-Lebenszyklus prinzipiell in Frage. Der hohe Grad an Wiederverwendbarkeit ermoeglicht es, bereits waehrend der Definitionsphase Prototypen zu bauen, die nach und nach in ein Produkt ueberfuehrt werden koennen. Vielfach lehnen Projekt-Manager dieses Vorgehen ab. Es kommt zu erheblichen Spannungen.

Ausserdem ist es schwierig, auf den ersten Blick faktorisierbare Aehnlichkeiten zwischen verschiedenen Projekten zu erkennen. Sinnvoll waere ein Team aus Framework-Entwicklern, die zeitweilig in verschiedenen Anwendungsprojekten mitarbeiten, um ihre Erfahrungen in das Framework einbringen zu koennen.

Einerseits fuehrt eine solche Arbeitseinteilung zu einem groesseren Kommunikations- und Koordinationsbedarf, andererseits zu einer Art Matrixorganisation. Diese laesst sich jedoch in den traditionell stark hierarchisch organisierten Entwicklungsabteilungen nur sehr schwer durchsetzen.

Frameworks koennen mit der Zeit betraechtlich an Reife gewinnen und verursachen immer wieder Anpassungen. Das erfordert von den Anwendungsentwicklern die notwendige Bereitschaft und vom Management das Verstaendnis fuer den erforderlichen Aufwand.