Dieser Artikel beschäftigt sich mit Frameworks in der Softwaretechnik, für die Office-Suite Framework siehe Framework (Software).

Dieser Artikel oder Abschnitt bedarf einer Überarbeitung. Näheres ist auf der Diskussionsseite angegeben. Hilf bitte mit, ihn zu verbessern, und entferne anschließend diese Markierung.

Ein Framework (engl. für „Rahmenstruktur, Fachwerk“) ist ein Programmiergerüst, welches in der Softwaretechnik insbesondere im Rahmen der objektorientierten Softwareentwicklung sowie bei komponentenbasierten Entwicklungsansätzen verwendet wird.

[Bearbeiten] Beschreibung

Ein Framework ist selbst noch kein fertiges Programm, sondern stellt den Rahmen, innerhalb dessen der Programmierer eine Anwendung erstellt, zur Verfügung, wobei u. a. durch die in dem Framework verwendeten Entwurfsmuster auch die Struktur der individuellen Anwendung beeinflusst wird. Beispielsweise unterstützten die MFC das Model-View-Controller-Muster.

Das Framework steht mit dem Software-Paket und der Software-Komponente in Beziehungen, unterscheidet sich aber von diesen in einigen wichtigen Punkten.

Ein Framework gibt somit in der Regel die Anwendungsarchitektur vor. Dabei findet eine Umkehrung der Steuerung (Inversion of Control) statt: Der Programmierer registriert konkrete Implementierungen, die dann durch das Framework gesteuert und benutzt werden, statt – wie bei einer Klassenbibliothek – lediglich Klassen und Funktionen zu benutzen. Wird das Registrieren der konkreten Klassen nicht fest im Programmcode verankert, sondern wird „von außen“ konfiguriert, so spricht man auch von Dependency Injection.

Ein Framework definiert insbesondere den Kontrollfluss der Anwendung und die Schnittstellen für die konkreten Klassen, die vom Programmierer erstellt und registriert werden müssen. Frameworks werden also i. A. mit dem Ziel einer Wiederverwendung „architektonischer Muster“ entwickelt und genutzt. Da solche Muster nicht ohne die Berücksichtigung einer konkreten Anwendungsdomäne entworfen werden können, sind Frameworks meist domänenspezifisch oder doch auf einen bestimmten Anwendungstyp beschränkt. Beispiele sind Frameworks für grafische Editoren, Buchhaltungssysteme oder elektronische Warenhäuser im World Wide Web.

[Bearbeiten] White-Box- und Black-Box-Frameworks

Die Blackbox- und Whitebox-Abstraktion bezieht sich auf die Sichtbarkeit einer Implementierung hinter der Schnittstelle. In einer idealen Blackbox-Abstraktion wissen Klienten keine Details, die sich hinter der Schnittstelle und seiner Spezifikation befinden. In einer Whitebox-Abstraktion kann die Schnittstelle immer noch die Kapselung erzwingen und begrenzen, was die Klienten tun können, obwohl die Implementierung das Erben substanzieller Interferenzen erlaubt. Wie auch immer, die Implementierung einer Whitebox ist vollständig vorhanden und kann deswegen studiert werden, um das Darunterliegende genauer zu verstehen, was die Abstraktion ausmacht. (Einige Autoren unterscheiden weiterhin zwischen Whiteboxes und Glassboxes, wobei die Whitebox die Manipulation der Implementierung erlaubt und Glassboxes lediglich das Studieren der Implementierung.)^[1]

[Bearbeiten] Framework-Typen

Frameworks lassen sich darüber hinaus wie folgt unterteilen (z.T. keine strikte Trennung):

• Application Frameworks bilden das Programmiergerüst für eine bestimmte Klasse von Anwendungen (horizontal slice), d. h. von Funktionen und Programmstrukturen, die bei allen Anwendungen dieser Klasse von Bedeutung sind.
• Domain Frameworks hingegen bilden das Programmiergerüst für einen bestimmten Problembereich (vertical slice), d. h. Funktionen und Strukturen, die zur Lösung dieses Problembereichs i. A. benötigt werden.
• Class Frameworks fassen Klassen und Methoden zusammen, die Unterstützung auf einer bestimmten Abstraktionsebene für ein breites Anwendungsfeld bieten.
• Komponenten-Frameworks abstrahieren von der objektorientierten Ebene und bieten eine Umgebung zur Entwicklung und Integration von Software-Komponenten an. Software-Komponenten werden dabei meist als Bündel von Klassen mit eindeutig definierten Schnittstellen betrachtet.
• Coordination-Frameworks (wie z. B. Jini und UPnP) stellen Formen und Einrichtungen der Geräte-Interaktion zur Verfügung und dienen so in erster Linie deren nahtloser und skalierbarer Interoperabilität. Wenn z. B. ein „Jini-fähiger“ Drucker an ein Netzwerk angeschlossen wird, welches Jini verwendet, so kann er selbstständig anderen Geräten mitteilen, was für eine Art von Drucker dazugekommen ist – so dass andere Geräte sich jetzt dieser neuen Möglichkeit „bewusst“ sind.

[Bearbeiten] Siehe auch

• Plugin
• Komponente
• Content Management Framework

[Bearbeiten] Literatur

• Wolfgang Pree: Komponentenbasierte Softwareentwicklung mit Frameworks. dpunkt, 1997, ISBN 3-920993-68-3.

[Bearbeiten] Einzelnachweise

1. ↑ Clemens Szyperski, Dominik Gruntz, Stephan Murer: Component Software. Beyond object-oriented programming. 2. Auflage. Addison-Wesley, London; München 2002, ISBN 0-201-74572-0, S. 40f.