Home CDF Idee/Architektur
Idee und Architektur | Drucken |

Dieser Abschnitt geht auf grundlegende Begriffe ein, die zum Verständnis des Component Description Framework notwendig sind. Anschließend wird das CDF-Framework sowie der dazu passende Editor im Detail vorgestellt und seine Architektur grob dargelegt.

Grundlagen

Komponenten

Moderne Software-Entwicklung erfolgt oftmals mit Hilfe wiederverwendbarer Komponenten, welche unter Anderem auch als Module bezeichnet werden können - beide Begriffe werden in der Folge gleichberechtigt verwendet. Im Umfeld von Eclipse werden diese mit Hilfe von sogenannten "Eclipse-Projekten" bzw. OSGi-Bundles realisiert, welche entsprechende Beschreibungen besitzen. Nutzt man Apache Maven zum Bauen der Software, handelt es sich um Maven-Projekte, die mittels eines sogenannten Project-Object-Model (pom) beschrieben werden. In anderen Umgebungen gibt es entsprechende Komponenten-Beschreibungssprachen.

Im Idealfall besteht die Erstellung eines konkreten Produktes aus der Wiederverwendung und Konfiguration existierender Komponenten. In der Realität müssen diese oftmals mittels zusätzlichem Code angepaßt werden, beispielsweise um Schnittstellen-Inkompatibilitäten zu beseitigen.

Modellgetriebene Software-Entwicklung und domänenspezifische Sprachen (domain specific language, DSL)

Universelle Programmiersprachen wie Java und C# lassen sich für die Beschreibung und Lösung spezialisierter Probleme nutzen. Allerdings erfordern sie einen sehr hohen Einarbeitungsaufwand und besitzen zudem keine an die jeweilige Domäne angepaßten Konstrukte (diese lassen sich bedingt über entsprechende Programmierschnittstellen realisieren) und Visualisierungen. Um einem Domänen-Experten die Möglichkeit zu geben, das jeweilige Problem in der für ihn passenden Repräsentation (z.B. graphische oder textuelle Syntax) zu beschreiben/lösen, werden domänenspezifischen Sprachen (DSL) eingesetzt.

Zur Beschreibung einer (textuellen) DSL ist die Erstellung einer Grammatik notwendig (M2 in der Abbildung unten). Diese enthält die Regeln, mit denen sich gültige Sätze (M1) der Sprache bilden lassen. Zur Beschreibung der Grammatik kommt eine Meta-Grammatik (M3) zum Einsatz, welche die Definition beliebiger Grammatiken erlaubt.

Die modellgetriebene Software-Entwicklung steht in engem Zusammenhang mit den DSLs. Während eine Grammatik die konkrete (textuelle) Syntax einer Sprache beschreibt, beschreibt das Meta-Modell die abstrakte Syntax, d.h. die Konstrukte der zu modellierenden Domäne unabhängig von deren Repräsentation. Instanzen der Meta-Modelle werden als Modelle bezeichnet und sind äquivalent zu gültigen Sätzen einer Grammatik. Um beliebige Meta-Modelle beschreiben zu können werden Meta-Meta-Modelle eingesetzt. Ein Beispiel eines Meta-Meta-Modells ist die Modellierungssprache Ecore, die im Rahmen des Eclipse Modeling Framework (EMF) zum Einsatz kommt.

mm

Zusammenhang zwischen modellgetriebener Software-Entwicklung und DSLs 

Das Framework und der CDF-Editor

Die Grundidee des Component-Description-Framework (CDF) war es, ein mächtiges Werkzeug für die komponenten-basierte Software-Entwicklung bereitzustellen, dass die Vorteile der modellgetriebenen SW-Entwicklung und den DSLs ausnutzt. Dabei sollten die Generatoren des FXL-Frameworks mit einer möglichst einfachen Nutzbarkeit integriert werden.

Es existieren wie bereits oben erläutert eine Vielzahl von Komponenten-Beschreibungssprachen. Keine davon kann allen möglichen Anforderungen aller Software-Projekte gerecht werden. Nutzt man unterschiedliche Komponenten-Beschreibungssprachen, so ergeben sich daraus einige Nachteile:

  • Die Auswahl einer Sprache forciert andere Entscheidungen (OSGi -> Java als Programmiersprache)
  • Da unterschiedliche Meta-Meta-Modelle als Grundlage der Sprachen dienen, sind
    • Referenzen zwischen den Instanzen/Modelle schwierig zu realisieren.
    • Abbildungen von unterschiedlichen Sprachen aufeinander (bzw. Teilen davon; sogenannte Modell-Transformationen) schwierig zu realisieren.
  • Die Sprachen selbst sind sehr statisch und schlecht an die Bedürfnisse einzelner Software-Projekte anpassbar.

Aus diesem Grund stellt das CDF eine minimale Komponenten-Beschreibungssprache bereit (im Wesentlichen bestehend aus einer Komponenten-Id und einer Komponenten-Version). Die Sprache selbst läßt sich über modellgetriebene Ansätze mittels Ecore beliebig erweitern.

Im Laufe der Entwicklung wurden verschiedene Varianten des CDF-Editors erstellt. Eine davon ist integriert in die Eclipse-Entwicklungsumgebung und eignet sich aus diesem Grund hervorragend zur Erstellung von Software-Entwicklungswerkzeugen, beispielsweise indem Code-Generatoren bereitgestellt werden, die aus den domänenspezifischen Informationen (in den Modellen) Code in universalsprachen (Java etc) erzeugen.

Eine weitere Variante (Standalone) funktioniert ohne die Entwicklungsumgebung und besitzt ein anpassbares Aussehen. Damit eigent sie sich für die Erstellung von Endbenutzer-Software bzw. Software für Nicht-Entwickler, beispielsweise als Grundlage für Verwaltungssoftware für Autohäuser, Hotels etc. Dabei entspricht eine Komponente einem bestimmten Programmmodul, z.B. einer Kundenverwaltung.

Umsetzung

Das CDF bzw. der CDF-Editor sind selbst auf Grundlage der modellgetriebenen Ansätze und der FXL-Code-Generatoren erstellt. Dazu wurde die minimale Komponenten-Beschreibungssprache mittels Ecore modelliert (componentdescription.ecore, vgl. Abbildung unten). Daraus wurden die CDF Programmierschnittstelle (API) zum Erstellen und Manipulieren von Komponenten-Beschreibungen sowie ein passender Editor generiert. Der Editor wurde durch Bereitstellen von Bildern und internationalisierten Texten angepaßt. Ein sogenannter Component Container dient als Abstraktionsschicht zum Laden/Speichern von Resourcen unterschiedlicher Quellen sowie zum Java-Klassen-Laden (classloading). Außerdem ist er zuständig für die Auflösung von Inter-Modell-Referenzen zwischen verschiedenen Komponenten.

cdf

Die Architektur des CDF-Editors

Der Kern des CDF-Editor ist für folgende erweiterte Funktionalitäten zuständig, die er für alle Erweiterungen der Komponenten-Beschreibungssprache bereitstellt:

  • das Handling von Validatoren/Markern (z.B. Unterstützung von Validierungen der Modelle zur Bearbeitungszeit),
  • das Handling von Bildern inkl. Overlays, beispielsweise in den Bäumen,
  • die Bereitstellung von Schnittstellen zur Anpassung der erstellten Editoren (angepasste Persistierung, Darstellung, Event-Handling etc),
  • ein einheitliches Hilfesystem (aufbauend auf dem Eclipse-Hilfe-System sowie kontext-sensitiv im Baum) und
  • ein einheitliches System für die Anzeige von Release-Notes der einzelnen Erweiterungen.

Erstellen von Erweiterungen/Bearbeiten von Ecore-Meta-Modellen

Wie bereits oben erläutert kann die abstrakte Syntax der Komponenten-Beschreibungssprache mittels Ecore-Meta-Modellen beliebig erweitert werden. Ecore ist dabei so mächtig, dass es sich selbst beschreiben kann (das Meta-Modell ecore.ecore beschreibt die Ecore-Modellierungssprache). Diese Tatsache wurde ausgenutzt, um aus diesem Meta-Modell die Ecore-Programmierschnittstelle sowie den passenden Editor zu generieren, welcher dann mittels Bildern und Internationalisierung angepaßt wurde. Der Ecore-Container ist zuständig für das Laden und Speichern der Ecore-Meta-Modelle sowie für die Auflösung von Referenzen zwischen verschiedenen Meta-Modellen (Inter-Meta-Modell-Referenzen).

Erweitern der Komponenten-Beschreibungssprache

Der so entstandene Ecore-Editor wurde in den Komponenten-Editor integriert und ermöglicht die Beschreibung beliebiger Erweiterungen der Komponenten-Beschreibungssprache (*.ecore). Daraus lassen sich nun mit Hilfe der FXL Generatoren die Programmierschnittstellen und Editoren der Erweiterungen generieren, welche mittel Bildern und internationalisierten Texten anpassen lassen und in den Komponenten-Editor integriert werden.

Weiterführende Informationen

Die Dokumentation der Komponenten-Beschreibungssprache befindet sich hier.

Eine detailliertere Beschreibung der Konzepte, Realisierung und Evaluierung des CDF sowie des CDF-Editors ist in den Kapiteln 4.2, 5.3 und 6.2 meiner Dissertationsschrift (siehe Publikationen) zu finden.

Die Präsentation How to develop an editor for the Eclipse RCP (siehe Präsentationen) zeigt anhand eines Beispiels noch einmal den Zusammenhang zwischen der modellgetriebenen Software-Entwicklung und den domänenspezifischen Sprachen im Detail auf. Dabei wurde für eine Konfigurations-Sprache ein Editor erzeugt, der sowohl eine textuelle als auch eine baumbasierte Repräsentation der Sprache beinhaltet. Folie 6 geht dabei auf die notwendigen Transformationen bzw. Synchronisationsmechanismen ein.