imported>Lustiger seth: großflächig: enyklopädischere Formulierugen, Kürzungen

2026-01-11T00:26:30Z

großflächig: enyklopädischere Formulierugen, Kürzungen

Neue Seite

{{Dieser Artikel|beschäftigt sich mit Programmiergerüsten in der Softwaretechnik. Zum Office-Paket siehe [[Framework (Office-Paket)]].}}

Ein {{lang|en|'''Framework'''}} ({{enS}} für ''Rahmenstruktur'') ist ein Programmiergerüst, das in der [[Softwaretechnik]] eingesetzt wird – insbesondere in der [[Objektorientierte Programmierung|objektorientierten]] [[Softwareentwicklung]] sowie in [[Komponentenmodell|komponentenbasierten]] Ansätzen.

== Beschreibung ==
Ein {{lang|en|Framework}} ist kein eigenständiges Programm, sondern stellt eine Struktur bereit, innerhalb derer Entwickler Anwendungen erstellen. Durch die im {{lang|en|Framework}} verwendeten [[Entwurfsmuster]] beeinflusst es typischerweise auch die [[Softwarearchitektur|Architektur]] der entstehenden Software. So unterstützen etwa die [[Microsoft Foundation Classes]] das [[Model View Controller|{{lang|en|Model-View-Controller}}]]-Muster.

Ralph E. Johnson und Brian Foote beschrieben ein Framework 1988 im Artikel ''Designing Reusable Classes'' im ''Journal of Object-Oriented Programming'' als:
{{Zitat|Ein Framework ist eine semi-vollständige Applikation. Es stellt für Applikationen eine wiederverwendbare, gemeinsame Struktur zur Verfügung. Die Entwickler bauen das Framework in ihre eigene Applikation ein und erweitern es derart, dass es ihren spezifischen Anforderungen entspricht. Frameworks unterscheiden sich von Toolkits dahingehend, dass sie eine kohärente Struktur zur Verfügung stellen, anstatt einer einfachen Menge von Hilfsklassen.|ref=<ref>Ralph E. Johnson, Brian Foote: “Designing Reusable Classes” im "Journal of Object-Oriented Programming" (1988); "A framework is a semi-complete application. A framework provides a reusable, common structure to share among applications. Developers incorporate the framework into their own application and extend it to meet their specific needs. Frameworks differ from toolkits by providing a coherent structure, rather than a simple set of utility classes."; Quelle: Petar Tahchiev, Felipe Leme, Vincent Massol: JUnit in Action, 2. Auflage, broschiert, Manning Publications, 2010, ISBN 1935182021, Seite 4</ref>}}

Frameworks geben in der Regel die grundlegende Anwendungsarchitektur vor. Charakteristisch ist dabei die ''({{lang|en|[[Inversion of Control]]}})'' (Umkehrung der Steuerung): Programmierer registrieren konkrete [[Implementierung]]en, die anschließend vom {{lang|en|Framework}} aufgerufen und verwaltet werden. Wird diese Registrierung nicht im Quellcode festgelegt, sondern extern konfiguriert, spricht man von ''{{lang|en|[[Dependency Injection]]}}''.

Ein {{lang|en|Framework}} definiert insbesondere den [[Kontrollfluss]] einer Anwendung sowie die [[Schnittstelle]]n, die konkrete Klassen implementieren müssen. Es dient damit der Wiederverwendung bewährter architektonischer Muster. Da solche Muster stets auf eine bestimmte [[Problemdomäne]] zugeschnitten sind, sind {{lang|en|Frameworks}} meist domänenspezifisch oder auf bestimmte Anwendungstypen beschränkt – etwa grafische Editoren, Buchhaltungssysteme oder [[Webshop]]s.

Eine allgemeingültige Definition existiert nicht, da Frameworks sehr unterschiedlich ausgeprägt sein können. Der Begriff wird daher häufig unscharf verwendet; mitunter werden bereits umfangreiche [[Klasse (Objektorientierung)|Klassensammlungen]] als Framework bezeichnet.

== {{lang|en|White-Box}}- und {{lang|en|Black-Box-Frameworks}} ==

Die Unterscheidung zwischen {{lang|en|White-Box}}- und {{lang|en|Black-Box}}-Frameworks bezieht sich auf die Sichtbarkeit und Zugänglichkeit der Implementierung hinter einer Schnittstelle.

* Bei einer {{lang|en|Black-Box}}-Abstraktion kennen Klienten nur die Spezifikation der Schnittstelle, nicht jedoch deren interne Umsetzung.
* Bei einer {{lang|en|White-Box}}-Abstraktion ist die Implementierung einsehbar und kann durch Vererbung erweitert werden, auch wenn die Schnittstelle weiterhin eine gewisse Kapselung erzwingt.

