Komponentenbasierte Software-Entwicklung

Von: Dipl.-Ing. Günter Klaus

In der heutigen Softwareentwicklung geht es schon lange nicht mehr nur um das einfache „Schreiben“ (designen) von Software, vielmehr geht es darum abstrakte Probleme auf Anwendungsebene zu lösen. So ist beispielsweise das Entwickeln einer Steuerrecht-Software ohne spezifisches Fachwissen nicht möglich. Dieser Umstand wird als Kernkompetenzenproblem bezeichnet. Zur Lösung dieses Problems sind Kompetenzpartner nötig, welche die Softwareentwicklung unterstützen. Eine weitere Herausforderung ist die Wiederverwendung bereits gelöster Softwareprobleme. Nirgendwo wird häufiger das „Rad neu erfunden“, wie in der Softwareentwicklung. Die objektorientierte Programmierung verspricht zwar, das Problem der Wiederverwendbarkeit zu lösen, nur zeigt sich in der Praxis, dass dieses Versprechen oft nicht einzuhalten ist, zu unterschiedlich sind die Anforderungen an die Softwareelemente. Heute ist in den häufigsten Fällen die Softwareentwicklung die Sache eines Teams, nicht mehr die eines Einzelnen. Hierzu ist eine Aufteilung der Software in unabhängige Bereiche notwendig. Diese ist jedoch in einem herkömmlichen (monolithischen)Ansatz oft schwierig, zu sehr greifen die Softwarestrukturen ineinander. Die Folge ist, dass Programmteile von einigen wenigen im Team entwickelt werden, während die Anderen auf einen bestimmten Entwicklungsstand warten.

Begriff der Softwarekomponente

Ein komponentenorientierter Ansatz verspricht die oben beschriebenen Probleme zu reduzieren. Im folgenden soll beschrieben werden, wie sich die geschilderten Probleme durch den Einsatz von Komponententechnologie lösen lassen. Man spricht bei Komponententechnologie von der problembezogenen Spezialisierung der objektorientierten Softwareentwicklung. Der objektorientierte Ansatz verfolgt dabei den Bezug zur Realität. Anders als bei der prozeduralen Programmierung die ihren Bezug eher in der Mathematik sucht, werden Objekte der realen Welt modelliert. Dieser Ansatz ist dem Gedanken des Menschen näher als dem mathematisch bezogenen Modellansatz. Probleme aus der Wirklichkeit können somit mit Objekten der Wirklichkeit modelliert werden. Der objektorientierte Ansatz bietet zwar die Modellierung von Objekten der Realität, das Erscheinungsbild (Interface) ist jedoch von Objekt zu Objekt verschieden. Soll z.B. ein Schrauben-Objekt zu einem Mutter-Objekt passen, so ist eine Normierung der Interfaces notwendig. In diesem Fall also die Normierung der Gewindeart. Ist die Normierung erfolgreich, so ist es egal von welchem Hersteller die Schrauben und Muttern stammen, sie passen zusammen. Durch die Normierung der Interfaces eines Objektes wird daraus eine Softwarekomponente. Es wird möglich Objekte, bzw. Komponenten zu benutzen, die von verschiedenen Herstellern entwickelt wurden, sie werden austauschbar. Die Wiederverwendbarkeit wird enorm gesteigert.
Lediglich Parameteranpassungen, wie im Beispiel der Schrauben, M5-, M6-Gewinde, müssten vorgenommen werden. Dies wird als Customizing bezeichnet. Durch den Einsatz von Softwarekomponenten kann auch das Kernkompetenzenproblem angegangen werden. Ein Softwarehaus, welches nicht alle Kernkompetenzen zur Bewältigung eines Softwareprojekts hat, kann mit diesem Ansatz von Fremdfirmen fehlende Kernkompetenzen in Form von spezialisierten Softwarekomponenten zukaufen. Wie in der Automobilbranche üblich, könnte sich eine Zulieferindustrie entwickeln, in der große Softwarehäuser sich Komponenten von Zulieferer-Firmen mit speziellem Fachwissen entwerfen lassen. Diese Kernkompetenzen werden in Form von high-level Komponenten hinzugekauft. Der Kunde merkt davon nichts. Das Softwarehaus integriert die eigenen und erworbenen Komponenten zu einem ganzen Produkt.

Entwicklung einer komponentenbasierten Applikation

