Komponentenbasierte Applikationen

Der Abschnitt beginnt mit der Klärung des Begriffs "Merkmal" im Kontext der Softwareentwicklung. Es wird betont, dass ein Merkmal eine für den Kunden wichtige Eigenschaft eines Systems darstellt, die in einer für den Kunden verständlichen Sprache ausgedrückt wird. Der Text verdeutlicht den Unterschied zwischen technischen Details (z.B. verwendeter Leim, Dübelart bei Möbeln) und kundenrelevanten Merkmalen (Farbe, Maße, Anzahl der Schubladen). Die Definition eines Merkmals sollte sich daher an der Kundenperspektive orientieren, wobei der Detaillierungsgrad abhängig vom Kunden und der Art des Produkts ist (Serienprodukt vs. Maßanfertigung). Die Kundenorientierung bei der Definition von Merkmalen ist zentral für den Erfolg der komponentenbasierten Softwareentwicklung. Die Arbeit kritisiert bestehende, zu technisch orientierte Definitionen von Merkmalen und strebt eine nutzerzentrierte Perspektive an, um die Anforderungen besser zu erfassen und die Komponentenauswahl zu optimieren. Der Fokus liegt auf der Erstellung einer Software, die die Kundenbedürfnisse optimal erfüllt, und nicht auf rein technischen Aspekten. Dies ist entscheidend für die Akzeptanz und den erfolgreichen Einsatz der entwickelten Software.

Im Anschluss an die Definition von Merkmalen wird der Begriff "Softwarekomponente" präzisiert. Im Gegensatz zu materiellen Komponenten (z.B. aus dem Automobilbau) sind Softwarekomponenten immateriell und alle Instanzen einer Komponente identisch. Ein wichtiger Aspekt ist die unabhängige Installierbarkeit, Aktualisierbarkeit und Entfernbarkeit von Komponenten, auch nach der Installation der Gesamtapplikation. Dies ermöglicht die Einbindung von Komponenten durch Dritte ohne detaillierte Kenntnisse des internen Aufbaus. Dieser Punkt ist entscheidend für die Etablierung eines Marktes für wiederverwendbare Softwarekomponenten, ein Ziel, das durch die Objektorientierung zwar angestrebt, aber aufgrund technischer Fokussierung und mangelnder Berücksichtigung ökonomischer Aspekte nicht erreicht wurde. Der Text unterstreicht die Bedeutung der klar definierten Schnittstellen von Komponenten für ein reibungsloses Zusammenspiel in komplexeren Applikationen. Komponenten sollen ihre Funktionalität unabhängig voneinander ausführen und nur in der Spezifikation festgelegten Weise interagieren. Der Vergleich mit Modulen in Programmiersprachen wie Oberon, Modula-3 und C# zeigt die Gemeinsamkeiten und Unterschiede auf. Im Gegensatz zu Modulen sollen Komponenten unveränderbare Ressourcen besitzen, um die Wiederverwendbarkeit und den Anwendungsbereich zu erhöhen.

Dieser Abschnitt fasst die Definitionen von Merkmalen und Komponenten zusammen und unterstreicht deren Bedeutung für die komponentenbasierte Softwareentwicklung. Ein Merkmal repräsentiert eine für den Kunden wichtige Systemeigenschaft und dient der Abbildung der Kundenanforderungen. Die Kategorisierung von Merkmalen in Funktion, Schnittstelle und Parameter vereinfacht die Modellierung und Verarbeitung. Die Definition nach [Str04] wird hervorgehoben, welche ein Merkmal als eine für den Kunden wichtige Eigenschaft eines Systems beschreibt, repräsentiert durch einen kundenverständlichen Ausdruck. Softwarekomponenten werden als unabhängige, installierbare und wiederverwendbare Bausteine definiert, die durch ihre Schnittstellen miteinander interagieren. Die klare Definition beider Begriffe ist fundamental für den Erfolg des automatisierten und kundenorientierten Ansatzes zur Applikationsableitung. Die Arbeit betont die Notwendigkeit einer klaren und verständlichen Terminologie, um Missverständnisse zu vermeiden und den Kunden effektiv in den Entwicklungsprozess einzubeziehen. Die konsistente Verwendung der Definitionen ist unerlässlich für die erfolgreiche Umsetzung des im Folgenden vorgestellten Ansatzes zur automatisierten Softwareentwicklung.