Einige Autoren unterscheiden zusätzlich zwischen {{lang|en|White-Boxes}} (Erweiterung möglich) und {{lang|en|Glass-Boxes}} (nur Einsicht möglich).<ref name="Component Software">{{Literatur |Autor=Clemens Szyperski, Dominik Gruntz, Stephan Murer |Titel= {{lang|en|Component Software. Beyond object-oriented programming}} |Auflage=2. |Verlag=Addison-Wesley |Ort=London; München |Jahr=2002 |Seiten=40f |ISBN=0-201-74572-0}}</ref>

== {{lang|en|Framework}}-Typen ==

{{lang|en|Frameworks}} lassen sich – ohne strikte Abgrenzung – in folgende Kategorien einteilen:

; {{lang|en|Application Frameworks}}
: bilden das Programmiergerüst für eine bestimmte Klasse von Anwendungen ''({{lang|en|horizontal slice}})'', die grundlegende [[Funktion (Programmierung)|Funktionen]] und [[Programmstruktur]]en bereitstellen.

; {{lang|en|Domain Frameworks}}
: bilden das Programmiergerüst für einen spezifischen Problembereich ''({{lang|en|vertical slice}})'', das typische Funktionen und Strukturen dieser Domäne bündelt.

; {{lang|en|Class Frameworks}}
: fassen Klassen und Methoden zusammen, die Unterstützung auf einer bestimmten Abstraktionsebene für ein breites Anwendungsspektrum bieten.

; Komponenten-{{lang|en|Frameworks}}
: abstrahieren von der objektorientierten Ebene und stellen eine Umgebung zur Entwicklung und Integration von Software-Komponenten bereit. Software-Komponenten werden dabei meist als Bündel von Klassen mit eindeutig definierten Schnittstellen betrachtet.

; {{lang|en|Coordination Frameworks}}
: (wie [[Jini]] und [[Universal Plug and Play|UPnP]]) ermöglichen die Interaktionen zwischen Geräten und unterstützen deren Interoperabilität. Wenn beispielsweise ein „Jini-fähiger“ Drucker an ein Netzwerk angeschlossen wird, welches Jini verwendet, so kann er selbständig anderen Geräten mitteilen, was für eine Art von Drucker dazugekommen ist.

; {{lang|en|Test Frameworks}}
: dienen zur Ausführung automatisierter [[Softwaretest]]s, etwa [[JUnit]] für [[Unit test|Modultests]] oder [[Selenium]] für [[Webanwendung]]en.

; [[Webframework]]s
: sind ausgelegt für die Entwicklung dynamischer Websites, Webanwendungen oder Webservices.

== Bekannte Frameworks ==
Aufgrund der uneinheitlichen Begriffsverwendung ist die Zuordnung einzelner Systeme nicht immer eindeutig. Beispiele sind:

* [[.Net-Framework]] von Microsoft
* [[1C:Enterprise]]
* [[ADAPTIVE Communication Environment|ACE]]
* [[BMC Remedy Action Request System|Action Request System]] (ARS) – Application Framework von BMC Remedy
* [[Adobe Flex]]
* [[Angular]]
* [[AngularJS]]
* [[Apache Spark]]
* [[Bootstrap (Framework)|Bootstrap]] Framework von Twitter
* [[Cocoa (API)|Cocoa]]
* [[CakePHP]]
* [[Django (Framework)]]
* [[Drupal]]
* [[Eclipse RCP|Eclipse Rich Client Platform]]
* [[TYPO3 Flow]]
* [[Grails]]
* [[Horde (Framework)]]
* [[JavaServer Faces]]
* [[JBoss Seam]]
* [[JHotDraw]]
* [[JUnit]]
* [[Laravel]]
* [[NetBeans IDE|OpenIDE RCP]]
* [[Microsoft Foundation Classes]]
* [[Qt (Bibliothek)|Qt]]
* [[Robot Framework]]
* [[Robot Operating System]]
* [[Ruby on Rails]]
* [[Selenium]]
* [[Spring (Framework)]]
* [[Struts]]
* [[Symfony]]
* [[Visual Component Library]] (VCL) – Komponentenbibliothek von Borland
* [[WoltLab Community Framework]] (WCF) – PHP-Framework
* [[YAML (Framework)]] CSS-Framework
* [[Yii]]
* [[Zend Framework]]

== Literatur ==
* {{Literatur |Autor=Wolfgang Pree |Titel=Komponentenbasierte Softwareentwicklung mit Frameworks |Verlag=dpunkt |Jahr=1997 |ISBN=3-920993-68-3}}
* {{Literatur |Autor=Krzysztof Cwalina, Brad Abrams |Titel=Richtlinien für das Framework-Design – Konventionen, Ausdrücke und Muster für wiederverwendbare .NET-Bibliotheken |Verlag=Addison-Wesley |Jahr=2007 |ISBN=3-827326-26-5}}

== Einzelnachweise ==
<references />

{{Normdaten|TYP=s|GND=4464685-9}}

[[Kategorie:Programmbibliothek| ]]
[[Kategorie:Softwarearchitektur]]

Framework - Versionsgeschichte

imported>Lustiger seth: großflächig: enyklopädischere Formulierugen, Kürzungen