Interview mit Olivier Constant

Eclipse Kepler Highlights: EMF Diff/Merge

Diana Kupfer

EMF Diff/Merge (EDM), ein Projekt speziell für das Zusammenführen von Modellen, gehört zu den Neulingen im diesjährigen Eclipse-Release-Train. Es ist ein Unterprojekt des Eclipse-Modeling-Projekts und spielt außerdem eine wichtige Rolle in der PolarSys Industry Working Group, die mit der „PolarSys IDE 1.0“ ein erstes eigenes Release im Oktober plant. Auf der EclipseCon North America gewann EDM in diesem Jahr den Preis „Innovativstes Projekt oder Feature“.

Eclipse Kepler im Fokus
Das Eclipse Magazin 5.13 widmet sich in seinem Schwerpunktthema detailliert dem Eclipse Kepler Release Train. Neben einem ausführlichen Rückblick auf das Eclipse-Kepler-Jahr finden Sie Beiträge zu den Neuerungen in der 4.3-Plattform, den Java Development Tools, in RAP 2.1 und der Orion IDE. Zudem stellen wir das neue Projekt Stardust vor und präsentieren spannende Erfahrungsberichte über die Umstellung von Eclipse 3.x auf 4.
Eclipse Magazin 5.13 ab 26.7. am Kiosk!

JAXenter: Wenn man „Diff/Merge“ hört, denkt man wahrscheinlich als Erstes an Versionskontrolle. Aber es gibt sicher viele andere interessante Anwendungsfälle für das Tool – welche zum Beispiel?

Olivier Constant: Eine Diff/Merge-Operation ist immer dann nötig, wenn unterschiedliche Varianten eines Modells, oder Teile davon, zu einem einzigen Modell zusammengeführt werden sollen. Neben Versionskontrolle und Teamarbeit an Modellen ergeben sich im modellbasierten Systemdesign noch viele andere Anwendungsfälle. Einer davon hängt mit der Entstehung und Wartung großer Modelle zusammen. Man braucht Toolunterstützung, um halbautomatisch Modeling-Aufgaben auszuführen, die ansonsten redundant und zeitaufwändig wären. Deshalb ist es grundlegend wichtig, Teilmodelle – auch ein und desselben Modells – zusammenführen zu können. Ein weiterer, sicherlich bekannterer Anwendungsfall ist inkrementelle Modelltransformation. Man denke zum Beispiel an einen Arbeitsablauf, in dem ein Systemdesignmodell in ein Modell im Bereich Sondermaschinenbau exportiert, um von entsprechenden Ingenieuren vervollständigt und begutachtet zu werden. Immer dann, wenn sich das Designmodell weiterentwickelt, muss das Sondermodell entsprechend aktualisiert werden. Dabei müssen stellenweise Veränderungen bewahrt werden, was einen „Merge“ nahelegt.

JAXenter: Worin bestehen die größten Herausforderungen beim Zusammenführen von Modellen im Vergleich zu Code?

Constant: Egal, wie fehlerhaft man Code zusammenführt, man kann ihn im Anschluss immer in beliebigen Editoren öffnen. Bei Modellen ist das anders. Code stellt man sich einfach als Zeichenfolge vor. Modelle hingegen sind komplexe Datenstrukturen, also Graphen aus Modellelementen, die Daten enthalten und bestimmte Konsistenzkriterien erfüllen müssen. Diese Kriterien sind von Modell zu Modell unterschiedlich. Sie werden vom Metamodell und manchmal von zusätzlichen Konsistenzregeln definiert. Manche Kriterien werden von Modellinfrastrukturen automatisch umgesetzt, aber nicht alle. Wenn ein Modell ein Kriterium verletzt, kann es sein, dass das übliche Modeling-Werkzeug es als fehlerhaft einstuft und nicht öffnen kann. Beim Zusammenführen von Modellen ist Konsistenz also essenziell.

JAXenter: Gibt es nicht bereits andere Projekte, die sich der Zusammenführung von Modellen verschrieben haben, z. B. EMF Compare?

Constant: EMF Compare ist eine integrierte Lösung, während es sich bei EDM um eine Komponente zum Bau von Werkzeugen handelt. Bei EDM ist das Merging eine primitive Operation auf dem Gebiet der Modellbearbeitung, -transformation und -entwicklung. Deswegen ist EDM nicht an die Art und Weise gebunden, wie Modelle persistiert und strukturiert werden – mit EMF-Ressourcen oder Containment Trees. EDM arbeitet mit „Model Scopes“. Das sind beliebig definierbare Gruppen von Modellelementen. Was es für ein Modellelement bedeutet, zu einem Scope hinzugefügt oder daraus entfernt zu werden, hängt vom jeweiligen Anwendungsfall ab. Wir arbeiten z. B. an einer Infrastruktur, die Modeling Patterns unterstützt. In diesem Kontext sind Model Scopes Teile von Modellen, die von spezifischen Filtern definiert werden.

JAXenter: Die Diff/Merge Engine wurde bei Thales entwickelt. Wie entstand die Idee dazu?

Constant: Bei einer großen Firmengruppe wie Thales gibt es ein breites Spektrum an modellbasierten Prozessen und ähnlichen Szenarien. Mit der Zeit wurde klar, dass das Zusammenführen von Modellen, egal in welchem Kontext oder zu welchem Zweck, ein wiederkehrendes Erfordernis ist und dass starke Garantien, was die Erhaltung von Konsistenz und Flexibilität betrifft, notwendig sind. Was die Weiterentwicklung und das Open Sourcing – abgesehen vom Prototyping – ermöglicht hat, war das französische Kollaborationsprojekt AgeSys. Darin erproben wir u. a. Teamwork mit Modellen.

