Komponentenbasierte Entwicklung domänenspezifischer Problemlösungen in Actionscript 3.0 sowie deren Verwaltung und Komposition am Beispiel eines Filter-frameworks für strukturierte Daten

Diplomarbeit von Mattes Groeger

Einleitung:

Die Geschichte der Softwareentwicklung reicht bis in die 50er Jahre zurück, als die ersten menschenlesbaren Programmiersprachen die maschinennahen Assemblersprachen ablösten. Bis heute werden die Sprachen mit dem Ziel, Entwicklungsprozesse effizienter zu gestalten, kontinuierlich weiterentwickelt.

Durch den Erfolg des Internets Mitte der 90er Jahre drängen neue Technologien auf den Markt. Ihr Fokus liegt auf der vereinfachten Generierung und Bereitstellung multimedialer, interaktiver Online-Inhalte. Die Flash-Technologie erfreut sich seither großer Beliebtheit, da vergleichbare Anforderungen mit den herkömmlichen Programmiersprachen nicht, oder nur unter großem Aufwand, realisierbar sind. Der wachsende Erfolg führt jedoch auch zu immer umfangreicheren und komplexeren Anwendungen.

Interaktionen lassen sich in Flash zunächst, auch ohne Programmierkenntnisse, durch einfache Skriptbefehle integrieren. Der resultierende Quelltext ist jedoch schwer zu warten und kann nicht wiederverwendet werden. Mit der Einführung von ActionScript wird die Skriptsprache schrittweise zu einer vollwertigen Programmiersprache weiterentwickelt. Heute profitiert der Entwickler sowohl von den komfortablen Visualisierungsmöglichkeiten, als auch von den Vorzügen ausgereifter Programmierkonzepte.

Im Gegensatz dazu versuchen Hersteller klassischer Programmiersprachen die Visualisierungsmöglichkeiten zu vereinfachen. Beispiele hierfür sind Microsoft Silverlight für .NET- oder Sun Microsystems JavaFX für Java-Entwickler. Durch zusätzliche Grafikwerkzeuge und einfache Skriptsprachen sollen Designer und grafisch orientierte Entwickler angesprochen werden. Die visuell geprägte Flash-Technologie hingegen versucht, durch eine verbesserte Programmiersprache, in die Domäne der klassischen Softwareentwicklung vorzudringen.

Der Beruf des Flash-Entwicklers hat sich erst innerhalb der letzten Jahre, parallel zu den Fortschritten in der Programmiersprache ActionScript, herausgebildet. Er entstammt dem interdisziplinären Berufsbild des „Flashers“ (Programmierer und Gestalter in einer Person). Trotz einer zunehmenden Professionalisierung der Entwicklungsprozesse fehlt dabei oftmals der notwendige „Blick über den Tellerrand“, um sich an bewährten Konzepten vergleichbarer Programmiersprachen (wie z.B. Java) zu orientieren. So bleiben einige Potentiale von ActionScript bisher ungenutzt.

Dazu gehört beispielsweise eine verbesserte Wartbarkeit und Wiederverwendbarkeit von Flash-Programmen. Die objektorientierte Programmierung (OOP) scheint hier zunächst gute Ansätze zu bieten, da sie auf der Klassenebene Prinzipien der Abstraktion und Kapselung forciert. Jedoch bilden häufig erst mehrere Objekte im Zusammenspiel die gewünschte Funktionalität. Mangels einer übergeordneten Strukturierungsmöglichkeit erschweren die Objektabhängigkeiten den Wiederverwendungsprozess einzelner Teilaspekte. Dies führt dazu, dass Individuallösungen entwickelt werden, anstatt auf bestehende Implementierungen zurückzugreifen.

Diese Arbeit befasst sich mit einem Prinzip, das in den klassischen Programmiersprachen bereits seit langem Anwendung findet – der komponentenbasierten Entwicklung. Anwendungsbezogene, abgegrenzte Problemstellungen werden hier in eigenständigen Softwarebausteinen strukturiert. Diese binären Komponenten besitzen klar definierte Schnittstellen, die eine Kommunikation zwischen den Bausteinen ermöglichen. Mehrere Komponenten lassen sich schließlich zu einer Gesamtanwendung zusammenfügen.