Die Komponententechnologie geht aus dem objektorientierten Ansatz hervor. Auch beim komponentenbasierten Ansatz geht es darum, Objekte des zu lösenden Problems zu identifizieren. Diese werden dann, unter Verwendung standardisierter Schnittstellen, in Komponenten umgewandelt. Hierbei ist es wichtig, dass darauf geachtet wird, möglichst wenige Kernkompetenzen in einer Komponente zusammenzufassen. Sind die vorkommenden Problembereiche identifiziert, wird nun recherchiert, ob es verfügbare Softwarekomponenten am Markt gibt, die auf die jeweiligen Problembereiche passen. Aus heutiger Sicht ist der Markt für Komponenten noch zu jung, um wirklich jedes Problem abzudecken. Dies wird sich jedoch in Zukunft ändern und der Anteil der hinzugekauften Komponenten wird steigen. Nicht verfügbare Komponenten werden selbst entwickelt und können, wenn sie von allgemeinem Interesse sind, neben dem entstehenden Softwareprodukt zusätzlich vermarktet werden. Die zukünftige Hauptaufgabe bei einer komponentenbasierten Entwicklung wird die Montage und Kopplung von Standardkomponenten zu einer Gesamtlösung.

Java-Beans Komponentenmodell

Im IAF der Fachhochschule Esslingen werden Java-Beans als Sun‘s Realisierung des Komponentenmodells für die „Java Plattform“ zur Entwicklung komponentenbasierter Software verwendet. Java Beans erfüllen voll unsere Ansprüche an komponentenbasierte Software und gelten 100% als plattformunabhängig. Dies war Grundvoraussetzung
für den Einsatz von Java Beans im IAF. Java Beans bilden selbst beschreibende Software-Einheiten. Dies bedeutet, dass andere Softwarekomponenten explizit das Interface eines Java Beans erfragen können. Beans geben hierbei Auskunft über Properties, Events und Methoden. Diese Informationen verbergen die interne Funktionalität des Beans vor der Außenwelt,lassen sie aber offen genug, um diese Funktionalität zu benutzen. Über spezielle Dialoge können die jeweiligen Beans innerhalb einer integrierten Entwicklungsumgebung (IDE) an individuelle Bedürfnisse angepasst werden (Customizing). Die sogenannten Properties (s.u.) bilden die Spezialisierung des Beans, welche dann im Endprodukt ihre Anwendung finden. Der Softwareaufwand zum Erstellen eigener Beans besteht im simpelsten Fall darin, festgelegte Namenskonventionen für die Zugriffsmethoden zu verwenden. Im folgenden sollen die näheren Eigenschaften von Java Beans beschrieben werden:

Properties

Properties sind diskrete Attribute eines Java-Beans, welche sein Verhalten und Erscheinungsbild steuern. Nach außen wird ein Property je nach Typ von ein bis drei Klassenmethoden repräsentiert. Diese Methoden müssen nach ganz bestimmten Namenskonventionen benannt werden. Soll z.B. eine Property lesbar und schreibbar sein, so sind folgende Methoden nötig:

<Typ> get<Property-Name>()

void set<Property-Name>( <Typ> )

Neben den normalen Properties gibt es noch zwei spezielle Arten:

Dies geschieht über das Werfen einer PropertieVetoException.

BeanInfo-Klassen

Diese Klassen geben allgemeine Auskünfte über das Bean. Informationen wie Methodennamen, Properties, Events und vieles mehr sind über diese Helper-Klasse in Erfahrung zu bringen. Eine IDE z.B. kann über die BeanInfo-Klassen ein Bean analysieren und auf besondere Eigenschaften eingehen. Eine BeanInfo-Klasse muss, ähnlich wie bei den Properties, eine ganz bestimmte Namenskonvention einhalten:

 <Name des Bean>BeanInfo

Dies ist wichtig, weil der Introspector (s. u.) sonst die Bean-Klassen nicht zu den Info-Klassen binden kann. Eine Besonderheit bei diesen Klassen ist, dass sie nicht unbedingt selbst erstellt werden müssen. Sie können vom Introspector automatisch zur Laufzeit generiert werden. Jedoch wird man sie in der Praxis selbst erstellen, weil darüber zentrale Eigenschaften der Beans einstellbar sind.

Introspector-Interface

Der Introspector ist die zentrale Anlaufstelle, um Informationen über Beans zu erhalten. Er sucht zunächst im Klassenarchive nach der zugehörigen Infoklasse. Findet er keine entsprechende
Klasse, so generiert er eine eigene Klasse. Es ist auch möglich eine unvollständige BeanInfo-Klasse zu ergänzen. Soll z.B. nur das Icon eines Beans definiert werden, kann der Introspector die fehlenden Informationen selbständig ergänzen.

Bean-Anpassungen (Customization)

In einer IDE sollen Properties über Property-Editor Dialoge eingestellt und abgespeichert werden können. Über den PropertyEditorManager können eigene und vordefinierte Editoren bezogen werden. Üblicherweise wird eine IDE die Editoren für bestimmte Property-Typen anfordern und einen Dialog erstellen, in dem die Editoren in einer Tabelle angeordnet sind. Interessant ist dabei die Möglichkeit, eigene, spezialisierte Editoren für bestimmte Datentypen zu registrieren; dies geschieht über den Property-Editor-Manager. Die IDE benutzt dann die neuen, registrierten Editoren, somit kann Einfluss auf die integrierte Entwicklungsumgebung genommen werden. Sollen eigene Property-Editoren zum Einsatz kommen, so müssen eigene GUI-Elemente erstellt und registriert werden. Diese Klassen müssen nach einer bestimmten Namenskonvention benannt werden:


Property-Typ: <Typ-Name>
Editor-Klasse: <Typ-Name>Editor


Die Klassen werden nun über folgenden Methodenaufruf registriert:

PropertyEditorManager.registerEditor(<Typ-Name>, <Typ-Name>Editor)

Die flexibelste Art der Bean-Anpassung ist die Erstellung von eigenen Customize-Dialogen. Dabei kann individuell auf besondere Begebenheiten der Beans eingegangen werden. Ist ein Customize-Dialog gut entworfen, so kann er auch für den Endeinsatz benutzt werden. Z.B. ein Datenbank-
Bean stellt einen Customize-Dialog für das Anmelden einer Datenbank zur Verfügung. Dieser Dialog kann dann nicht nur zur Design-Zeit benutzt werden, sondern auch im realen Einsatz. In der jeweiligen BeanInfo-Klasse muss die folgende Methode überschrieben werden:


public BeanDescriptor getBeanDescriptor()


Detailliertere Informationen sind in der Java Beans Spezifikation [1] zu finden.

Baukastenprinzip mit Java Beans

Wir sehen einen Baukasten als Ansammlung von bestimmten Komponenten, aus denen sich Gebilde erstellen lassen, die einer bestimmten Grundstruktur entsprechen. Die Elemente eines Baukastens sind so konzipiert, dass mit möglichst wenig unterschiedlichen Bauteilen verschiedenartigste Konstrukte erzeugt werden können. Durch die Spezialisierung eines Baukastens auf einen ganz bestimmten Problembereich können schnell und einfach individuelle Lösungen gefunden werden. Dieses Prinzip lässt sich gut auf den Bereich der Individual-Software anwenden. Ein Vertriebs-Informationssystem fällt z.B. unter den Bereich der Individual-Software. Es gibt keine allgemeine Lösung, jede Firmenvertriebsstruktur sieht etwas anders aus. Eine Standardsoftware kann hier nicht die ideale Lösung bieten. Entweder ist die Software, durch die Abdeckung aller erdenklichen Spezialfälle, so komplex, dass sie nur mit hohem Schulungsaufwand bedienbar wird oder sie verlangt von der Firma seine Strukturen an das Produkt anzupassen. Auf der anderen Seite wäre ein maßgeschneidertes Produkt das Optimum. Dieses ist aber durch die Einzelentwicklung sehr teuer und außerdem sehr statisch. Jede weitere Änderung verschlingt wiederum viel Geld. Die Idee ist nun, das Problem der Vertriebsorganisation allgemein durch einen Komponenten-Baukasten zu lösen. Durch die Auswahl, der Montage und der Parametrisierung von Standardkomponenten erhält der Kunde seine individuelle Version des Vertriebsinformationssystems. Die Zusammenstellung oder Anpassungen ergeben einen Bruchteil der Kosten, die für eine Einzelentwicklung anfallen würden. Fehlen bestimmte Bauelemente im Baukasten, werden sie anfangs für einen Kunden separat entwickelt, wandern aber danach in den Komponenten-Baukasten. So entsteht über die Zeit ein leistungsfähiges Gesamtprodukt, das durch seine Flexibilität und Individualität besticht. Die Java Beans-Technologie bieten hierfür eine gute Grundlage. Die Java Beans bilden die Bausteine unseres Baukasten. Das Zusammensetzen der Bausteine erfolgt zum in einer IDE.

Zusammenfassung

Durch das Java Beans-Konzept wird es möglich, Komponenten zu erzeugen, die sich selbst beschreiben. Entwicklungstools können diese Informationen verwenden, um die Komponenten zu benutzen. Es ergibt sich Wiederverwendbarkeit auf höchsten Niveau. Durch die Einteilung der Software in eigenständige Komponenten können Komponenten separat entwickelt und getestet werden. Der Aufbau der Beans ermöglicht es, selbst entwickelte Komponenten zu verkaufen, ohne den internen Aufbau  eines Bean zu veröffentlichen oder auch Beans zu kaufen. Die Java Beans Technologie wurde bei uns im IAF der Fachhochschule Esslingen für ein Vertriebsinformationssystem eingesetzt. Hierbei wurden sehr gute Erfahrungen mit Java Beans gemacht.

 

Literatur

[1] Sun Microsystems (Hrsg.) (1998): Java Beans 1.0.1 Specification
[2] Sun Microsystems (Hrsg.) (1998): Java Beans: API Specification
[3] Reaz Hoque (1998): Programming Java Beans 1.1

 

Erschienen: horizonte 16 / Juni 2000