Komponentenbasierte Software-Entwicklung

Transkript

1 Komponentenbasierte Software-Entwicklung Marc Monecke Praktische Informatik Fachbereich Elektrotechnik und Informatik Universität Siegen, D Siegen 20. Mai 2003 Zusammenfassung In der komponentenbasierten Software-Entwicklung dienen Software-Komponenten zur Strukturierung komplexer Systeme. Komponenten sind auch wiederverwendbare Einheiten, die einmal entwickelt und mit geringem Aufwand in unterschiedlichen Systemen eingesetzt werden sollen. In diesem Lehrmodul gehen wir zunächst kurz auf die Wiederverwendung ein und betrachten dann die Ziele und Merkmale von Software-Komponenten genauer. Anschließend werden einige Komponentenmodelle kurz vorgestellt und Anmerkungen zum Einsatz der Komponententechnologie bei der Software-Produktion gemacht. Inhaltsverzeichnis 1 Einleitung und Motivation Wiederverwendung Ziele der Wiederverwendung Unterschiede zwischen den verschiedenen Wiederverwendungsarten White-box- und black-box-wiederverwendung: Komponenten-Begriff Einige Definitionen für Komponenten Zentrale Begriffe Angestrebte Eigenschaften von Komponenten Granularität Schnittstellen Semantik Komponentenmodelle Elemente eines Komponentenmodells Beispiele i

2 3.2.1 JavaBeans CORBA ActiveX/(D)COM Enterprise JavaBeans Einsatz von Komponententechnologie Vorgehen und Prozesse Komponenten und die Software-Industrie Zusammenfassung 10 ii

3 1 Einleitung und Motivation Software-Entwickler müssen häufig Lösungen für Probleme erarbeiten, die sie selbst oder andere Software-Entwickler bereits gelöst haben Ziel: Wiederverwendung dieser Lösungen Software-System in Software-Komponenten aufteilen Komposition des Systems aus Komponenten jede Komponente stellt Dienste bereit, die andere Komponenten nutzen können Komponenten kommunizieren miteinander Vorbild: Hardware-Branche Software-IC 1.1 Wiederverwendung Wiederverwendbar sind unterschiedliche Dinge: Ideen : was ähnliches haben wir schonmal gemacht... Vorgehensweisen : Kochbuch-Ansatz Bildschirm-Layouts, Bedienkonzepte und -abstraktionen: dadurch können verschiedene Programme unter einer graphischen Benutzeroberfläche ähnlich bedient werden Entwürfe, Architekturen, Entwurfsmuster (design reuse): mehr oder weniger abstrakte Beschreibung der Problemlösung einzelne Funktionen, Klassen: letztere mit der Möglichkeit zur Erweiterung Quelltext-Ausschnitte: copy & paste ganze Programme oder Bibliotheken: bequem, sofern sie zum Problem passen. Gutes Beispiel ist die Unix toolbox. Komponenten : intuitiv klar als (beliebiger) Baustein. Hier greift die Lego-Stein- Metapher [3]. Allgemein formuliert [1]: Wiederverwendung von Software ist das erneute Anwenden von bei der Entwicklung eines Softwaresystems entstandenen Artefakten und angesammeltem Wissen bei der Entwicklung eines neuen Softwaresystems, um den Aufwand zur Erstellung und Pflege dieses neuen Systems zu reduzieren. Maßstab Analog zum programming-in-the-small und programming-in-the-large werden auch bei der Wiederverwendung zwei Stufen unterschieden: reuse-in-the-small: Routinen, Klassen, Pakete, Bibliotheken; meist sprach- oder plattformspezifisch hoher Integrationsaufwand reuse-in-the-large: Sub-, Komplettsysteme hoher Anpassungsaufwand 1