Ziel dieser Arbeit ist es, das Konzept der komponentenbasierten Entwicklung von den herkömmlichen Programmiersprachen auf Flash zu übertragen und dessen Anwendbarkeit zu untersuchen. Dazu werden Lösungsansätze und Werkzeuge aus dem Java-Umfeld evaluiert. Bei der Betrachtung geht es nicht darum, das Konzept in allen Details zu übernehmen. Vielmehr muss auf die Flash-spezifischen Anforderungen Rücksicht genommen werden. Die einzelnen Kriterien sind sinnvoll zu adaptieren und in bestehende Prozesse zu integrieren.

Im praktischen Teil der Arbeit werden die gewonnen Erkenntnisse anhand eines Beispiels dargestellt. Hierfür wird eine Filterkomponente entwickelt, die zusammen mit weiteren Bausteinen in eine Gesamtanwendung eingebunden wird.

Gang der Untersuchung:

Im folgenden Kapitel werden zunächst die Grundlagen der Softwareentwicklung mit Flash erörtert. Hierzu werden verschiedene Entwicklungsumgebungen für die Programmiersprache ActionScript vorgestellt. Es werden zudem die Probleme der bisher in Flash verwendeten Programmieransätze aufgezeigt.

Das nachfolgende Kapitel 3 beschäftigt sich mit den theoretischen Grundlagen der komponentenbasierten Entwicklung. Im Anschluss an die Definition des Komponentenbegriffs werden technische Besonderheiten der Komponentenentwicklung beleuchtet. Zudem werden weitere grundlegende Bestandteile des Paradigmas herausgearbeitet.

Kapitel 4 zeigt Lösungsansätze, die sich für die Umsetzung des Paradigmas eignen. Im Zentrum der Betrachtungen stehen Frameworks und Modelle aus dem Java-Umfeld, die sich auf die Flash-Technologie übertragen lassen. Untersucht werden auch Lösungsansätze in Flash und ActionScript.

Bevor die Anwendung des Paradigmas anhand eines praktischen Beispiels gezeigt wird, werden Aufgaben und Funktionsweise der umzusetzenden Komponente in Kapitel 5 dargestellt. Zudem werden aus den vorgestellten Lösungsansätzen geeignete Technologien für die Umsetzung ausgewählt.

Kapitel 6 zeigt anhand eines Filter-Frameworks die Besonderheiten der Komponentenentwicklung. Durch die gezielte Verwendung der Programmiersprache ActionScript wird, gemäß der in Kapitel 3 erarbeiteten Definition, eine Komponente realisiert.

Diese wird in Kapitel 7 im Rahmen der komponentenbasierten Entwicklung in eine Gesamtanwendung eingebunden. Dies zeigt, wie die Konfiguration und Vernetzung von Komponenten zu realisieren ist. Es wird zudem dargestellt, wie sich die Komponenten für eine Wiederverwendung bereitstellen lassen.

Kapitel 8 fasst die gewonnen Erkenntnisse zusammen und bewertet den Erfolg der Umsetzung. Mögliche Verbesserungen oder Erweiterungen der hier dargestellten Ergebnisse werden aufgezeigt.

Inhaltsverzeichnis:

	Abbildungsverzeichnis	VII
	Listingverzeichnis	IX
	Abkürzungsverzeichnis	XI
