In diesem Abschnitt soll die Wiederverwendung durch Frameworks und Software-Architekturen betrachtet werden. Der Framework Begriff ( frame : Rahmen, Gerüst ), wird häufig mit unterschiedlichen Bedeutungen belegt. Die Abgrenzung, was ist ein Framework und was nicht, ist allerdings auch nicht so klar zu ziehen, wie bei den vorhergegangenen Wiederverwendungsmethoden. Daher sollen zunächst einige Autoren zum Thema Frameworks zitiert werden:
"Framework: a semifinished software architecture that can be adapted to specific need by applying object-oriented programming concepts ..." [Pree, 1994, S. 253]
"A framework is a collection of abstract and concrete classes and the interface between them ..." [Chen, D.J. & CHen, T.K, S.56]
"A framework is a set of cooperating classes that make up a reusable design for a specific class of software. The framework dictates the architecture of your application." [Gamma et at., 1995, S. 26]
"Ein Framework besteht aus einer Menge von Objekten, die eine generische Lösung für eine Reihe verwandter Probleme implementieren." [Birrer et al., 1995, S. 18]
Frameworks bestehen aus mehreren interagierenden Softwarekomponenten. Dies sind vornehmlich die Klassen der objektorientierten Programmierung. Einige dieser Klassen sind dabei noch abstrakt gehalten und müssen mit Hilfe der objektorientierten Methoden vom Entwerfer vervollständigt werden. Der Softwareentwickler implementiert die erforderliche Funktionalität der abstrakten Klassen und erstellt somit das gewünschte Teilsystem. Ein Framework stellt eine Art vordefinierten Rahmen dar, indem anwendungspezifische Details integriert werden. Dabei stellt ein Framework die Infrastrukturen und Konzepte eines bestimmten Anwendungsbereichs zur Verfügung.
Dem gegenüber stehen die Software-Architekturen, die eher feste Strukturen aufweisen und als monolithische Blöcke miteinander interagierender Komponenten anzusehen sind, deren Eigenschaften nur wenig beeinflußt werden können.
"Reusable software architectures are large-grain software frameworks and subsystems that capture the global structure of a software system design." [Krueger, 1992, S. 173]
"Software architecture: several interacting software components." [Pree, 1994, S. 254]
In einem Framework werden häufig auftretende Entwurfsprobleme und Entwurfsentscheidungen eines Anwendungsbereiches zusammengefaßt. Wiederverwendung findet hierbei auf der Ebene des Entwurfs und mit den enthaltenen, konkreten Komponenten statt. Softwareentwickler, die ein Framework benutzen, ergänzen nur die abstrakt gehaltenen Stellen eines Frameworks mit anwendungsspezifischen Details.
Heutzutage werden Software-Architekturen und Frameworks meist mit der Objektorientierung verbunden. Die Komponenten eines Frameworks bestehen dann aus konkreten und abstrakten Klassen einer objektorientierten Programmiersprache. Die Modellierung eines Systems ist aber generell unabhängig von der später verwendeten Sprache. In Abbildung94 wird ein Framework für ein Mailsystem nach Wolfgang Pree [Pree, 1994] dargestellt.
Abbildung 9: Mailing framework [Pree, 1995]
Die Klasse Mailer implementiert mit Hilfe der abstrakten Klassen Employee und DesktopItem ein allgemeines Mailsystem. Alle Objekte der Klassen, die von Employee und DesktopItem abgeleitet sind, können in diesem System bearbeitet werden. Dieses Framework kann durch Hinzufügen neuer Klassen auf neue Employee -Typen bzw.neue Mailobjekte erweitert werden (Vererbung). Zudem ist auch die Modifikation des allgemeinen Mailvorgangs möglich, indem man eine Unterklasse von Mailer bildet und in ihr die benötigten änderungen realisiert. Weitere Konzepte der Objektorientierung, wie z.B. Polymorphie und dynamisches Binden können ebenfalls zum Einsatz kommen. Dadurch wird eine modulare Softwarearchitektur, wie in Abbildung 10 dargestellt, erst möglich.
Abbildung 10: Modulare Softwarearchitektur mit Frameworks [Pree, 1995]
Die Vorteile bei der Wiederverwendung durch Frameworks liegen zum einen im Umfang der Wiederverwendung (mehrere interagierende Klassen), zum anderen an der Möglichkeit der Modifizierung und Anpassung an die spezielle Aufgabe. Die objektorientierten Konzepte, die OO-Modellierungsmethoden und OO-Programmiersprachen bilden die dazu benötigten Grundlagen. Weitaus gewichtiger ist die Wiederverwendung von Entwurfsstrategien. Strukturen, die sich als gut erwiesen haben, werden immer wieder verwendet.
Die meisten der erfolgreichen Frameworks sind im Bereich der graphischen Benutzungsschnittstellen angesiedelt, wie z.B. Visual Works (Parc Place Systems) oder die Microsoft Foundation Class Library . Dabei zeigt sich direkt ein Problem bei der Anwendung von Frameworks. Obwohl die oben genannten dem gleichen Zweck dienen, der Erstellung von Anwendungen für graphische Benutzungsschnittstellen, sind sie doch sehr verschieden. Jedes Framework muß vor seiner erfolgreichen Anwendungen zunächst erlernt werden. Dies ist bei dem Funktionsumfang und der Gestaltungsvielfalt heutiger Oberflächen keine leichte Aufgabe.
Die wohl bekannteste Software-Architektur ist das Model-View-Controller Modell, das zunächst als "Programmiertrick" in der Programmiersprache Smalltalk benutzt wurde und mittlerweile zum Standardarchitektur für die graphische Benutzungsschnittstellen avanciert ist. Das Prinzip des Model-View-Controller Modells, das in Abbildung 115 dargestellt wird, ist die Trennung der Verantwortlichkeiten. Die Funktionalität der Anwendung wird von der Darstellung der Information und der Verarbeitung von Benutzereingaben abgetrennt. Nachfolgend werden die Aufgaben der Teilsysteme kurz erläutert.
Abbildung 11: ModView {Das Model-View-Controller Modell
Das Model-Subsystem beinhaltet den Anwendungskern. Es stellt den Zugriff auf die spezifischen Anwendungsdaten zur Verfügung. Nicht enthalten sind die Möglichen Darstellungsformen (Views) und die Reaktion auf Benutzereingaben (Conroller).
Das View-Subsystem erzeugt und verwaltet die möglichen Sichten auf die Anwendung und erzeugt die entsprechende Anzeige. Die notwendigen Daten werden dazu vom Model geliefert.
Das Controller-Subsystem verarbeitet Benutzereingaben und setzt sie in Aufrufe an das Model bzw.das View-Subsystem um.
Durch die Strukturierung eines Softwaresystems in Mode, View und Controller ergeben sich mehrere Vorteile. Änderungen an einem der drei Teilsysteme wirken sich nicht oder nur im geringen Maße auf die anderen Teilsysteme aus. Auch nach Fertigstellung der Anwendung ist es mit Hilfe der objektorientierten Methoden möglich, noch weiter Sichten auf die Daten im Modell hinzuzufügen oder die Reaktion der Software auf Benutzereingaben abzuändern. Das Model ist prinzipiell unabhängig vom Rest und kann für alle Betriebsystemplattformen identisch sein, was zur besseren Portierbarkeit führt. Auf dieser Stelle stellt sich jedoch die Frage, wie die Kommunikation zwischen den Teilen realisiert werden kann, wobei gleichzeitig die Unabhängigkeit der Teile bestehen bleiben kann. Auf diese und ähnliche Entwurfsprobleme wird im Kapitel 3 "Entwurfsmuster und Wiederverwendung" eingegangen.
Die Wieververwendbarkeit von und durch Frameworks wird durch die Verfügbarkeit der Frameworks und deren beschränkten Einsatzfähigkeit begrenzt. Für jedes unterschiedliche Anwendungsgebiet, müssen zunächst einmal die Grundlagen erarbeitet und danach generische Frameworks entwickelt werden. Die Aufgabenbereiche sind dabei nicht austauschbar. Jedes Gebiet erhält sein eigenes spezifisches Framework . In jedem Framework stecken langjährige Erfahrungen und viele Stunden Entwicklungsarbeit. Der Aspekt der Erfahrung aber, d.h.der Wiederverwendung von Wissen, soll durch die Entwurfsmuster abgedeckt werden.
Dieses Kapitel konnte nur einen kleinen Teil der in der Literatur zitierten und in der Praxis angewendeten Wiederverwendungsmethoden bringen. Es wurden exemplarisch die wichtigsten vorgestellt, an der sich die große Bandbreite der Wiederverwendungsmethoden abschätzen läßt.
Klar wurde jedoch, welche unterschiedlichen Ansätze die Methoden zur Wiederverwendung bieten. Dabei reicht das Spektrum von der Wiederverwendung im Kleinen , mit Hochsprachen und Quellcode-Komponenten, über Software-Schemata, Frameworks und Software-Architekturen bis hin zur Automatisierung der Wiederverwendung mit Hilfe von Applikationsgeneratoren. Gleichzeitig überstreicht das Angebot der Methoden den Bereich von allgemein anwendbar (Hochsprachen) bis hin zu sehr spezialisiert (Applikationsgeneratoren).
Diese unterschiedlichen Aspekte der Wiederverwendungsmethoden, rechtfertigen die folgende Abbildung 12 . Sie zeigt eine mögliche Einordnung der vorgestellten Methoden bezüglich ihrer allgemeinen Verwendbarkeit (Generality) und dem Wiederverwendungsgewinn (Power) nach Ted J. Biggerstaff und Charles Richter [Biggerstaff & Perlis (Hrsg.), 1989a] . Dabei sei die Graphik nur als Anhaltspunkt gedacht. Sie soll die relativen Unterschiede zwischen den Wiederverwendungsarten visualisieren. Zur Orientierung sind weitere in der Literatur verbreitete Methoden aufgenommen worden (grau dargestellt), um ein besseres Gesamtbild erzeugen zu können.
Abbildung 12: Charakterisierung der Wiederverwendungsarten nach [Biggerstaff & Richter, 1989c]
Alle vorgestellten Wiederverwendungsarten (Hochsprachen, Quellcode-Komponenten, Software-Schemata, Applikationsgeneratoren und Software-Architekturen und Frameworks) sind heute mehr oder weniger im Einsatz. Sie bauen aufeinander auf, z.B. bestehen die Komponenten eines Frameworks aus Softwarekomponenten und diese sind wiederum in Hochsprachen realisiert. Somit steht kaum eine Methode für sich isoliert, sondern wird meist in Verbindung mit anderen verwendet. Auch deshalb ist eine deutliche Trennung nicht immer möglich.
Die vorgestellten Methoden erlauben die Wiederverwendung und bieten unterschiedliche Unterstützung. Es entsteht aber nicht automatisch gute und wiederverwendbare Software. Statt die Möglichkeiten von Quellcode-Komponenten in Anspruch zu nehmen, kann eine Anwendung auch als ein monolithischer Block erstellt werden, dessen Einzelteile untrennbar miteinander verbunden sind. Der Erfolg bei der Softwareentwicklung ist daher von den Erfahrungen und der Einstellung der beteiligten Entwickler und des Managements abhängig. Die besten Werkzeuge und Methoden sind sinnlos, wenn sie wegen fehlender Erfahrung im Umgang damit nicht richtig eingesetzt werden. Dieses Erfahrungswissen soll im folgenden Kapitel durch die Entwurfsmuster vermittelt werden können. Wie unterscheiden sich Entwurfsmuster von den bisher vorgestellten Methoden? Sind sie etwas gänzlich Neues? Wie sind sie in das bisher gezeigte einzuordnen?