Der Text beschreibt die Multi-Attribute Utility Theory (MAUT) als einen Ansatz zur Komponenten-Auswahl. MAUT ermöglicht eine detaillierte Bewertung von Komponenteneigenschaften anhand von Gewichtungen und Nutzenfunktionen. Diese Funktionen sollen die individuellen Kundenanforderungen abbilden. Ein entscheidender Nachteil der MAUT-Methode ist die aufwendige Ermittlung der Nutzwerte und individuellen Substitutionsraten. Der Kunde muss komplexe Bewertungen vornehmen und z.B. quantifizieren, wie viel er für eine höhere Wiedergabequalität bereit ist zu zahlen. Diese subjektiven Präferenzen sind individuell unterschiedlich und oft schwer zu ermitteln, was die praktische Anwendung der MAUT-Methode erschwert. Die Komplexität der Methode kann für den Kunden unübersichtlich sein, besonders wenn er eine kostengünstige Lösung sucht. Die Bestimmung der richtigen Nutzwerte und Substitutionsraten stellt eine erhebliche Hürde für die breite Anwendung dar; viele Kunden sind nicht in der Lage, die notwendigen Informationen zu liefern oder die Fragen zu beantworten.

Als einfachere Alternative zur MAUT-Methode wird die Prioritätenliste vorgestellt. Diese Methode basiert auf einer Rangfolge von Eigenschaften, die der Kunde nach ihrer Bedeutung ordnet. Die Einfachheit und Verständlichkeit sind die größten Vorteile. Der Kunde kann intuitiv seine Prioritäten setzen, z.B. Preis, Marke oder Qualität. Die Ermittlung der Prioritäten ist sowohl für den Kunden als auch für den Anbieter wenig aufwendig. Im Gegensatz zur MAUT-Methode erfordert die Prioritätenliste keine komplexen Berechnungen oder Bewertungen. Jedoch ist das Ergebnis der Prioritätenliste nicht zwangsläufig optimal und es besteht die Möglichkeit, dass wichtige Aspekte übersehen werden. Die Methode ist weniger präzise als MAUT, bietet aber den Vorteil der einfachen Handhabung und hohen Akzeptanz beim Kunden. Die Wahl zwischen MAUT und Prioritätenliste hängt stark vom Kontext und den Anforderungen ab; für eine schnelle und einfache Komponentenauswahl bietet die Prioritätenliste einen praktikableren Ansatz.

Der Abschnitt vergleicht die beiden vorgestellten Methoden, MAUT und Prioritätenliste, und verdeutlicht ihre jeweiligen Vor- und Nachteile im Kontext der Komponenten-Auswahl. MAUT bietet eine präzisere, aber komplexere und für den Kunden aufwendigere Lösung. Die Prioritätenliste hingegen ist einfach und verständlich, liefert aber möglicherweise nicht das optimale Ergebnis. Die Wahl der geeigneten Methode hängt von den Anforderungen des Kunden und der Komplexität des Projekts ab. Für den hier verfolgten Ansatz der automatisierten und kundenorientierten Applikationsableitung wird aufgrund der Einfachheit und Kundenfreundlichkeit die Prioritätenliste favorisiert. Die Einfachheit der Prioritätenliste erlaubt eine Integration in ein automatisiertes System zur Komponentenauswahl. Die Limitationen bezüglich der Optimalität des Ergebnisses werden im weiteren Verlauf der Arbeit durch andere Mechanismen kompensiert. Die Entscheidung für die Prioritätenliste stellt einen Kompromiss zwischen Präzision und Praktikabilität dar, der für die Zielsetzung des Projekts als sinnvoll erachtet wird.

Der eigene Ansatz zur automatisierten Ableitung komponentenbasierter Applikationen beginnt mit der Analyse der Beziehungen zwischen den ausgewählten Merkmalen und den verfügbaren Komponenten. Der Fokus liegt darauf, die Komponenten zu identifizieren, die die vom Kunden gewünschten Merkmale implementieren. Die Anforderungen an die Komponenten werden präzisiert, um ein geeignetes Modell zu entwickeln, mit dem die wichtigen Eigenschaften der Komponenten erfasst werden können. Die Kernidee ist die automatisierte Auswahl der Komponenten basierend auf den vom Kunden spezifizierten Merkmalen. Dieser Prozess zielt darauf ab, eine Applikation zusammenzustellen, die den Kundenanforderungen bestmöglich entspricht. Die Beziehungen zwischen den Komponenten und den Merkmalen werden detailliert untersucht, um mögliche Konflikte oder Abhängigkeiten frühzeitig zu erkennen und zu berücksichtigen. Dies ist essentiell für eine effiziente und fehlerfreie automatisierte Ableitung der Applikation. Die Grundlage bildet ein Merkmalmodell, das alle relevanten Eigenschaften des zukünftigen Systems beinhaltet. Die Herausforderung besteht darin, diese Anforderungen in ein für die automatisierte Komponentenauswahl geeignetes Format zu überführen.