1.	Einleitung	1
1.1	Motivation	2
1.2	Zielsetzung	3
1.3	Aufbau der Arbeit	3
1.4	Konventionen	4
2.	Softwareentwicklung mit Flash	5
2.1	Entwicklungsumgebungen	7
2.2	Programmierparadigmen	10
2.3	Zusammenfassung	13
3.	Komponentenbasierte Entwicklung	15
3.1	Komponenten	17
3.1.1	Begriff	17
3.1.2	Abgrenzung	19
3.1.3	Komponentenentwicklung	20
3.2	Repository	23
3.3	Komposition	25
3.3.1	Komponentenmodelle	26
3.3.2	Objektvernetzung	26
3.3.3	IoC-Container	29
3.4	Zusammenfassung	30
4.	Lösungsansätze	33
4.1	Komponentenmodelle	34
4.1.1	JavaBeans	34
4.1.2	Flash-Komponentenmodelle	35
4.1.3	Enterprise JavaBeans	37
4.1.4	Bewertung	39
4.2	Lightweight Container	40
4.2.1	Spring	41
4.2.2	Prana	43
4.2.3	Parsley	44
4.2.4	Vergleich	45
4.3	Komponentenrepositories	48
4.3.1	Apache Ivy	48
4.3.2	Apache Maven	49
4.3.3	Bewertung	51
4.4	Zusammenfassung	52
5.	Filter-Framework	53
5.1	Einordnung	54
5.2	Anforderungen	56
5.3	Architektur	57
5.3.1	Datenmodell	57
5.3.2	Filter	58
5.3.3	Integration	60
5.4	Verwendung der Lösungsansätze	61
6.	Komponentenentwicklung	63
6.1	Kapselung	64
6.1.1	Sichtbarkeit	64
6.1.2	Namensräume	66
6.1.3	Datenstrukturen	68
6.2	Exportierte Schnittstellen	70
6.2.1	Filter	70
6.2.2	SmartFinder	72
6.2.3	Datenmodell	73
6.3	Importierte Schnittstellen	75
6.3.1	ProgressMonitor	75
6.3.2	Comparator	77
6.3.3	Logging	80
6.4	Zusammenfassung	81
7.	Komponenteneinsatz	83
7.1	Verwaltung mit Ivy	84
7.1.1	Metadaten	84
7.1.2	Repositories	85
7.1.3	Ivy verwenden	87
7.2	Komposition mit Parsley	89
7.2.1	Container konfigurieren	90
7.2.2	Container verwenden	93
7.3	Zusammenfassung	96
8.	Zusammenfassung	97
8.1	Bewertung	98
8.2	Verbesserungsmöglichkeiten	99
8.3	Ausblick	100
	Anhang A	102
	Anhang B	103
	Literaturverzeichnis	105

Textprobe:

Kapitel 3, Komponentenbasierte Entwicklung:

Die komponentenbasierte Softwareentwicklung wird in der englischen Sprache auch als Component-Based Development (CBD) oder Component-Based Software Engineering (CBSE) bezeichnet. Es handelt sich dabei um ein Entwicklungsparadigma, dessen Hauptziel es ist, eine Anwendung aus vorgefertigten – oder selbst erstellten – Bausteinen zusammenzusetzen. Die Aufteilung der Verantwortlichkeiten auf einzelne Komponenten (separation of concerns) trägt zur Reduktion der Gesamtkomplexität eines Softwaresystems bei. Als in sich geschlossene Einheiten können Komponenten ohne Auswirkungen auf ihre Umgebung verändert werden. Dieses Prinzip der lokalen Änderbarkeit vereinfacht die Wartung von komponentenbasierten Architekturen.

Da bestehende Lösungen in Form von Komponenten effizient wiederverwendet werden können, eignet sich dieses Konzept für das rapid prototyping und zeitkritische Projekte. Die Wiederverwendbarkeit trägt zudem zu einer verbesserten Softwarequalität bei, da die Funktionalitäten bereits zum Einsatz kamen und getestet wurden. Die klar definierten Schnittstellen ermöglichen zudem das parallele, unabhängige Erstellen von neuen Komponenten.

Schryen unterteilt die komponentenbasierte Entwicklung in drei wesentliche Phasen: Komponentenentwicklung, Komponentenverwaltung, Entwicklung mit Komponenten.

Diese drei Phasen bauen jeweils aufeinander auf, denn die Voraussetzung für eine Verwendung von Komponenten (application engineering) ist deren Vorhandensein. Eine zentrale Rolle spielt hierbei das Repository, in dem alle Komponenten verwaltet werden. Dies ist die erste Anlaufstelle, um nach Komponenten für eine bestimmte Anforderung zu suchen. Ist eine Komponente noch nicht vorhanden, so muss diese zunächst entwickelt werden (component engineering). Im Anschluss ist sie zum Repository hinzuzufügen, um eine effiziente Wiederverwendung für andere Projekte zu ermöglichen.

Analog zu dieser Einteilung lassen sich für den Entwicklungsprozess Rollen definieren, die sich für die einzelnen Phasen verantwortlich zeichnen. Im Rahmen der Enterprise JavaBeans (EJB) Spezifikation werden sieben verschiedene Rollen sowie deren Voraussetzungen und Aufgaben definiert. Bezogen auf die angeführten Phasen kommt der Rolle des Komponentenentwicklers (Component Provider) und der des Anwendungsentwicklers (Application Assembler) die wichtigste Bedeutung zu.