4 1.1.1 Ziele der Wiederverwendung Aufwand und Kosten reduzieren: Je häufiger ein Baustein verwendet wird, desto geringer fällt der initiale Aufwand für seine Entwicklung ins Gewicht. Qualität erhöhen: Je häufiger ein Baustein verwendet wird, desto weniger Fehler wird er enthalten. Wartung erleichtern: Werden die gleichen Komponenten mehrfach im gleichen oder in verschiedenen Systemen verwendet, muß sich ein Entwickler nur einmal mit ihrer Funktionsweise auseinandersetzen, um die Funktion des Systems zu verstehen. Andererseits wirkt sich die Änderung, Korrektur oder Erweiterung einer zentralen Komponente (hoffentlich positiv) an vielen Stellen des Systems aus. Einheitliches Verhalten und Aussehen erreichen: Gleiche Komponenten, etwa im GUI, sehen an verschiedenen Stellen im System gleich aus und verhalten sich gleich. Dadurch wird die Bedienung für den Benutzer erleichtert. Auch ist das Systemverhalten in einer bestimmten Situation so leichter zu verstehen Unterschiede zwischen den verschiedenen Wiederverwendungsarten Anpaßbarkeit: z.b. Parametrisierbarkeit, Konfigurierbarkeit, Änderbarkeit der wiederverwendeten Lösung Flexibilität: z.b. Plattform(un)abhängigkeit erforderlicher Arbeitsaufwand: ein Programm kann direkt eingesetzt werden, ein Entwurf muß zuerst implementiert werden Abstraktionsstufe: ein Quelltext-Ausschnitt löst das Problem in einem ganz bestimmten Kontext und unter ganz bestimmten Annahmen; ein Entwurfsmuster beschreibt den Lösungsansatz für eine Klasse ähnlicher Probleme Zeitpunkt: Analyse, Entwurf, Implementierung oder Laufzeit des Systems White-box- und black-box-wiederverwendung: Wiederverwendung kann auch danach klassifiziert werden, welche Informationen der Nutzer eines Bausteins über diesen Baustein benötigt: Bei der white-box-wiederverwendung ist die innere Struktur und Funktionsweise des wiederverwendeten Bausteins bekannt und kann bei der Anpassung und beim Einsatz des Bausteins berücksichtigt werden. Bei der black-box-wiederverwendung ist die innere Struktur nicht bekannt. Der Baustein präsentiert sich als schwarzer Kasten, von dem nur die Schnittstelle bekannt ist. 2 Komponenten-Begriff Software-Komponenten tauchen in vielen Situationen auf. Weit verbreitet sind Komponenten, aus denen graphische Benutzungsschnittstellen (graphical user interface, GUI) zusammengesetzt werden. Diese Komponenten sind direkt manipulierbar, können also an der gewünschten Stelle plaziert und in Größe, Farbe und weiteren Eigenschaften angepaßt werden. 2

5 haben beim Entwurf die gleiche Repräsentation und zum Teil das gleiche Verhalten wie zur Laufzeit des resultierenden Systems. haben eine intuitiv klare Bedeutung. Beim Zusammensetzen eines GUI werden Entwurfswerkzeuge (GUI builder) verwendet und die Komponenten oft direkt aus einer Palette ausgewählt und an die gewünschte Position gezogen. Am anderen Ende des Spektrums liegen Komponenten, die komplexe Aufgaben in Geschäftsanwendungen übernehmen. Diese Komponenten haben oft eine direkte Entsprechung in der Geschäftswelt (etwa Kunde, Lieferung, Vertrag) und bilden deren Eigenschaften, Verhalten und Interaktionen ab. 2.1 Einige Definitionen für Komponenten Allgemein sind Komponenten Bausteine, aus denen Software-Systeme zusammengesetzt werden. Es gibt zahlreiche Definitionen zum Begriff der Software-Komponente, die unterschiedliche Aspekte in den Vordergrund stellen [1, 3]: Flexibler Einsatz: Components are software units that are context-independent both in the conceptual and the technical domain. Kapselung der Funktionalität und Zugriff über Schnittstellen: A component denotes a self-contained entity (black box) that exports functionality to its environment and may also import functionality from its environment using well-defined and open interfaces. In this context, an interface defines the syntax and semantics of the functionality it comprises (i.e., it defines a contract between the environment and the component). Components may support their integration into the surrounding environment by providing mechanics such as introspection and configuration functionality. Schnittstellen und Verträge: Eine Softwarekomponente ist ein Baustein mit ausdrücklichen Kontextabhängigkeiten und vertraglich spezifizierten Schnittstellen. Eine Softwarekomponente kann unabhängig verwendet werden und leicht mit anderen Komponenten integriert werden.[2] Granularität von Komponenten und ihre Kooperation im System: Eine Komponente ist ein Stück Software, das klein genug ist, um es in einem Stück erzeugen und pflegen zu können, groß genug, um eine sinnvolle Funktionalität zu bieten und eine individuelle Unterstützung zu rechtfertigen, sowie mit standardisierten Schnittstellen ausgestattet ist, um mit anderen Komponenten zusammenzuarbeiten. Die letzte Definition soll als Basis für die folgenden Ausführungen betrachtet werden. 2.2 Zentrale Begriffe Abbildung 1 enthält einige zentrale Begriffe und ihre Beziehungen [3]. 3

