Vorteile der Softwareentwicklung mit Framework-Technologie

Gliederung

1 Das Prinzip der Wiederverwendung

2 Die Framework-Technologie
2.1 Die Framework-Idee
2.2 Auf bau und Entwicklung

3 Business Frameworks
3.1 Allgemeine Einteilung und Architektur
3.2 Microsoft Business Framework

4 Vorteile der Framework-Technologie

Quellenverzeichnis

1 Das Prinzip der Wiederverwendung

Bereits im Jahre 1968 wurde auf der „NATO Working Conference on Software Engineering“ festgestellt, dass es mit der damaligen Art der Software-Entwicklung mehrere Probleme gab. Eine Analyse hatte ergeben, dass es nicht genug Anwendungen für die geforderten Problemstellungen gab, die vorhandenen qualitativ zu schlecht und gleichzeitig zu teuer waren, während die Entwicklungsprojekte zu lange dauerten („Software-Krise“). Einen Ausweg sah man darin, sich bestimmte Sachen im Bereich des Maschinenbaus oder der Elektrotechnik abzuschauen, wo die Wiederverwendung von standardisierten Teilen erfolgreich eingesetzt wurde [STÜT02, S. 29]. McIllroy regte dies auf der Konferenz an [SPEC00, S. 15]:

„Software engineers should take a look at the hardware industry and establish a software component subindustry. The produced software components should be tailored to specific needs but be reusable in many software systems.”

Als man sich später mit dem Thema intensiver auseinander setzte, stellte man die Folgerung auf, dass die niedrige Produktivität und Qualität der Anwendungen im wesentlichen darauf zurückzuführen sei, dass nur sehr wenig im Bereich der Software-Entwicklung erneut verwendet wurde [STÜT02, S. 29]. Meistens werden heute Anwendungen komplett neu entwickelt, obwohl sich die Anforderungen an diese oft ähneln [BIRR95, S. 1]. Der Wiederverwendungsgedanke dagegen besagt, dass man bereits vorhandene Anwendungen bei der Entwicklung miteinbezieht, anstatt alles neu zu planen [STÜT02, S. 11]. Dies bedeutet, dass nun nicht mehr darauf abgezielt wird, große Programme aus einem Guss zu fertigen, sondern der Fokus eher auf die Erstellung kleinerer wiederverwendbarer Bausteine liegen sollte, die anschließend zusammengesetzt werden können [RÜPI97, S. 30]. Dies wird vor allem durch objektorientierte Methoden und die Framework-Technologie unterstützt [SPEC00, S. 15].

Im weiteren Verlauf dieser Arbeit wird nun insbesondere auf die Softwareentwicklung mit Frameworks und ihrer Vorteile eingegangen. Dazu wird zunächst der Gedanke erläutert, der dahinter steht, und anschließend auf den Bereich der Business Frameworks Bezug genommen, wobei hier das Microsoft Business Framework (MBF) näher betrachtet wird. Zum Schluss werden dann einige Gründe genannt, warum es für die Unternehmen lohnend sein kann, auf diese Technologie zu setzen.

2 Die Framework-Technologie

2.1 Die Framework-Idee

Zunächst einmal bleibt zu sagen, dass es in der Literatur keine allgemein akzeptierte Definition des Framework-Begriffs gibt. Generell gilt jedoch, dass ein Framework eine wiederverwendbare Entwurfsmöglichkeit für ähnliche Anwendungen bietet [MAIE98, S. 2]. Dabei handelt es sich um eine Ansammlung zusammenarbeitender Klassen, durch die verschiedene Softwarelösungen mit ähnlicher Funktionalität dargestellt werden können. Darüber hinaus legt ein Framework auch die Architektur bzw. das Design dieser Anwendungen fest [GAMM04, S. 37]. Bei dieser handelt es sich um die Komposition der einzelnen vorgefertigten oder halbfertigen Software-Komponente und deren Interaktion untereinander. Durch die Anpassung dieser Komponente kann man schließlich spezielle Anwendungen bzw. Teilausschnitte entwickeln [SPEC00, S. 15]. Dies wird dadurch ermöglicht, dass einige dieser Komponente so angelegt sind, dass man sie austauschen kann [PREE97, S. 7].

Frameworks bieten also somit eine Art Standart für Anwendungen eines speziellen Funktionsbereichs, da sie aus gebrauchsfertigen Komponenten, die jedoch teilweise noch vervollständigt werden müssen, bestehen und eine bestimmte Architektur vorgeben. Dabei spielt die Wiederverwendung in Form von wiederholter Zusammenstellung und Anpassung der Komponente für jeweils ähnliche Anwendungsprobleme eine große Rolle [PREE97, S. 39]. Dafür werden die Stellen definiert, an denen das Framework angepasst bzw. erweitert werden kann [BIRR95, S. 1]. Pree hält den Aspekt, dass alle aus einem Framework heraus entwickelten Lösungen den gleichen vorgegebenen Architekturentwurf verwenden, für die wichtigste Charakteristik von Frameworks überhaupt [PREE97, S. 8].

2.2 Aufbau und Entwicklung

Wie man im vorangegangenen Abschnitt erkennen konnte, beinhalten Frameworks Komponente, die für die Anpassung bzw. Erweiterung vorgesehen sind. Diese Stellen, die man Hot Spots nennt, bilden also den flexiblen Teil des Frameworks. Die Komponente des Frameworks, die dagegen nicht veränderbar sind, nennt man Frozen Spots. Im Gegensatz zu den Hot Spots sollten diese einen größeren Anteil im Framework darstellen, da sie die Komponenten sind, die für die Wiederverwendung vorgesehen sind [PREE97, S. 7, SPEC00, S. 17]. In Abbildung 1(a) sieht man an einem Beispiel die Abgrenzung zwischen den beiden Spots am Beispiel der Einbindung einer anwendungsspezifischen Klasse („User Class“) in das Framework.

Die Klassen des unveränderlichen Teils werden durch den Frozen Spot repräsentiert. Der Hot Spot besteht aus einem Subsystem mit verschiedenen Arten von Klassen. Den Übergang zum Frozen Spot bildet die Schablonenklasse (Template). Sie definiert somit die Stelle im Framework, an welcher der Hot Spot liegt, und enthält eine sogenannte Schablonenmethode (Template Method), welche die Hot Spot Klassen aufruft. Eine Einschubklasse (Hook), bildet die Schnittstelle zwischen dem Framework selber und der Klassen, die vom Anwender geschrieben wurde. In diesem Fall handelt es sich um die vom Anwender geschriebene Klasse „User Class“, die speziell für die zu erstellende Anwendung geschrieben wurde. Die Anpassung oder Erweiterung des Frameworks geschieht nun durch Überschreibung der Methoden der Einschubklasse (Hook Method), welche speziell dafür vorgesehen sind, durch diese anwendungsspezifische Klasse. Diese Art der Anpassung, bei der die Schablonen- und die Einschubklasse getrennte Klassen darstellen, nennt man „Anpassung durch Komposition“. Somit wird der Code, den der Anwender geschrieben hat, von dem Rest des Frameworks getrennt. Es existiert aber auch noch eine andere Art der Flexibilisierung („Anpassung durch Vererbung“). Bei dieser sind die beiden zu einer einzigen Klasse zusammengefasst (vgl. Abb. 1(b)), wobei auch hier die Anpassung durch Überschreibung der Einschubklasse erreicht. Durch die Zusammenfassung ist das Framework für Fehler des Anwenders anfällig, während er im ersten Fall nicht auf dieses einwirken kann [SPEC00, S. 17ff.; PREE97, S. 39ff.; MAIE98, S. 2].

Grundsätzlich kann man Frameworks in zwei Gruppen unterscheiden. Whitebox-Frameworks (oder auch Gerüste) zeichnen sich dadurch aus, dass bei ihnen neue konkrete Unterklassen der abstrakten Basisklassen entwickelt werden und dadurch unvollständig spezifizierte Methoden (abstrakte Methoden) überschrieben werden. Der Anwender passt das Framework also auf die vorgegebene Problemstellung durch Überschreibung der Einschubmethoden bzw. durch Vervollständigung der Hot Spots an. Da der Anwender dafür aber programmieren muss, gilt diese Art der Flexibilisierung als sehr aufwendig. Zudem muss er wissen, wo überhaupt die Stellen im Framework liegen, an denen er ansetzen kann, was eine genauere Kenntnis der Struktur durch Einarbeitung in das Framework bedeutet [BIRR95, S. 2; MAIE98, S. 2; PREE97, S. 19f.; SCHM01, S. 9].

Blackbox-Frameworks (Baukästen) besitzen dagegen keine unfertigen Klassen. Sie basieren auf fertiggestellten Komponenten, die durch Komposition an verschiedene Problemstellungen angepasst werden. Diese Klassen sind direkt benutzbar und müssen somit nicht mehr durch Programmierung verändert werden. Für die notwenige Anpassung genügt dem Anwender die Kenntnis der Schnittstellen der betreffenden Klassen (Hot Spots). Er muss sich somit nicht mit dem Aufbau des kompletten Frameworks beschäftigen, wodurch der Aufwand geringer ausfällt, als bei dem vorhergehenden Ansatz [BIRR95, S. 2; MAIE98, S. 2; PREE97, S. 20; ].

Im Vergleich kann man sagen, dass die Whitebox-Frameworks flexibler sind und weitgehendere Anpassungen zulassen, die dafür aber auch mit mehr Aufwand verbunden sind [BIRR95, S. 2]. Blackbox-Frameworks haben dagegen jedoch den Vorteil, dass sie während der Laufzeit geändert werden können, indessen bei den Whitebox-Frameworks die Anwendung vollständig runtergefahren werden muss [MAIE98, S. 2]. In der Praxis findet man jedoch fast ausschließlich Mischformen dieser beiden Konzepte vor (Greybox-Frameworks), da sich die anfänglichen Whitebox- mit zunehmender Wiederverwendung zu Blackbox-Frameworks entwickeln [PREE97, S. 20f.; SPEC00, S. 20]. Dies hat auch mit dem iterativen Entwicklungsprozess zu tun, der als nächstes angesprochen werden soll.

[...]