Der Komponentenentwickler ist für Entwurf, Implementierung und Dokumentation der Komponenten verantwortlich. Hingegen setzt der Anwendungsentwickler diese zu Gesamtsystemen zusammen (Assemblies). Er muss dabei kein konkretes Wissen über die internen Abläufe der Komponenten besitzen, sondern lediglich deren Schnittstellen korrekt bedienen. Hierfür benötigt er gegebenenfalls eine Komponentendokumentation.

Dieses Kapitel erarbeitet die theoretischen Grundlagen der komponentenbasierten Entwicklung. Es bildet damit die Voraussetzung für die Evaluierung bestehender Lösungsansätze sowie deren Übertragung auf ActionScript. Dazu werden die einzelnen Phasen der komponentenbasierten Entwicklung detailliert betrachtet. Abschnitt 3.1 definiert zunächst den Begriff der Komponente und betrachtet deren softwaretechnische Besonderheiten. In Abschnitt 3.2 werden Anforderungen an die Komponentenverwaltung herausgearbeitet. Mit der dritten Phase beschäftigt sich Abschnitt 3.3. Hier werden Möglichkeiten der Komponentenkomposition aufgezeigt. Es folgt eine Zusammenfassung am Ende des Kapitels (Abschnitt 3.4).

Komponenten:

Begriff: In der Literatur existieren unterschiedliche Auffassungen des Komponentenbegriffs. Schryen zitiert beispielsweise eine Definition, die auf nahezu alle Codefragmente zutrifft:

NATO: „Komponenten sind alle an einem Softwareentwicklungsprozeß beteiligten Artifakte (Programme, Entwurfsmodelle usw.)“.

Neben dieser allgemeinen Interpretation finden sich präziser formulierte Definitionen. Szyperski zufolge lassen sich Komponenten unabhängig voneinander erstellen und zu Gesamtsystemen zusammensetzen: „[…] software components are executable units of independent production, acquisition, and development that can be composed into a functioning system“.

Zudem hebt er den ausführbaren Charakter – die binäre Repräsentation – hervor. Komponenten müssen unabhängig von Entwicklungs- und Ausführungsumgebungen existieren können. Dies unterstreicht auch die Definition von Gruhn: „Eine Komponente ist ein Stück Software in binärer Form, das eine kohärente Funktionalität bietet“.

Komponenten bilden demnach unteilbare Einheiten, die sich durch zusammenhängende Funktionalitäten auszeichnen. Die binäre Repräsentation charakterisiert zugleich den Black-Box-Charakter einer Komponente. Da lediglich die Schnittstellen zur Verfügung stehen, ist eine direkte Manipulation der Interna ausgeschlossen. Dies macht auch die folgende Definition deutlich.

Bosch: „Eine Softwarekomponente ist das Medium der Komposition von Systemen mit explizit definierten bereitgestellten Schnittstellen, benötigten Schnittstellen, Konfigurationsschnittstellen und Qualitätsattributen.“ Laut Bosch muss eine Komponente über explizite Schnittstellen verfügen, die eine Konfiguration und Verwendung ermöglichen. Zudem macht er deutlich, dass mehrere Komponenten zu einer neuen Komponente verbunden werden können. Innerhalb einer solchen Komposition ist die bereitgestellte Schnittstelle gleichzeitig die benötigte Schnittstelle einer übergeordneten Komponente. Dieser Aspekt wird in Abschnitt 3.1.3 im Rahmen der importierten und exportierten Schnittstellen betrachtet. Qualitätsattribute können die Einsatzmöglichkeiten und Leistungen einer Komponente beschreiben. Diese Informationen lassen sich über eine separate Dokumentation und spezielle Metadaten bereitstellen.

Die hier vorgestellten Definitionen treffen keine Aussagen darüber, nach welchen Programmierparadigmen die Realisierung einer Komponente zu erfolgen hat. Die Untersuchung in Kapitel 2 hat gezeigt, dass Komponenten und Objekte eine hohe Affinität aufweisen. So wird die objektorientierte Programmierung in vielen Architekturen zur Realisierung von Komponenten eingesetzt.