6 bietet an Schnittstelle 1..n 0..n 1 enthält 0..n Operation Komponente 1 0..n Instanz von Komponenten instanz implementiert von 0..n 0..n Klasse 1 0..n Objekt Instanz von Abbildung 1: Zentrale Begriffe und ihre Beziehungen 2.3 Angestrebte Eigenschaften von Komponenten Mit dem Komponentenbegriff sind eine Reihe von Anforderungen verbunden. Erst wenn diese Anforderungen erfüllt werden, können Komponenten ihre wahren Vorteile ausspielen [2]: Wohldefinierter Zweck: Eine Komponente soll einem wohldefinierten Zweck dienen. Sie ist also auf eine bestimmte Aufgabe spezialisiert, stellt aber keine eigenständige Anwendung dar. Statt dessen wird die Komponente in den Anwendungskontext eingebettet. Wiederverwendbarkeit, Konfigurierbarkeit, Anpaßbarkeit: Komponenten sollten in ihrem Anwendungskontext leicht wiederverwendbar sein. Der Anwendungskontext variiert abhängig von der Spezialisierung der Komponenten etwa von der einfachen GUI-Komponente zur Komponente, die bestimmte Aufgaben in einer Geschäftsanwendung übernimmt. Voraussetzung für eine Problemlose Wiederverwendung ist die Möglichkeit, eine Komponente an die jeweiligen Anforderungen anzupassen, ohne ihre Implementierung ändern zu müssen (customizing). Kontextunabhängigkeit: Rahmenbedingungen wie Programmiersprache, Plattform und Entwicklungsumgebung sollten beim Komponenteneinsatz keine Rolle spielen. Alle relevanten Merkmale der Komponente sollen in ihrer Schnittstelle definiert sein. Portabilität und Programmiersprachen-Unabhängigkeit: Komponenten sollten in beliebigen Sprachen (objektorientiert, prozedural, funktional, logisch) entwickelt werden können. Die resultierende übersetzte Komponente sollte plattformunabhängig einsetzbar sein und mit beliebigen anderen Komponenten interagieren können. Ortstransparenz: Das Verhalten der Komponente soll unabhängig davon sein, wo die Komponente ausgeführt wird. Der Kontext, in dem sich die Komponente befindet (Netzwerkknoten, Prozeß) ist also für den Nutzer der Komponente transparent. Trennung von Schnittstelle und Implementierung, Selbstbeschreibungsfähigkeit: Die Dienste, die eine Komponente anbietet, und die Schnittstellen, über die diese Dienste aufgerufen werden, sollen unabhängig von der Implementierung der Komponente spezifiziert werden. Die Implementierung der Komponente ist also für den Benutzer transparent; interne Details werden explizit verborgen. Komponenten sollen die Schnittstelle einer Komponente abfragen können, um so Informationen über die angebotenen Dienste zu erhalten und eine lose und späte Koppelung 4

