Entwicklung

Mit Eclipse zum Modellaustausch

23.05.2011 von Karsten Thoms
Wer die im Entwicklungsprojekt entstehenden Modelle austauschen will, sollte über Eclipse eine Werkzeugkette integrieren.

Mit Modellen wird das Grundprinzip der Abstraktion in der Softwareentwicklung verfolgt. Modelle stellen Abbildungen der wirklichen Software auf einem höheren Abstraktionsniveau dar. Dabei spielt es zunächst keine Rolle, ob Modelle formal oder informal sind, grafische oder textuelle Notationen besitzen, oder in einer standardisierten oder propietären Modellierungssprache beschrieben sind. Für die jeweils verwendete Modellierungssprache kommen spezifische, teilweise eigens zu erstellende Werkzeuge zum Einsatz.

Eine wichtige Forderung in der modellgetriebenen Softwareentwicklung ist auch, dass Modelle automatisiert verarbeitet werden können und die Spezifikation der Software stets beim Modell beginnt (Forward Engineering). Die Modelle müssen dazu formal sein und festgelegten Modellierungsregeln folgen. In diesem Entwicklungsansatz ist es zwangsläufig erforderlich, dass Modelle zu jedem Zeitpunkt die Realität widerspiegeln. Ein Umstand, der für die herkömmliche Softwareentwicklung zwar äußerst wünschenswert ist, in der Praxis jedoch selten angetroffen wird. Dennoch gilt: Die modellgetriebene Softwareentwicklung verspricht der nächste Evolutionsschritt von der Manufaktur hin zur industriellen Softwarefertigung zu werden.

COMPUTERWOCHE Marktstudien

COMPUTERWOCHE Marktstudien

Agile Softwareentwicklung 2011 (149,90 €)

In wieweit sind agile Methoden in den IT-Abteilungen angekommen? Welche Erfahrungen haben Unternehmen mit agiler Softwareentwicklung gesammelt und wo lagen die größten Hürden bei der Einführung?

Jetzt bestellen!

Modellierungssprachen

Zur Modellierung der vielfältigen Aspekte in einem Softwareprojekt werden unterschiedliche Modellierungssprachen eingesetzt. Am weitesten verbreitet ist hier die Unified Modeling Language (UML). Durch Profile lässt sie sich auf spezifische Anwendungsbereiche erweitern. So wurde beispielsweise mit SysML von der OMG und dem International Council on Systems Engineering eine Erweiterung für den Systementwurf standardisiert. Die UML besitzt eine grafische konkrete Syntax und ist für zahlreiche Problemstellungen der Softwaremodellierung einsetzbar. Sie ist eine visuelle, universell verwendbare Modellierungssprache (General Purpose Language - GPL).

Das Eclipse-Plug-in TextUML bietet einen einfachen Editor für Modellinformationen.

Doch Modellierungssprachen müssen nicht unbedingt eine visuelle konkrete Syntax besitzen. Es gibt auch eine Vielzahl textueller Modellierungssprachen. Sie zeichnen sich oft dadurch aus, dass sie einen stärkeren Bezug zum Problemkontext besitzen. Stark im Trend liegen derzeit textuelle domänenspezifische Sprachen (Domain Specific Language - DSL). Diese erlauben die Erstellung von Modellen in textuellen Notationen, die stark auf die Problemdomäne ausgerichtet sind.

Das Eclipse Modeling Project bietet zahlreiche Möglichkeiten zur Entwicklung von Werkzeugen für textuelle und visuelle DSLs. Mit dem Eclipse Modeling Framework (EMF) hat sich ein De-Facto Standard gebildet, auf dessen Basis immer mehr Modellierungswerkzeuge entwickelt werden. Treibend sind hier vor allem IBM und Borland, deren Entwicklungswerkzeuge Rational Software Architect und Together auf EMF aufsetzen. Auch Microsoft hat den Bedarf nach DSL Werkzeugen längst erkannt. In Visual Studio 2008 wurden erstmals die Domain-Specific Language Tools integriert. Mit dem Projekt Oslo geht Microsoft heute einen deutlichen Schritt weiter.