Ein wichtiger Unterschied der Komponenten zur Objektorientierung ist ihr erhöhtes Abstraktionsniveau. Komponenten haben eine fachliche, anwendungsbezogene Bedeutung, während bei Objekten die technische, systembezogene Funktionalität im Vordergrund steht. Komponentenorientierte Architekturen lassen sich einfacher strukturieren.

Zusammenfassend lassen sich für eine Komponente folgende Merkmale definieren:

Domänenspezifisch: Sie stellt eine anwendungs- und keine systembezogene Funktionalität zur Verfügung.

Binär: Sie liegt in einem ausführbaren, kompilierten Zustand vor.

Importierte/Exportierte Schnittstellen: Sie stellt ihre Funktionalität über Schnittstellen zur Verfügung. Benötigte Funktionalitäten werden importiert.

Black-Box: Eine Verwendung ist nur über die Schnittstellen möglich. Ein Zugriff auf die Interna ist nicht erlaubt.

Komposition: Komponenten lassen sich hierarchisch zu neuen Komponenten kombinieren.

Abgrenzung:

Komponenten ermöglichen eine Wiederverwendung von Funktionalitäten ohne Kenntnis von deren Implementierung besitzen zu müssen. In diesem Zusammenhang existieren weitere Technologien und Konzepte mit ähnlichen Bestrebungen. In diesem Abschnitt werden die – nach Meinung des Autors – Bedeutendsten von dem Komponentenbegriff abgegrenzt.

Laut Gamma bestehen Bibliotheken ebenfalls aus zusammengehörigen Klassen, die jedoch einem bestimmten funktionalen Zweck dienen. Dies können beispielsweise Hilfsklassen sein, die Datenstrukturen zur Verfügung stellen. Im Gegensatz zu Komponenten besitzen sie keine anwendungsbezogene Funktionalität. Bibliotheken bieten auf der Basis konkreter Implementierungen einen sehr hohen Grad der Wiederverwendbarkeit.

Im Gegensatz zu Bibliotheken ermöglichen Frameworks die Wiederverwendung auf Architekturebene (design reuse). Sie bestehen aus mehreren interagierenden Klassen, die zusammen das Rahmenwerk für ein bestimmtes Architekturproblem vorgeben. In der Regel ist ein Framework allein nicht lauffähig. Erst durch das Erweitern von abstrakten Klassen oder das Implementieren von frameworkspezifischen Schnittstellen (vgl. „Plug-ins“ im Anschluss) kann es für eine bestimmte Anwendung eingesetzt werden. Dabei führt das Framework die zusätzlichen Erweiterungen automatisch aus. Der Kontrollfluss der Anwendung wird an das Framework abgegeben – es besitzt somit die Ablaufhoheit.

Häufig stellt ein Framework bereits Standardimplementierungen zur Verfügung, um einen schnellen Einsatz zu ermöglichen. Gamma nennt als wesentliche Vorteile die verkürzte Entwicklungszeit sowie eine bessere Wartbarkeit der Anwendung. Da dem Programmierer durch das Rahmenwerk wesentliche Architekturentscheidungen abgenommen werden, schränkt es jedoch die Umsetzung eigener Designvorstellungen ein.

Schryen zufolge haben Frameworks – wenn sie die Struktur eines Softwaresystems vorgeben – globalen Charakter. Sie grenzen sich damit von Komponenten ab, die anwendungsbezogene Teilprobleme lösen. Da Frameworks um eigene Implementierungen erweitert werden können, besitzen sie zahlreiche Abhängigkeiten zum Verwender. Sofern die Klassen des Rahmenwerks jedoch eine zusammengehörige Funktion bereitstellen, lässt es sich laut Wunderlich als feingranulare Komponente betrachten.

Ein Plug-in kann eine Software um zusätzliche Funktionen erweitern. Dazu muss die Software eine öffentliche, standardisierte Plug-in-Schnittstelle zur Verfügung stellen. Das Plug-in bedient diese Schnittstelle durch seine konkrete Implementierung. Es kann sowohl als Klasse, aber auch durch eine Komponente implementiert sein. Eingesetzt werden Plug-ins überall dort, wo Standardimplementierungen für konkrete Anwendungsfälle angepasst werden müssen. Beispielsweise innerhalb von Frameworks, da diese lediglich ein sehr abstraktes Rahmenwerk vorgeben.