In Kapitel 1.2 wurde die "Kapitalintensive Softwaretechnik" mit Hilfe von Softwarekomponenten nach Peter Wegner vorgestellt, ohne näher auf mögliche Realisierungen einzugehen. Quellcode-Komponenten sind eine mögliche Realisierung, bei denen mehrere Hochsprachenanweisungen zu einem Block bzw.Baustein ( building block ) zusammengefaßt werden. Nach außen stellt ein solcher Baustein über eine Schnittstelle eine definierte Funktionalität bereit und ist durch ein bestimmtes Verhalten charakterisiert.
Quellcode-Komponenten existieren in vielerlei Gestalt. Eine Gruppe besteht aus Prozeduren, Funktionen und Unterprogrammen, die von Betrand Meyer [Meyer, 1989] unter dem Oberbegriff Routinen zusammengefaßt werden. Alle verfolgen den gleichen Ansatz, sprich das Auslagern häufig verwendeter Programmteile in Routinen und dem Austausch von Daten über Parameter oder globale Variablen. Paradebeispiel hierfür sind die mathematischen Funktionsbibliotheken, die seit geraumer Zeit im Einsatz sind. Die nächst höhere Ebene sind Module oder Pakete ( packages ), die aus mehreren problemnahen Routinen und Typdeklarationen bestehen können. Die Datentypen stehen aber nicht in direkter Beziehung zu den Routinen im Modul.
Stand der Technik sind heute die verschiedenen Realisierungen der Abstrakten Datentypen , allen voran die objektorientierten Programmiersprachen mit Klassen und deren Ausprägungen, den Objekten. Abbildung 5 zeigt eine übersicht über die verschiedenen Quellcodekomponenten mit einigen Beispielen.
Abbildung 5: Verschiedene Arten von Quellcode-Komponenten
Alle Ansätze haben zum Ziel, möglichst gute und umfangreiche, wiederverwendbare Bibliotheken mit Standardkomponenten bereitzustellen, aus denen Software zusammengesetzt werden kann.
"The goal of off-the-shelf components is to reduce the cognitive effort, the number of keystrokes, and therefore the amount of time required to design, implement and debug a new software system."
[Krueger, 1992]
Die Wiederverwendung mit Quellcodekomponenten wirft verschiedene Probleme auf. Wird die Anzahl der Komponenten sehr groß, so wird die Suche nach angemessenen Komponenten recht langwierig. Man betrachte als Beispiel die Referenzhandbücher handelsüblicher C-Compiler. Hier eine Klassenbezeichnung aus dem Leben eines Anwendungsprogrammierers:
IlvMakeArrowPolylineInteractor
Charles W. Krueger bringt die Problematik auf den Punkt: "To reuse a software artifact effectively, you must be able to find it faster than you could build it." [Krueger, 1992]. Dieses Prinzip gilt ganz allgemein für alle Wiederverwendungselemente. Lösungen hierfür sind moderne Entwurfsdatenbanken.
Die Verwaltung von Softwarekomponenten, von Hand oder mit Werkzeugen, setzt voraus, daß diese mit aussagekräftigen Namen und charakteristischen Beschreibungen versehen worden sind, an denen ihre Bedeutung erkenntlich wird. Einfache Funktionen, wie z.B. die mathematischen Bibliotheksfunktionen sin und log , sind anhand des Namens bereits selbsterklärend. Je umfangreicher und anwendungsspezifischer Bausteine werden, desto schwieriger ist es, geeignete Abstraktionen zu finden. "To select an artifact for reuse, you must know what it does." [Krueger, 1992].
Nach der Selektion geeigneter, komplexer Komponenten müssen in der Regel Anpassungen vorgenommen werden. Modifikationen auf dem unterliegenden Quellcode sind zwar möglich, aber keine geeignete Methode für einfache und schnelle Wiederverwendung. Oft ist der Quellcode auch gar nicht verfügbar, z.B. bei käuflich erworbenen Bibliotheken die vom Hersteller nur im einbindbaren Code vorliegen, oder Veränderungen der Software sind durch Copyright nicht möglich. Mit Hilfe der objektorientierten Konzepte und Programmiersprachen wird die Modifikation ohne Eingriff möglich, z.B. in Form von generischen Klassen und Parameterisierung (C++-Templates oder andere) und durch Vererbung. Abbildung 63 zeigt ein Beispiel für die Parameterisierung einer generischen Klasse, dargestellt in der Booch-Notation [Booch, 1994a]
Abbildung 6: Wiederverwendung mit generischen Klassen
Allgemein kann man sagen, daß der objektorientierte Ansatz für die Wiederverwendung auf Komponentenebene gut geeignet ist. Da dieser Ansatz auf den früheren Konzepten der Routinen und Module aufbaut, sind diese ebenfalls wichtige Konzepte der Wiederverwendung.