Domänenspezifische Sprachen

Domänenspezifische Sprachen (Domain Specific Language - DSL) sind formale Sprachen, die für ein spezielles Problemfeld (Domäne) optimiert sind. Die Sprachelemente und Struktur einer DSL entspricht dem natürlichen Verständnis von Domänenexperten zur Beschreibung von Problemlösungen.

Klassifizierung domänenspezifischer Sprachen:

  • Interne (eingebettete) DSL: Die Definition der DSL erfolgt in einer allgemeinen Sprache (Host-Sprache). Beispiele für interne DSLs sind UML2 Profile und XML Schema.

  • Externe DSL: Die DSL ist eine eigenständige Sprache. Dies erfordert meist die Entwicklung spezifischer Werkzeuge (Parser, Editoren etc.) für diese Sprache. Beispiele für externe DSLs sind SQL, reguläre Ausdrücke, WebML (www.webml.org), ereignisgesteuerte Prozessketten (EPK) und die BPML.

Interoperabilität von Modellen

Zum Austausch von Modellinformationen hat sich der XMI-Standard (XML Metadata Interchange) durchgesetzt. Dennoch ist es nicht so, dass mit XMI Interoperabilitätsprobleme für den Modellaustausch der Vergangenheit angehören. XMI legt lediglich fest, wie Metadaten in XML-Dokumenten ausgetauscht werden können, aber nicht, welche. Der Austausch von Modellinformationen ist selbst zwischen verschiedenen UML-Werkzeugen, welche die gleiche UML-Version und die gleiche XMI-Version verwenden, oft nicht gewährleistet. Noch problematischer gestaltet sich der Austausch von Diagramminformationen, die bei visuellen Modellierungssprachen eine wichtige Rolle spielen. Mit UML Diagram Interchange gibt es hierfür zwar einen OMG-Standard, dieser wird jedoch nur von wenigen UML-Werkzeugen unterstützt.

Eines der bekanntesten Werkzeuge, um eigene domänenspezifische beziehungsweise problemorientierte Sprachen zu definieren, ist Xtext von Eclipse.

Die meisten Hersteller von Modellierungswerkzeugen setzen heute auf das Eclipse Modeling Framework (EMF), wodurch eine gemeinsame Implementierungsbasis entstanden ist. Im Eclipse-Projekt Model Development Tools (MDT) wird der UML-Standard auf Basis von EMF implementiert. Alle führenden UML2-Werkzeuge sind mit diesem Format kompatibel und haben Interoperabilität zumindest auf der Ebene der Modellinformationen, nicht aber bei den Diagramminformationen erreicht.

Bei Modellen, die in textuellen Sprachen vorliegen, ist Austauschbarkeit inhärent gegeben, da die Modelle direkt als Text vorliegen. Hier liegen die Herausforderungen eher bei der Integration mit andersartigen Modellen und der Werkzeugintegration. Das Xtext-Projekt, das Teil des Eclipse-Release Galileo ist, bietet dazu Unterstützung an.

Automatisierte Softwareproduktion

Die modellgetriebene Softwareentwicklung propagiert die Verwendung von Modellen zur automatisierten Produktion von Software. Damit dies möglich ist, müssen verschiedenartige Modelle in den Fertigungsprozess einfließen und miteinander integriert werden. Dies gelingt vor allem dann, wenn den Modellen eine gemeinsame Basis zugrunde liegt, für die es die notwendigen Werkzeuge unter anderem zur Transformation, Validierung und Persistierung gibt. Auch hier bietet das Eclipse Modeling Framework die derzeit breiteste Unterstützung. Zahlreiche Open-Source-Werkzeuge, insbesondere aus dem Eclipse Modeling Project, und kommerzielle Werkzeuge lassen sich auf dieser Basis integrieren.

Die Integration selbst muss allerdings weitgehend projektspezifisch gelöst werden. Es lassen sich auch durchaus Modelle in einer Werkzeugkette integrieren, die nicht auf EMF basieren. Voraussetzung ist ein hinreichend offenes Modellaustauschformat, wie es zum Beispiel XMI bietet. Der Integrationsaufwand ist hier meist höher.

Das Eclipse-Plug-in OpenArchitectureWare bietet einen ausgereiften Open-Source-Generator für die modellgetriebene Softwareentwicklung.

Die Adaption von Modellen innerhalb einer Werkzeugkette erfolgt durch Modell-zu-Modell-Transformationen (M2M). Realisiert werden diese meist durch Open-Source-Werkzeuge, wobei standardbasierende Lösungen wie QVT ebenso wie propietäre Lösungen (zum Beispiel openArchitectureWare Xtend) zum Einsatz kommen.

Die Produktion der Software erfolgt letztendlich durch Modell-zu-Text-Transformationen, allgemein auch als Code-Generierung bekannt. Zum Teil können Modelle auch durch Interpreter zur Laufzeit direkt verarbeitet werden. Die vollständige Erzeugung von Software aus Modellen erweist sich in der Regel als nicht zweckmäßig, wird in manchen Anwendungsgebieten aber auch angetroffen, unter anderem im Automotive-Bereich oder bei der Entwicklung von eingebetteten Systemen.

Diversität erfordert spezifische Werkzeugketten

Software wird für die unterschiedlichsten Plattformen entwickelt. Die Vielzahl der möglichen Zielsprachen, Softwarearchitekturen und Entwicklungsprozesse machen es unmöglich, allen Anforderungen durch eine einheitliche Modellierungssprache oder eine einzige Werkzeugkette gerecht zu werden. Abhängig vom spezifischen Kontext müssen andere Glieder zusammengefügt werden. Je enger dieser Kontext gefasst wird, desto größer ist das Potential, eine passende Werkzeugkette erstellen zu können. So entwickelt die Robert Bosch GmbH an einer durchgängigen Modellierungs- und Entwicklungsumgebung auf Basis von Eclipse, die für die Entwicklung von Software für elektronische Steuerungseinheiten in Automobilen eingesetzt wird. Als Modellierungssprache kommt hier nicht die UML zur Anwendung, sondern man setzt auf die Industriestandards MSR und Autosar. Die Entwicklung einer hoch spezialisierten Werkzeugkette kann mit großen Entwicklungsaufwänden verbunden sein. Doch je nach Projekt und Anforderungen an die Werkzeugkette kann sich die Investition auch schon für einzelne Projekte rechnen. Gerade im Bereich der Implementierung erzielt man durch die mittlerweile ausgereiften Basiswerkzeuge und aufgrund des hohen Automatisierungspotentials gute Ergebnisse.

Auswirkungen auf den Entwicklungsprozess

Einordnung der Modellierungssprachen

Die Verwendung von Modellen zur automatisierten Softwareproduktion erfordert ein Umdenken. Insbesondere die Notwendigkeit zur Formalisierung von Modellen ist Projektbeteiligten meist neu. Modelle sind mit Code gleichzusetzen, und sind in jeder Hinsicht gleich zu behandeln. Durch die modellgetriebene Entwicklung können mehr Projektbeteiligte direkt in den Umsetzungsprozess einbezogen werden, da ihre Spezifikationen direkten Einfluss auf die erstellte Software haben. Die unterschiedlichen Denkweisen von Fachspezialisten, Architekten, Entwicklern und Testern erfordern unterschiedliche Modellierungsarten, die miteinander integriert werden müssen.

Bei der Einführung kann sowohl ein Top-down- als auch ein Bottom-up-Ansatz gewählt werden. In der Praxis findet man heute meist den Bottom-up-Ansatz, bei dem der Einsatz von Modellen dort erfolgt, wo das Potential für Abstraktion und Automatisierung am höchsten ist und sukzessive auf weitere Bereiche ausgedehnt werden kann. Dieser Ansatz wird meist von den Entwicklungsteams getrieben. (ue)