Ein zentraler Aspekt des eigenen Ansatzes ist die Entwicklung einer Methode zur automatisierten Komponenten-Auswahl. Hierbei wird die im vorherigen Abschnitt beschriebene Prioritätenliste verwendet, da sie für den Kunden einfach verständlich ist. Die Methode ermöglicht die Auswahl der Komponenten, die den Anforderungen am besten entsprechen. Um die Konfiguration der Ableitung zu speichern und später Modifikationen zu ermöglichen, wird ein Systemmodell entwickelt. Dieses Modell enthält Informationen über die verwendeten Komponenten, deren Konfigurationen und deren Abhängigkeiten. Die Speicherung der Prioritätenliste im Systemmodell ermöglicht die Nachvollziehbarkeit der Komponentenauswahl. Das Systemmodell dient als zentrale Datenbasis für den gesamten Prozess der automatisierten Applikationsableitung, von der Merkmalsauswahl bis zur finalen Konfiguration. Die Dokumentation aller Komponenten und ihrer Konfigurationen ist essentiell für die spätere Wartung und Erweiterung der Software. Das Systemmodell verbessert somit die Transparenz und Nachvollziehbarkeit des Prozesses, was die Qualitätssicherung und die spätere Anpassung der Software erleichtert.

Der Ansatz berücksichtigt auch die spätere Modifikation und Erweiterung von Applikationen. Jedes abgeleitete System wird in einem Systemmodell gespeichert, das dem Kunden zur Verfügung gestellt oder beim Händler verbleiben kann. Dieses Modell ermöglicht es, die verwendeten Komponenten und deren Konfigurationen zu analysieren und die Applikation gezielt anzupassen. Ein Werkzeug kann das Systemmodell laden und in Verbindung mit einem FORE-Datenmodell die bereits implementierten Merkmale analysieren. Der Prozess erlaubt die Ableitung eines neuen Systemmodells und die Erstellung eines Patchprogramms, das die Anpassung an die neuen Anforderungen vereinfacht. Der modulare Aufbau komponentenbasierter Software und die Dokumentation im Systemmodell ermöglichen einen einfachen Austausch von Komponenten und Erweiterungen ohne die gesamte Applikation neu installieren zu müssen. Dies verbessert die Wartbarkeit und Flexibilität der Software. Die Möglichkeit zur Modifikation ist ein entscheidender Vorteil des vorgestellten Ansatzes, da Software oft im Laufe der Zeit angepasst und erweitert werden muss.

Das Digitale Videoprojekt (DVP) dient als Fallbeispiel zur praktischen Überprüfung des entwickelten Ansatzes zur automatisierten Applikationsableitung. Als Kernkomponente wird die Open-Source-Software vdr (Video-Disk-Recorder) verwendet. Das DVP besteht aus einem Server und mehreren Client-PCs, die mit DVB-Karten (Digital Video Broadcast) ausgestattet sind. Der Server verarbeitet die Videosignale von den DVB-Karten und stellt sie den Clients über ein Streaming-Plug-in bereit. Der Datentransfer erfolgt über ein Standard-Netzwerkinterface (z.B. Ethernet). Zusätzlich bietet das System die Möglichkeit, Zusatzinformationen wie Programminformationen oder Feedback zur Gerätebedienung im laufenden Videobild einzublenden. Die Steuerung des Systems kann auch über einen Handheld-Computer erfolgen, wobei die Ergebnisse des IrDA-Projekts ([Bar02]) von [Die03] verwendet werden. Die konkrete technische Ausstattung des DVP, mit seinen DVB-Karten, dem Streaming-Server und den Clients, demonstriert ein reales Szenario zur Anwendung des Ansatzes. Das Projekt bietet somit eine ideale Testumgebung zur Validierung der entwickelten Methode.

