Überlegungen zur Komponententechnologie sind nicht neu. Bereits 1969 hatte der Entwickler Doug McIlroy die Metapher der Softwarekomponente eingeführt. Es sollte aber bis in die Mitte der 90er Jahre dauern, bis das Thema zum ersten Mal breitere Beachtung fand. Trotz dieser langen Vorgeschichte sind wir heute noch weit von einer einheitlichen und allgemein akzeptierten Definition von Komponenten entfernt. Einige anerkannte Experten haben sich daran gemacht, den Begriff zu definieren, allerdings aus der Sicht ihrer Zeit und damit des aktuellen Stands der Technik.
Booch [Booch 1987] - "A reusable software component is a logical cohesive, loosely coupled module that denote a single abstraction."
Nierstrasz & Tsichritzis [Nierstrasz 1995] - "A Software component is a static abstraction with plugs. Plugs refer to the in and out-going interfaces. The static aspect is according to the definition in this book; it allows components to be stored in repositories."
Szyperski [Szyperski 1997] - "A software component is a unit of composition with contractually specified interfaces and explicit context dependencies only. A software component can be deployed independently and is subject to composition by third parties."
Die Definitionen wurden über die Jahre weiter präzisiert, sie ermöglichen jedoch noch immer keine allgemeinverständliche und plausible Charakterisierung von Komponenten. Immerhin findet sich eine Reihe von Attributen, die eine Komponente kennzeichnen: Sie ist ein binäres Stück Software mit spezieller Funktionalität, die über Schnittstellen angeboten wird und deren Verhaltensbeschreibung zum Beispiel mit Hilfe von Vor- und Nachbedingungen oder Kontrakten ausgedrückt wird. Ferner kann sie sofort per "plug and play" in einer Komponenteninfrastruktur aufgenommen werden und ist per Definition darauf vorbereitet, ja angewiesen, mit anderen Komponenten entsprechend bestimmter Interaktionsmuster, die von der Infrastruktur definiert werden, zu kooperieren. Außerdem ermöglicht sie die Komposition von Anwendungen aus vorgefertigten Softwarekomponenten.
Viele Definitionen bleiben unzureichendFast alle Definitionen vernachlässigen aber den Unterschied zwischen der Definitions- und der Inbetriebnahmezeit. Atkinson [Atkinson 1999] versuchte, dieses Defizit zu beseitigen. Nach seinem Ansatz wird die Modellierung auf folgenden Ebenen durchgeführt:
-Kompositionshierarchie - Komponenten bestehen wiederum aus Komponenten;
-Typhierarchie - eine Komponente gleicht der anderen; so dass Vererbung möglich ist;
-Metahierarchie - beschreibt die Komponentenspezifikation einschließlich Realisierung und Dokumentation;
-Architekturhierarchie - Abbildung der statischen Komponentendefinition in die Laufzeithierarchie - , Möglichkeit der initialen Konfigurationsbeschreibung.
Aber auch dieser bemerkenswerte Ansatz ist nur ein kleiner Schritt, den die IT-Abteilung machen muss, bevor sie tatsächlich komponentenbasiert entwickeln kann. Vielmehr gibt es zahlreiche weitere technische und organisatorische und definitorische Fragen, die bedacht und beantwortet sein wollen (siehe Kasten "Fragen").
Auch fehlt derzeit noch die Spezifizierung eines allgemeinen komponentenbasierenden Softwareentwicklungsprozesses. Allerdings sind entsprechende Bestrebungen im vollen Gange. Hierbei wird versucht, vorhandene Entwicklungsprozesse auf die spezifischen Gegebenheiten der Komponentenentwicklung zu übertragen. Die Entwicklung neuer oder die Weiterentwicklung existierender Ansätze wie Rational Unified Process (RUP), Catalysis oder Business Component haben bereits für erste wichtige Impulse gesorgt.
RUP 1999 beispielsweise zeichnet sich zwar noch durch die sehr generische und inkrementelle Softwareentwicklung aus und beschreibt sinnvolle Vorgehensweisen. Er ist jedoch selten präskriptiv und benutzt erstaunlicherweise kaum die objektorientierte Standard-Notation der Unified Modelling Language (UML). Catalysis [Wills 1999] hingegen ist stark an UML ausgerichtet, zum Teil sehr rigoros in der Definition der Vorgehensweise und verursacht größeren Einarbeitungsaufwand.
Die Business Components Factory [Sims 2000] ihrerseits ist komponentenbasierend und Architektur-orientiert, unterstützt die kontinuierliche und evolutionäre Integration von neuen Komponenten sowie den Aufbau von Komponentenbibliotheken und ermöglicht nebenläufige Entwicklungsaktivitäten.
Bei der Entwicklung von Architekturen müssen ferner zwei Aktivitäten unterschieden werden: einerseits das Entwickeln von Komponenten (Programming-in-the-Large), andererseits das Entwickeln mit Komponenten (Programming-in-the-Small). Beide Tätigkeiten müssen in enger Abstimmung erfolgen. Dabei können Entwurfsmuster eine wichtige Rolle spielen. Konkret beinhaltet das Entwickeln mit Komponenten, dass die Entwurfsmuster in Anlehnung an eine entsprechende Infrastruktur Richtlinien und Verpflichtungen für die Entwicklung von Komponenten bereitstellen. So genannte Idiome definieren zudem Implementierungen gängiger Probleme und hängen stark vom benutzten Komponentenmodell und der Implementierungssprache ab. Bei der Entwicklung mit Komponenten geht es hingegen zum einen um Architekturmuster, die helfen sollen, die Struktur der Softwareanwendungen zu gliedern und die grundsätzlichen Interaktionsprinzipien zu definieren. Zum anderen gibt es Entwurfsmuster, die eine Verfeinerung der Anwendung und ihrer Subsysteme ermöglichen. Diese betrachten die Architektur als ein statisches Model, ohne die Komposition oder gar die Laufzeitebene der Komponenten zu berücksichtigen.
Des Weiteren bekommt es der Anwender mit einer Vielzahl von Komponentenmodellen zu tun, von denen sich mittlerweile drei herauskristallisiert haben: Microsofts Component Object Model (COM [COM 96]), Suns Enterprise Javabeans [EJB] und OMGs Corba Component Model (CCM) [CCM 1999]. Sie alle unterstützen aber bis heute nur eine begrenzte Auswahl heterogener Rechnerarchitekturen sowie Implementierungssprachen und lassen speziellere Anwendungsgebiete völlig außer Acht. Diese meist nicht standardisierten Spezialisierungen bleiben externen Anbietern oder dem Endanwender überlassen. Man kann aber gespannt sein, wie sich das noch nicht in Produkten verfügbare CCM und Micosofts neuer .Net-Ansatz [Stahl 2000] entwickeln werden und welche neuen Ideen Sun präsentieren wird.
Spezialisierte Komponentenmodelle stellen spezielle Anforderungen an die Laufzeitumgebung. Die gegenwärtigen Modelle ermöglichen es jedoch nur mit viel Mühe, eine angemessene Infrastruktur aufzubauen. Insbesondere lassen sich Komponentenframeworks nicht effizient einrichten. Ausdrucksmöglichkeiten für Interaktionsbeschreibungen, wie zum Beispiel Rollendefinitionen, fehlen ebenso wie eine Unterstützung der Komposition oder die Prüfung der Konsistenz solcher Rahmenwerke etwa durch Vor- und Nachbedingungen [Nierstrasz 1996]. Des Weiteren sind heutige Kompositionsumgebungen noch nicht ausreichend auf die vielfältigen Aufgaben ausgelegt. Vielmehr beschränken sie sich weitgehend auf die Verschaltung von grafischen Komponenten auf der Ebene der Triggerung von Methoden, wenn Nachrichten eintreffen oder sich Variablenwerte ändern. Eine Komposition, bei der auch komplexere Applikationssemantik verknüpft wird, ist nur in speziellen, meist explorativen Komponentenumgebungen erhältlich, die wiederum auf speziellen Komponentenmodellen aufbauen. Lediglich die für den Corba-Standard zuständige Object Management Group (OMG) versucht bisher mit der Definition des CCM-Standards entsprechende Vorkehrungen zu treffen. Sollen neue Komponenten, wie erhofft, ein langes Leben haben und ausgedehntere Innovationszyklen sowie häufigere Release-Updates überdauern, so müssen sie sich unbedingt in die alten Infrastrukturen integrieren lassen. Es ist daher damit zu rechnen, dass in Zukunft die Anforderungen an die Meta-Modell-basierende Schnittstellen-Generierung und Modifikation weiter steigen. Solche Schnittstellen sollten dann auch gleich in der Lage sein, Komponenten von einem Interaktionsparadigma zum anderen (halb-)automatisch anzupassen [Assmann 1998].
Ebensfalls wichtig für die Beherrschung der Komponententechnologie ist es, die interne Organisation und die Qualitätssicherung stärker zu beachten. Hierher gehören etwa die Beseitigung unzulänglicher Spezifikationen und Dokumentationen. So steckt die Verwaltung der Evolution und der Kompatibilität von Komponentenversionen und Systemkonfigurationen noch in den Kinderschuhen. Es reicht bei weitem nicht aus, jeder Komponente lediglich eine eindeutige Identität zu verpassen und die Funktionalität über die Versionen zu aggregieren (zum Beispiel in COM). Dies führt vielmehr zu "fetten" Komponenten, deren Funktionalität entweder veraltet ist oder nur zu einem Bruchteil verwendet wird.
Schließlich hat sich auch in puncto Archivierung und effektiver Suche nach Komponenten sowie bei der Implementierung einer geeignetenVermarktungsstrategie für intern und extern erstellte Komponenten kaum etwas gatan. Doch die Zeit drängt: Viele Unternehmen werden von dem "lokalen" Denken und der Verwendung von großen, zugekauften Komponenten (Frameworks) auf feingranulare Komponentenstrukturen umschalten müssen. Damit einhergehend gewinnen Qualitäts-, Robustheits- und Sicherheitsaspekte im Sinne der Vertrauenswürdigkeit der Komponenten höchste Priorität. Auf all diese Fragen gibt es auch heute noch keine befriedigenden Antworten, geschweige denn eine Idee, wie sich beispielsweise Komponenten zertifizieren lassen.
*Dr. Christian Zeidler arbeitet im Bereich Corporate Research DECRC/A bei Asea Brown Boveri (ABB) in Heidelberg.
FRAGENUnternehmen, die erfolgreich Komponenten-basierend entwickeln wollen, müssen sich Fragen wie diese stellen:
- Welches Komponentenmodell soll verwendet werden?
- Welche Infrastruktur ist notwendig, um Entwicklung, Inbetriebnahme und Wartung von Komponenten-basierender Software zu ermöglichen?
- Wie entwickelt man methodisch Komponenten: Hilft Vererbung oder ist Delegation beziehungsweise Aggregation der bessere Ansatz?
- Wie sollte man Komponenten-basierende Systeme entwickeln, und welche Rolle spielt die Definition der Laufzeit-Infrastruktur und ihrer Interaktionsprinzipien (Patterns)?
- Wie kann man Komponenten-basierende Software testen?
- Wie regelt man die Haftungsfragen, wenn Komponenten von Fremdanbietern verwendet werden?
- Welches ist die richtige Granularität für eine erfolgreiche Vermarktung und Benutzung von Komponenten?
- Wie findet man die gesuchten Komponenten? Wie werden Komponenten versioniert?
- Wie beschreibt man Komponentenfunktionalität?
Literatur[Assmann 1998]
Uwe Assmann, Meta-programming Composers In Second-Generation Component Systems, editors Bishop, J. and Horspool, Proceedings of Systems Implementation 2000 - Working Conference IFIP WG 2.4 N, Chapman and Hall, Berlin, 1998
[Atkinson 1999]
Colin Atkinson, Thomas Kühne, Christian Bunse, Dimensions of Component-based Development, Fourth International Workshop on Component-Oriented Programming (WCOP''99; in conjunction with ECOOP''99), Lisbon, Portugal, 14 June 1999
[Booch 1987]
_ Grady Booch, Software Components with Ada: Structures, Tools, and Subsystems, Benjamin/Cummings, Menlo Park, CA, 1987
[CCM 1999]
CORBA Components; Volume I, OMG TC Document orbos/99-07-01, August 1999
[COM 96]
The Component Object Model Specification, Microsoft Corporation and Digital Equipment Corporation, June 1996
[EJB]
Sun Microsystems JavaBeans? API specification, Version 1.01, Graham Hamilton (Editor), July 1997, sowie http://java.sun.com/products/ejb/docs/index.html
[Meyer 1999]
Bertrand Meyer et al, The Trusted Components Initiative, http://trusted-components.org
[Nierstrasz 1995]
Oscar Nierstrasz and Dennis Tsichritzis, Object-Oriented Software Composition, Prentice Hall, 1995
[Nierstrasz 1996]
Oscar Nierstrasz, Infrastructure for Software Component Frameworks, http://www.iam.unibe.ch/scg/Archive/NFS/iscf.html
[RUP 1999]
Ivar Jacobson, Grady Booch, James Rumbaugh, Unified Software Development Process, Addison-Wesley, Object Technology Series, ISBN: 0201571692
[Sims 2000]
Peter Herzum und Oliver Sims, Business Component Factory: A Comprehensive Overview of Component-Based Development for the Enterprise, John Wiley & Sons, January 2000
[Stahl 2000]
Michael Stahl, Microsoft .NET - Evolution oder Revolution, ObjektSpektrum, 6/2000.
[Szyperski 1997]
Clemens Szyperski, Component Software - Beyond Object-Oriented Programming, Addison-Wesley, 1997.
[Wills 1999]
Alan Cameron Wills and Desmond Francis D''Souza, Objects, components, and Frameworks with UML - The Catalysis Ap-proach, Addison-Wesley, 1999.
Abb: Wichtige Themen bei der komponentenorientierten Entwicklung sind noch ungeklärt Quelle: Zeidler