7 zwischen Komponenten zu ermöglichen. Integrations- und Kompositionsfähigkeit, Plug & Play: Komponenten sollten dynamisch zur Laufzeit zu größeren Komponenten zusammengefaßt werden können also nicht nur zur Entwurfszeit. Die hierzu nötigen Basisdienste werden von der zugrundeliegenden Infrastruktur bereitgestellt. Eine Komponente soll sich selbst in einer solche Infrastruktur installieren und die nötigen Initialisierungen und Registrierungen ausführen. Dadurch ist eine Komponente ohne weiteren Aufwand für den Nutzer sofort einsetzbar (plug & play). Bewährtheit: Komponenten sollen zuverlässig und robust funktionieren. Voraussetzung sind umfangreiche und sorgfältige Tests. Qualitätssicherungsmaßnahmen sind die Voraussetzung dafür, aus einer Menge von Klassen eine Komponente machen zu können. Binärcode-Verfügbarkeit: Komponenten liegen in übersetzter Form vor, können also direkt (auf der passenden Plattform) eingesetzt werden. Der Quelltext ist meist nicht verfügbar. Existieren Varianten für verschiedene Plattformen, funktionieren die Komponenten auf allen Plattformen gleich Granularität Bei der Verwendung von Komponenten stellt sich die Frage, welche Granularität diese haben sollen, also aus Sicht der Komponente: Welchen Umfang soll die Komponente haben? Welche Funktionen soll sie enthalten, welche Dienste anbieten? Wie soll die Schnittstelle aussehen? aus Sicht des Systems: Wie soll die Funktionalität des Systems auf die verschiedenen Komponenten verteilt werden? Also wie sieht die Zerlegung des Systems in Komponenten aus, welche Komponenten müssen dazu gekauft oder entwickelt werden? Werden Dinge aus dem Anwendungskontext als Komponenten repräsentiert, ergeben sich diese meist von selbst etwa Rechnung, Produkt, Report, Zeichenfläche, Menü. Bei abstrakteren Dingen (Prozeßmaschine, Datenbankkern) ist die Zerlegung meist willkürlich. Maße für den Umfang Dabei ist die Größe oder der Umfang einer Komponente schwierig zu bestimmen. Folgende Maße sind sinnvoll. Relevanz für den Anwendungsbereich, Anteil an der Semantik und Funktionalität des Gesamtsystems Umfang der Schnittstelle, also Zahl der angebotenen Dienste Code-Größe, kann beim Übertragen von Komponenten relevant sein Drei Granularitätsstufen Trotz der genannten Schwierigkeiten bei der Gewichtung von Komponenten kann man grob drei Granularitätsstufen unterscheiden (Tabelle 1). 5

8 feinkörnig mittelkörnig grobkörnig eher passiv z.b. Versandanschrift, die gedruckt, angehängt und gelesen werden kann leicht wiederverwendbar, einfache Schnittstelle, aber hoher Integrationsaufwand aktiv, enthalten meist Interaktionen z.b. Einkaufskorb, Zahlungsabwicklung ermöglichen Wiederverwendung komplexerer Funktionen aktiv, übergreifend, kontrollierend/steuernd z.b. Lagerverwaltung direkte Wiederverwendung komplexer Funktionen, aber komplizierte Schnittstelle, aufwendige Parametrisierung, also schwierige Verwendung 2.4 Schnittstellen Tabelle 1: Granularität von Software-Komponenten stellen die Grenze einer Komponente dar bestimmen, wie das Gesamtsystem aus Komponenten zusammengesetzt werden kann und wie die Komponenten miteinander interagieren legt die Abstraktion fest, die die Komponente anbietet kann auch als Vertrag betrachtet werden nach außen angebotene Dienste, unabhängig von ihrer Implementierung ist es möglich, für eine Komponente mehrere Schnittstellen zu definieren, können Sichten definiert und darin Operationen zusammengefaßt werden Darstellung der Schnittstelle graphisch, z.b. mit UML Programmiersprachen-unabhängig mit Interface Definition Language (IDL), z.b. CORBA IDL Bei der Implementierung wird die Programmiersprachen-unabhängige Spezifikation auf die jeweilige Zielsprache abgebildet. Programmiersprachen-abhängig, also direkt in einer Programmiersprache wie Java Hier werden Schnittstellen auf einer geringeren Abstraktionsstufe spezifiziert. selbstbeschreibend, die Schnittstelle kann also dynamisch von Werkzeugen oder anderen Komponenten abgefragt werden. 2.5 Semantik Funktionalität und Verhalten von Komponenten muß klar definiert sein Spezifikation verbale Spezifikationen lassen Interpretationsspielraum ungenau mathematische Formalismen zu aufwendig Protokoll beschreibt korrekte Folgen von Operationsaufrufen 6

9 bei Verwendung der Komponente korrekte Nutzung überwachbar daraus Semantik teilweise ableitbar mögliche Darstellungen: Zustandsautomat zu aufwendig Vor-/Nachbedingungen, Zusicherungen 3 Komponentenmodelle Komponentenmodelle definieren den Rahmen sowohl für die Entwicklung als auch für die Ausführung von Komponenten. Sie bestimmen wie Komponenten zusammengesetzt und verknüpft werden können wie Komponenten miteinander kommunizieren und zusammenarbeiten können welche Mechanismen und Dienste den Komponenten von einer Infrastruktur zur Verfügung gestellt werden etwa für Verteilung, Persistenz und Sicherheit In Abbildung 2 ist die Einbettung von Komponentenmodellen in die komponentenorientierte Software-Entwicklung dargestellt [3]. Komponenten modell Grundlage für konkrete Komponenten zusammen gesetzt zu Komponentenbasierte Anwendung kompatibel zur Entwicklung von betrieben in Framework Entwicklungs werkzeuge Middleware Abbildung 2: Komponentenmodelle und ihre Beziehungen zu anderen Konzepten 3.1 Elemente eines Komponentenmodells Ein Komponentenmodell legt folgende Aspekte der Entwicklung und Benutzung von Komponenten fest [4]: Schnittstellen: Eigenschaften und Verhalten von Komponenten, Sprachen zur Schnittstellen-Spezifikation (IDL) Namen: Global eindeutige Namen für Schnittstellen und Komponenten Meta-Daten: Informationen über Komponenten und Schnittstellen; Dienste für den Zugriff auf diese Informationen Interoperabilität: Kommunikation und Datenaustausch zwischen Komponenten (heterogen, verschiedene Hersteller) Konfiguration: Dienste zur Anpassung und Konfiguration von Komponenten (customization) werden von Konfigurations- und Administrationswerkzeugen genutzt 7

10 Komposition: Schnittstellen und Regeln für das Zusammensetzen von Komponenten zu größeren Strukturen Evolution: Dienste und Regeln für den Austausch von Komponenten gegen neuere Versionen Zusammenpacken und ausliefern: Zusammenfassen der Implementierung und aller benötigten Ressourcen einer Komponente, so daß sie ausgeliefert, installiert und konfiguriert werden kann 3.2 Beispiele Einige bekannte Komponentenmodelle sind: JavaBeans visuell manipulierbare Java-Komponenten Bean jeweils durch Java-Klasse implementiert Schnittstelle gemäß Vorgaben gestalten hauptsächlich für mittelkörnige GUI-Elemente Verteilung, Verbunddokumente nicht direkt unterstützt CORBA Common Object Request Broker Architecture Bestandteil der Object Management Architecture (OMA) von OMG spezifiziert (ABM-Herstellerkonsortium: Anyone but Microsoft) für verteilte, heterogene Systeme Objektmodell und Object Request Broker (ORB), der Infrastruktur implementiert (Middleware) Schnittstellenbeschreibung Programmiersprachen-unabhängig in CORBA-IDL ActiveX/(D)COM (Distributed) Component Object Model eher zufällig entstanden bei der Wartung und Weiterentwicklung der Microsoft-Produkte daher Konzepte und Begriffe eher unsauber, vielfach geändert Grenze zwischen Betriebssystem und Komponentenmodell nicht klar (z.b. registry des Betriebssystems zum Auffinden von Komponenten genutzt) genutzt für Verbunddokumente in denen spezialisierte Komponenten für die Darstellung, Manipulation und automatische Aktualisierung unterschiedlicher Dokument- Bestandteile zuständig sind etwa Text, Grafik, Tabellen Enterprise JavaBeans Komponentenmodell für serverseitige Komponenten in Geschäftsanwendungen 8