JAXenter: In welchen Industrieprojekten wird EDM bislang verwendet?

Constant: EDM ist mittlerweile in die interne Thales Toolsuite für modellbasiertes Design eingebettet. Es ist ins Frontend-Tool für Versionskontrolle integriert, außerdem als Backend Engine für eine Reihe weiterer Tools und Features, denen es einen richtigen Entwicklungsschub gegeben hat. Die Toolsuite wird in einer Vielzahl von Betriebsprojekten innerhalb der Wirkungsbereiche von Thales verwendet: Luft- und Raumfahrt, Transport, Verteidigung und Sicherheit. Nach den Systemdesignteams zu urteilen, mit denen wir uns austauschen, wird EDM vorwiegend in der Aeronautik verwendet. Aber wie bei jedem anderen Eclipse-Open-Source-Projekt kann es sein, dass wir vom Einsatz von EDM in anderen Bereichen einfach nichts wissen.

JAXenter: Offensichtlich ist EDM für kollaborative Modeling-Umgebungen eine hervorragende Wahl. Aber wie groß darf eine solche Umgebung sein, gibt es eine Obergrenze?

Constant: Das ist eine fundamentale Frage, die alle Modeling-Technologien betrifft. Wir sehen immer mehr Projekte, die große Modelle verwenden. Diese können aus speichertechnischen Gründen nicht bearbeitet werden, ohne von 32-Bit auf 64-Bit-Windows-Betriebssystem zu wechseln. Was das Mergen angeht: Wie auch immer Modelle persistiert werden – ob in Dateien oder auf Datenbanken –, EDM kann sich die Model Scopes zunutze machen, indem es Teile von Modellen bearbeitet, die entweder möglichst klein und auf einen bestimmten Anwendungsfall zugeschnitten sind oder so groß, wie es der verfügbare Speicher erlaubt.

JAXenter: Bisher ist der Abstraktionsgrad von EDM ein geringer, strikt technischer. Habt ihr vor, das Projekt auf ein höheres Niveau zu heben oder setzt ihr mehr auf Interoperabilität mit Vergleichsframeworks, die sich bereits auf einem höheren Level ansiedeln?

Constant: Unterschiede zwischen Modellen können auf mehreren Abstraktionsniveaus dargestellt werden. Auf einem niedrigen, rein technischen Niveau hat man es einfach mit einem winzigen Stück Information zu tun, das im einen Modell vorhanden ist, im anderen nicht. Auf einem hohen Niveau entspricht eine Abweichung vielleicht einer Bearbeitungsaktion eines Nutzers, die über eine Werkzeugpalette in einem Diagramm ausgeführt wurde. Auf einer tieferen Ebene würde so etwas mehreren Abweichungen entsprechen. Die EDM Engine operiert auf niedriger Ebene. Daraus ergibt sich ein einfaches Framework für das Mergen, was sich positiv auf Integrität und Konsistenz auswirkt. Anders ist es in einem Fall, in dem ein User die Abweichungen begreifen muss und zu entscheiden hat, welche er zusammenführt. Hier ist es besser, die Unterschiede auf höherer Ebene anzuzeigen.

In EDM werden diese beiden Anforderungen verschiedenen Komponenten zugeordnet: Die Engine ist für die Integrität zuständig, das Standard-GUI dafür, die Abstraktion zu erhöhen.

Diese beiden Möglichkeiten – einerseits die Verbesserung der GUI, andererseits Brücken zu anderen Frameworks, die auf einem höheren Abstraktionsniveau operieren – schließen sich nicht gegenseitig aus. Wir werden möglicherweise beides ausloten.

JAXenter: Apropos Brücken: Was sind momentan die stärksten oder wichtigsten Verbindungen zu anderen Modeling-Projekten bei Eclipse?

Constant: Der wesentliche Teil von EDM steht in direkter Abhängigkeit zu EMF, der Modeling-Kerntechnologie bei Eclipse. Das Standard-GUI von EDM lässt sich in das Compare-Framework von Eclipse integrieren. Außerdem werden Standard-Model-Scopes für die Visualisierungstechnologie GMF bereitgestellt. Und wir arbeiten gerade an einer Integration in bzw. Unterstützung für UML, SysML, CDO und das neue Sirius-Projekt.

JAXenter: Was ist abgesehen davon noch geplant?

Constant: Wir wollen das Tool flexibler machen. Das UI wird erweitert, um die Definition der Model Scopes zu vereinfachen. Der Mechanismus zum Vergleich von Modellelementen beruht auf dem allgemeinen Konzept eines Identifiers, der auf EMF-Identifier gemappt werden kann, qualifizierte Namen oder beliebige andere Elemente. Mithilfe dieses Mechanismus sollen alternative Matching-Algorithmen bereitgestellt werden. Langfristig werden wir weitere Ideen erproben: eine verbesserte Impact-Analyse beim Mergen, Reaktionen der Engine auf Änderungen am Modell oder eine bessere Verwendung des Delta-Konzepts.

Olivier Constant ist Ingenieur bei Thales Global Services und Projektleiter von EMF Diff/Merge. Er promovierte an der Université de Pau. Davor studierte er Maschinenbau an der Ecole des Mines de Nantes und erwarb einen M.Sc. an der Vrije Universiteit Brüssel.

Geschrieben von
Diana Kupfer
Diana Kupfer
Diana Kupfer war Redakteurin bei S&S Media für die Zeitschriften Java Magazin, Eclipse Magazin und das Portal JAXenter. 
Kommentare

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht.