Von Componentware zum Framework-Konzept

Der Weg zur Standardsoftware mit Workflow-Steuerung

13.03.1998

Als klassische Standardsoftware werden transaktionsgetriebene, integrierte Anwendungssysteme bezeichnet. Da diese häufig auch programmtechnisch integriert sind und eine fest programmierte Ablaufsteuerung enthalten, sind sie nur bedingt für einen Workflow-gesteuerten Ansatz geeignet. Sofern die Systeme aber modular aufgebaut sind und beispielsweise eine Schnittstelle zum Remote Procedure Call (RPC) anbieten, kann das Workflow-System den Aufruf dieser Module oder Transaktionen übernehmen. R/3 etwa bietet ein solches Interface mit dem Remote Function Call (RFC).

Wird ein unabhängiges Workflow-System zur Steuerung eingesetzt, wird die Standardsoftware jedoch in ihre Bearbeitungsfunktionalität und in den vom Workflow übernommenen Kontrollfluß zerlegt, so daß der Hersteller nicht mehr für die Integrität der gesamten Lösung verantwortlich sein kann.

Um dennoch den Gedanken der Flexibilisierung aufnehmen zu können, setzen Anbieter von Standardsoftware eigenentwickelte Workflow-Systeme zur Ablaufsteuerung ein. Diese sind aber häufig sehr eng mit dem System verbunden und erfüllen deshalb nicht die Forderung nach einer auch heterogene Lösungen umfassenden Prozeßsteuerung.

Der erhebliche Wartungsaufwand physisch hoch integrierter Pakete, deren schwerfällige Release-Politik auf Basis des Gesamtsystems und der hohe Aufwand für Schulungs- und Dokumentationsunterlagen machen es notwendig, die Software in kleinere Einheiten (Module, Komponenten, Agenten, Business Objects) zu zerlegen. Die Release-Strategie kann dann auf der Basis dieser Komponenten erfolgen, die Systeme sind wegen ihrer losen Kopplung einfacher zu warten und die Dokumentationen besser zu pflegen.

Die Zerlegung einer Software in Module ist nicht neu. Ein Modul bietet seinem Benutzer eine definierte Schnittstelle zur Kommunikation an. Die interne Implementierung des Moduls ist dem Benutzer nicht bekannt (Information Hiding).

Ein Nachteil des Modulkonzepts ist, daß es nur dann in mehreren Zusammenhängen eingesetzt werden kann, wenn es in exakt der gleichen Form verwendet wird. Sobald ein Modul für verschiedene Anwendungen geändert werden muß, sind Eingriffe in den Programmcode erforderlich, es können sogar verschiedene Versionen entstehen. Modulkonzepte werden dadurch unübersichtlich, das Prinzip der Wiederverwendung wird begrenzt.

Objektorientierte Ansätze lassen sich dagegen auf der Typebene definieren, so daß von einem Objekt bei Änderungen Subtypen angelegt werden können, ohne daß das Ausgangsobjekt geändert werden muß. Dadurch erhöhen sich die Flexibilität des Systementwurfs und die Wiederverwendbarkeit der Entwurfskonstrukte.

Der Trend, monolithische Software in kleinere Einheiten zu zerlegen, trifft sich mehr und mehr mit den mittlerweile herangereiften objektorientierten Ansätzen. Das Schlagwort heißt dabei Componentware.

Componentware

Der Grundgedanke von Componentware ist, Softwaresysteme aus Standardkomponenten zusammenzusetzen, die auch von unterschiedlichen Herstellern stammen können. Die Komponenten sind durch Nachrichtenaustausch lose miteinander gekoppelt. Die Entwicklung verlagert sich dann vom Programmieren zum Design der Lösung und zur Montage der Komponenten.

Der Komponentengedanke ist eng mit den Prinzipien objektorientierter Ansätze verbunden. Objektorientierte Konzepte sind nicht neu, erhalten aber erst in den letzten Jahren zunehmend praktische Bedeutung. Neue Anwendungssoftware wird heute überwiegend in Objekttechnologien entwickelt. Damit trifft sich die Zerlegung klassischer Standardsoftware in Objektstrukturen als Top-down-Ansatz mit dem Bottom-up-Ansatz neu entwickelter Systeme.

Objekte

Der objektorientierte Ansatz beruht darauf, Objekte mit ihren Datenbeschreibungen und den auf sie anzuwendenden Methoden (Funktionen) zu kapseln. Der Benutzer kann über Nachrichten Methoden aktivieren und so auf Daten zugreifen. Die Implementierung der Methoden bleibt dem Benutzer verborgen.

Systeme werden auf der Typebene entworfen, ähnliche Objekte also zu Klassen zusammengefaßt. Eine weitere Eigenschaft von Objekten ist die Vererbung, bei der sich Methoden und Attribute übergeordneter Klassen über die Generalisierung-/Spezialisierung-Operation auf untergeordnete Klassen vererben. Sie können dort auch überschrieben und ergänzt werden. Durch die Vererbung wird das Prinzip der Wiederverwendbarkeit unterstützt.

Die ausschließliche Verwendung einer objektorientierten Programmiersprache garantiert aber noch keinen Produktivitätsgewinn gegenüber klassischen Modulkonzepten. Insbesondere die feine Granularität der Objekte hat zur Folge, daß umfassende Systeme unübersichtlich werden. Die einzelnen Objekte sind auch zu fein, um in einer sinnvollen Workflow-Steuerung aufgerufen zu werden. Deshalb werden Objekte zu größeren Einheiten, sogenannten "Business Objects" zusammengefaßt, in denen auch schon das Anwendungswissen über das Zusammenspiel der internen Objekte enthalten ist.

Business Objects

Die Granularität der Objekte ist für eine montagebezogene Software-Entwicklung zu fein. Hier müssen gröbere Logikbausteine definiert werden. So sieht etwa der objektorientierte Ansatz der Unified Modeling Language (UML) die Bildung sogenannter "Packages" vor. Die anwendungsbezogene Sicht, die ein gröberes Objekt nach Anwendungsfunktionalität definiert, wird durch den Begriff "Business Object" verdeutlicht. Ein Business Object umfaßt einen Geschäftsablauf mit den benötigten Daten und den auf sie anzuwendenden Funktionen. Es beinhaltet mehrere Objekte des zuvor beschriebenen, klassischen objektorientierten Ansatzes - Eigenschaften wie Kapselung, Wiederverwendbarkeit durch Vererbung und lose Kopplung durch Nachrichtenaustausch werden übernommen.

Auch bei den Business Objects ist die Granularität nicht vorgegeben, sondern muß nach sinnvollen anwendungsbezogenen Arbeitseinheiten gebildet werden. Kriterien dafür sind ein enger inhaltlicher und organisatorischer Zusammenhang, die hohe interne und geringe externe Kommunikation, eine hohe geschlossene Wiederverwendbarkeit und Performance.

Business Objects müssen nicht notwendigerweise aus streng objektorientierten Einzelobjekten gebildet werden, sondern können insbesondere bei der Top-down-Zerlegung eines existierenden Systems auch aus konventionellen Programmteilen bestehen. Wichtig ist nur, daß sich das Business Object selbst nach objektorientierten Grundsätzen verhält.

Der Gedanke von Componentware wird auch von Softwarekonzepten unterstützt, die auf einfachen Hardware-Clients, sogenannten Netzcomputern, basieren. Die Anwendungen werden in einem Netzwerk (Inter- oder Intranet) gespeichert und bei Bedarf vom Client abgerufen. Besondere Bedeutung haben hierbei die Möglichkeiten der Programmiersprache Java erreicht. Mit Hilfe von Java-Applets kann die Bearbeitung plattformunabhängig in der inzwischen verbreiteten Umgebung eines Internet-Browsers erfolgen.

Java Applets

Die Anwendung der Java-Sprache ist auf drei Ebenen möglich. Mit Javascript werden die Befehle als Quellcode direkt in den Text einer HTML-Seite eingebunden. Der zur Verfügung stehende Befehlssatz ist nur teilweise mit Java identisch, beide basieren jedoch auf C++. Mit Javascript können allerdings nur kleinere Anwendungen realisiert werden wie das Überprüfen eingegebener Werte auf ihre Gültigkeit oder das Anzeigen einer Laufschrift in der Statuszeile des Browsers. Javascript erlaubt keine direkte Kommunikation zwischen Client und Server.

In der zweiten Stufe wird der Bytecode eines Applets zusätzlich zu der geladenen HTML-Seite zum Client übertragen. Dort wird der Bytecode verifiziert und interpretiert, das Applet anschließend ausgeführt. Applets sind allerdings nur innerhalb der Browser-Umgebung ablauffähig. Innerhalb von Applets kann jedoch eine weitere Kommunikation zwischen Server und Client erfolgen. So läßt sich beispielsweise gemeinsam mit dem Applet ein Dokument vom Server laden, innerhalb des Applets bearbeiten und dann zurück an den Server schicken.

Sogenannte Applications sind dagegen unabhängig von der Browser-Umgebung einsetzbar. Sie benötigen lediglich eine Java Virtual Machine (JVM) zur Umsetzung des Bytecode. Mit ihnen ist die Entwicklung eigenständiger Anwendungen möglich, deren Bausteine je nach Bedarf über ein Netzwerk auf den Client-Rechner geladen werden.

Sowohl Applets als auch Applications sind geeignet, den Gedanken von Componentware zu unterstützen. Es müssen keine überflüssigen Module installiert und gepflegt werden. Das System wird kundenindividuell nach Bedarf zusammengestellt.

Framework-Konzept

Der objektorientierte Ansatz hat das Modulkonzept verbessert, weil er durch das Vererbungsprinzip leichter Änderungen zuläßt, ohne daß neue Modulvarianten entstehen. Das Framework-Konzept geht noch weiter. Es enthält eine Sammlung von Komponenten und fügt sie zu einem bestimmten Anwendungsfall zusammen. Auf den ersten Blick entspricht diese Beschreibung der eines Business Objects. Als Ergänzung kommt aber hinzu, daß Infrastrukturkomponenten wie Workflow-Systeme, Modellierungs-Tools und Middleware mitgeliefert werden, und die Business Objects innerhalb des Framework bereits zu einer Anwendung verknüpft sind. Weiterhin tritt anstelle des objektorientierten Vererbungsprinzips das Prinzip der Komposition.

Bei einem Framework können Komponenten als austauschbar definiert werden ("Hot Spots"), um sie von Anwendern entsprechend ihren Anforderungen durch eigene Komponenten auszutauschen. Die nicht veränderbaren Komponenten werden als "Frozen Spots" bezeichnet. Die Anpassung von Frameworks durch Komponentenaustausch läßt sich als Komposition bezeichnen und ist eine Alternative zur objektorientierten Anpassung (Definition von Subklassen mit Vererbung). Ein Framework stellt damit ein unvollkommenes Anwendungssystem dar, das durch Austausch von Komponenten auf den Benutzer ausgerichtet wird. Die Wiederverwendbarkeit gilt nicht nur für Komponenten, sondern auch für das Architekturwissen zur Verknüpfung der Komponenten. Bei Framework-Produkten wird somit insbesondere die Einbeziehung von Middleware, die zwischen Anwendungssoftware und dem Betriebssystem sowie Hardware vermittelt, betont.

Konsequenzen für die Software-Industrie

Mit den Möglichkeiten von Componentware und Frameworks wird sich die Erstellung von Software ändern. Die Software-Industrie wird in Zukunft ihre bisherige große Fertigungstiefe abbauen und sich aufteilen in Komponentenhersteller sowie Anbieter von Gesamtlösungen, die Komponenten in Frameworks montieren. Dazwischen werden Sub-Systemhersteller Zwischenprodukte erstellen.

Die Komponenten werden von den Monteuren nach dem Grundsatz "best of breed" ausgewählt und ausgetauscht. Damit wird das betriebswirtschaftliche Wissen und seine Darstellung in montagegeeigneter Form immer wichtiger. Modellierungsmethoden sowie die Integrations- und Customizing-Verbindungen zu Workflow und Business Objects stellen den Angelpunkt der Software-Entwicklung dar.

Allerdings sollten die Möglichkeiten eines Marktes für Componentware, aus dem sich die großen Lösungsanbieter flexibel bedienen können, nicht überschätzt werden. Insbesondere erscheint das Bild eines Legobaukastens nicht zutreffend. Legosteine sind einander gleich und können ohne Wissen über die innere Struktur der Steine zusammengesetzt werden. Softwarekomponenten enthalten dagegen unterschiedliches Anwendungswissen.

*Auszug aus dem noch in diesem Monat von Prof. Dr. Dr. h. c. A.-W.Scheer im Springer Verlag veröffentlichten Buch "Aris - Vom Geschäftsprozeß zum Anwendungssystem". Scheer ist Direktor des Instituts für Wirtschaftsinformatik der Universität des Saarlandes.