11 plattformunabhängig, verteilt Java-spezifisch; über CORBA auch heterogene Komponenten möglich Spezifikation enthält Basisdienste u.a. für Kommunikation, Persistenz, Sicherheit s. auch Lehrmodul aus DBS II 4 Einsatz von Komponententechnologie 4.1 Vorgehen und Prozesse Die Nutzung von Komponententechnologien muß auch bei der Gestaltung des Software- Entwicklungsprozesses berücksichtigt werden. Oft geht mit der Umstellung auf komponentenbasierte Software-Entwicklung auch ein weitergehender Technologiewechsel einher, der die verwendete Programmiersprachen, Methoden und Werkzeuge betrifft. Solche Änderungen können zu weitgehenden Konsequenzen innerhalb eines Unternehmens führen. Grundsätzlich besteht das Vorgehensmodell aus folgenden Schritten: 1. Analyse & Definition: Hier werden wie üblich die Anforderungen an das System festgelegt. 2. Entwurf: Das Gesamtsystem wird auf Basis des gewählten Komponentenmodells in einzelne Komponenten zerlegt und es werden die Anforderungen an das Gesamtsystem auf diese Komponenten verteilt. Dabei müssen die Dienste festgelegt werden, die jede Komponente anbietet, und es muß die Interaktion der Komponenten untereinander bestimmt werden. Die ermittelten Komponenten können nun auf dem Komponentenmarkt eingekauft oder entwickelt werden (make-or-buy-entscheidung). 3. Komponenten-Entwicklung: Die Komponenten können weitgehend unabhängig voneinander entwickelt werden. Ziel des komponentenbasierten Ansatzes ist es ja, Funktionen innerhalb von Komponenten zu kapseln und nach außen über eine wohldefinierte Schnittstelle anzubieten. Prinzipiell kann also für jede Komponente ein separater Entwicklungsprozeß instantiiert werden. 4. Integration: Die entwickelten oder gekauften Komponenten werden zum Gesamtsystem zusammengesetzt. Hier muß sichergestellt werden, daß die Summe der Komponentenfunktionen die Funktion des Gesamtsystems ergibt. Bei der Integration müssen die Komponenten passend konfiguriert und so an die konkreten Anforderungen angepaßt werden. 4.2 Komponenten und die Software-Industrie Die konsequente Nutzung von Komponenten würde sich auch auf Software-Unternehmen auswirken, die als Hersteller und als Nutzer von Komponenten auftreten können. Zwar sind einige Auswirkungen auch heute schon erkennbar vom Software-IC ist die Software- Industrie aber noch weit entfernt. Zukauf von Komponenten und ihre Integration in eine bestehende Software- Landschaft: Voraussetzung dafür sind klar definierte Schnittstellen, über die neue Komponenten mit dem vorhandenen System kommunizieren können, und die Möglichkeit zur Anpassung der Komponenten an die konkrete Situation. 9

12 Verkauf von eigenentwickelten Komponenten, die von anderen Entwicklern in anderen Kontexten erneut eingesetzt werden können: Nicht jede (Menge von) Klasse(n), die für eine bestimmte Anwendung entwickelt wurden, kann sinnvoll als Komponente angeboten werden. Voraussetzungen sind die hohe Qualität, Konfigurierbarkeit und eine hinreichende Allgemeingültigkeit (s. auch Abschnitt 2.3). Ein allgemeiner Komponentenmarkt, auf dem Software-Komponenten wie elektronische Bauteile gehandelt werden, existiert aber zur Zeit noch nicht. Arbeitsteilung zwischen Komponentenentwickler und dem eigentlichen Anwendungsentwickler: Insbesondere muß sich letzterer nicht mehr um Aufgaben kümmern, die außerhalb der Anwendungsdomäne liegen, wie etwa die Bereitstellung von Basisdiensten zur Datenverwaltung, für GUI oder Sicherheit. 5 Zusammenfassung Mit Komponenten können komplexe Software-System strukturiert werden Komponenten sind wiederverwendbare Bausteine, die theoretisch auf einem Komponentenmarkt ähnlich wie elektronische Bauteile gehandelt werden können Ein umfassender Einsatz der Komponententechnologie wirkt sich auf die Software- Industrie und die verwendeten Entwicklunsprozesse aus Mögliche Vorteile sind: geringere Kosten, schnellere Entwicklung höhere Qualität bessere Wartbarkeit bessere Erweiterbarkeit und Anpaßbarkeit Komponentenmodelle definieren den Rahmen, in dem Komponenten entwickelt und ausgeführt werden Literatur [1] F. Griffel. Componentware Konzepte und Techniken eines Softwareparadigmas. dpunkt Verlag für digitale Technologie, Heidelberg, [2] V. Gruhn and M. Schneider. EJB 2.0 Anwendungen. Addison-Wesley, [3] V. Gruhn and A. Thiel. Komponentenmodelle. Addison-Wesley, (zu EJB Version 1.1). [4] G. T. Heinemann and W. T. Councill, editors. Component-Based Software Engineering. Addison-Wesley, New York,