Das DVP wird genutzt, um den Ansatz der automatisierten Applikationsableitung anhand eines konkreten Beispiels zu testen und zu validieren. Die Auswahl der Komponenten im DVP-System soll durch den automatisierten Prozess unterstützt werden. Die im DVP verwendeten Komponenten, wie z.B. verschiedene vdr-Plug-ins (Commander, Femon), demonstrieren die Herausforderungen bei der Komponentenauswahl anhand von Namen und Beschreibungen. Diese sind oft nicht aussagekräftig genug, um eine fundierte Entscheidung zu treffen. Schnittstellenmerkmale spielen bei der Erstinstallation einer Applikation eine untergeordnete Rolle, werden aber bei Erweiterungen wichtiger. Die Standardisierung von Schnittstellen und die Gliederung nach Anwendungsgebieten werden als Ansatz zur Verbesserung der Komponentenauswahl und zur Förderung eines Marktes für wiederverwendbare Komponenten diskutiert. Das DVP dient somit als praktische Anwendung zur Demonstration der Leistungsfähigkeit und der Grenzen des entwickelten Ansatzes. Die Ergebnisse des DVP fließen direkt in die Evaluierung und Weiterentwicklung der automatisierten Ableitung ein. Die Komplexität der Komponentenauswahl und -integration wird im Kontext des DVP verdeutlicht.

Die Beschreibung der Komponenten des DVP und ihrer Merkmale verdeutlicht die Problematik der Komponentenauswahl. Plug-ins wie Commander und Femon veranschaulichen, dass Komponentennamen allein oft keine ausreichende Information über den Funktionsumfang liefern. Die Bedeutung der Schnittstellen wird thematisiert, insbesondere im Hinblick auf die Erweiterung bestehender Systeme. Die Standardisierung von Schnittstellen wird als wichtiger Aspekt für die Verbesserung der Komponentenauswahl und den Aufbau eines Komponentenmarktes genannt. Zusätzlich werden Beschaffenheitsmerkmale als Entscheidungshilfe für die Auswahl, sowohl manuell als auch automatisiert, diskutiert. Dabei wird der Unterschied zwischen quantifizierbaren und nicht quantifizierbaren Eigenschaften hervorgehoben, wobei letztere eine komplexere Behandlung erfordern (z.B. Lizenzmodelle). Das DVP dient als Beispiel, um die Herausforderungen und Möglichkeiten der Komponentenauswahl im Kontext der automatisierten Applikationsableitung zu verdeutlichen. Die Fallstudie des DVP unterstützt die Entwicklung und Validierung des vorgeschlagenen Ansatzes.

Die Erstellung komponentenbasierter Software verursacht anfänglich höhere Kosten als die Entwicklung von Individualsoftware. Dieser Mehraufwand ist eine Investition in die Wiederverwendbarkeit der Komponenten. Die zusätzlichen Kosten werden auf 0% bis 120% der Entwicklungskosten für vergleichbare Individualsoftware geschätzt ([Pou97, S. 26f]). Dieser Kostenfaktor muss bei der Entscheidung für einen komponentenbasierten Ansatz berücksichtigt werden. Die Amortisation der höheren Anfangskosten erfolgt durch die Mehrfachverwendung der Komponenten in verschiedenen Applikationen. Eine einzelne Anwendung mag teurer sein, aber die Gesamtkosten sinken, je häufiger die Komponenten wiederverwendet werden. Die Wirtschaftlichkeit des komponentenbasierten Ansatzes hängt daher maßgeblich vom Grad der Wiederverwendbarkeit ab. Eine sorgfältige Planung und die Auswahl von Komponenten mit hohem Wiederverwendungspotenzial sind essentiell für die Wirtschaftlichkeit des gesamten Entwicklungsprozesses.

Der Text betont, dass die Wirtschaftlichkeit komponentenbasierter Software erst dann voll zum Tragen kommt, wenn die entwickelten Komponenten in vielen Anwendungen eingesetzt werden. Der anfängliche Mehraufwand bei der Entwicklung amortisiert sich erst durch die Vermeidung von Redundanzen in zukünftigen Projekten. Die Kostenersparnis entsteht durch die Vermeidung von wiederholter Entwicklung und das Wiederverwenden von getesteten und bewährten Komponenten. Der komponentenbasierte Ansatz kann somit als eine strategische Investition betrachtet werden, die langfristig die Entwicklungskosten senkt und die Effizienz erhöht. Die Skalierbarkeit der Entwicklung ist ein wichtiger Aspekt. Mit der Anzahl der Anwendungen, die die gleichen Komponenten verwenden, nimmt der wirtschaftliche Vorteil des komponentenbasierten Ansatzes zu. Daher ist eine strategische Planung und die Auswahl von Komponenten mit hohem Wiederverwendungspotential entscheidend für den langfristigen Erfolg und die Wirtschaftlichkeit des Projekts.