Entwicklung hochwertiger grafischer Modelleditoren

Das Modeling-Framework Eclipse Graphiti

Christian Brand, Matthias Gorning, Tim Kaiser, Jürgen Pasch und Michael Wenz

Graphiti unterstützt das leichte und schnelle Erstellen homogener grafischer Editoren, die ein unterliegendes Domänenmodell mittels einer werkzeugdefinierten grafischen Notation anzeigen und editierbar machen. Im nachfolgenden Artikel ordnen wir Graphiti zunächst in das Eclipse-Modeling-Umfeld ein und grenzen das Framework gegen GMF und GEF ab. Es folgt eine Übersicht der Architektur und eine Einführung in die grundlegenden Konzepte von Graphiti. Das Framework wird im Hauptteil des Artikels durch ein einfaches Beispiel fassbar. Wir entwickeln einen grafischen Editor, der sich an das Tutorial des Example Features von Graphiti anlehnt. Schon nach wenigen Schritten hat man erste vorzeigbare Erfolge. Das macht hoffentlich Laune, tiefer in das Framework einzusteigen.

Versucht man mit Eclipse einen grafischen Editor für ein Domänenmodell zu erstellen, so kommt man nur schwer am Eclipse Modeling Framework (EMF) und am Graphical Editing Framework (GEF) vorbei. Während EMF die Basis zur Modellierung bereitstellt, hilft GEF bei der Programmierung von grafischen Editoren. Schnell stellt man jedoch fest, dass GEF sehr komplex ist und es viel Arbeit erfordert, sich in das Framework hineinzudenken. Deswegen und auch zur Vereinheitlichung von Tools entstand bei der SAP AG ein Framework, das durch ein einfaches Programmiermodell basierend auf Features die Komplexität von GEF vor dem Nutzer verbirgt, eine Brücke zwischen EMF und GEF baut und damit das Entwickeln von Editoren stark erleichtert und beschleunigt. Nachdem die SAP AG 2009 beschlossen hatte, das Framework in die Eclipse-Community einfließen zu lassen, konnte das Entwicklungsteam im Oktober 2010 das 0.7.0 Incubation Release der Graphical Tooling Infrastructure (Graphiti) ausliefern. Erwähnenswert ist sicherlich, dass bereits der SAP-interne Vorgänger von Graphiti produktiv im Einsatz ist [2], [3]. Installieren kann man sich das Framework über die Webseite des Projekts [1]. Graphiti bietet die folgenden Vorteile bei der Entwicklung und im Einsatz:

  • Schnelle Einarbeitung: plattformspezifische Technologien wie GEF/Draw2D werden gekapselt
  • Inkrementelle Entwicklung: schnelle Erfolge durch Standardimplementierungen, kurzer Entwicklungszyklus (Programmierung, Fehlersuche)
  • Homogene Editoren: Editoren auf Graphiti-Basis sehen ähnlich aus und verhalten sich ähnlich; die Benutzer-interaktionen wurden mit Ergonomie-Experten abgestimmt
  • Optionale Unterstützung verschiedener Plattformen: Diagramme werden plattformunabhängig definiert, können also prinzipiell auf jeder beliebigen Plattform dargestellt werden

Eine Alternative bei Eclipse existiert bereits: das Graphical Modeling Framework (GMF). Grundlegende Unterschiede zwischen den Paradigmen von Graphiti und GMF sind in Tabelle 1 dargestellt.

Tabelle 1: Graphiti vs. GMF

Graphiti GMF
Architektur Laufzeitorientiert Generativ
Schnittstelle Abgeschlossen Bezug zu GEF
Klientenlogik Zentralisiert (Featurekonzept) Funktionalität ist verteilt
Aussehen und Verhalten Im Standard definiert von Ergonomieexperten bei SAP (anpassbar) Einfach (anpassbar im Generat)

Der wichtigste Unterschied im Aufbau der Frameworks ist, dass man mit GMF generativ arbeitet, also der grafische Editor aus Modellen generiert wird, während man mit Graphiti schlicht und einfach gegen eine Java-Schnittstelle programmiert. Der Ansatz von Graphiti hat den nicht zu unterschätzenden Vorteil, dass kein generierter Quelltext verändert werden muss, um den Editor anzupassen – im Gegensatz zu GMF: hier muss man im Generat Änderungen vornehmen, was bei erneuter Generierung komplexe Probleme verursachen kann.

Architektur und grundlegende Konzepte

Die Kommunikation zwischen Benutzer und einem Graphiti-basierten Tool erfolgt selbstverständlich über Bildschirm (Screen), Maus und Tastatur (Abb. 1). Dabei werden Interaktionsanfragen wie beispielsweise Resize, Drag-and-Drop oder auch Delete von einer Interaction Component entgegengenommen. Die eigentliche Verarbeitung der entgegengenommenen Anfragen geschieht im so genannten Diagram Type Agent, auf den im nachfolgenden Abschnitt näher eingegangen wird.

Abb. 1: Grundlegende Architektur

Die Kommunikation zwischen Benutzer und einem Graphiti-basierten Tool erfolgt selbstverständlich über Bildschirm (Screen), Maus und Tastatur (Abb. 1). Dabei werden Interaktionsanfragen wie beispielsweise Resize, Drag-and-Drop oder auch Delete von einer Interaction Component entgegengenommen. Die eigentliche Verarbeitung der entgegengenommenen Anfragen geschieht im so genannten Diagram Type Agent, auf den im nachfolgenden Abschnitt näher eingegangen wird.

Aufgabe der Rendering Engine ist es, die jeweils aktuellen Diagrammdaten auf dem Bildschirm darzustellen. Rendering Engine und Interaction Component bilden gemeinsam die Frameworkkomponenten von Graphiti – und damit die eigentliche Graphiti-Laufzeit. Die technische Realisierung der Graphiti-Laufzeit basiert auf dem Graphical Editing Framework (GEF) in Verbindung mit Draw2d. Durch die zum Teil festen Vorgaben von Graphiti kann eine einheitliche Oberfläche (Aussehen und Verhalten) aller Graphiti-basierten Tools sichergestellt werden.

Diagram Type Agent

Wie bereits oben erwähnt, wird der Diagram Type Agent über die Interaction Component angesprochen. Das geschieht über eine genormte Schnittstelle. Der Diagram Type Agent muss durch den Entwickler bereitgestellt werden. Dem Entwickler stehen für die Implementierung diverse Services, aber auch viele sinnvolle Standardimplementierungen zur Verfügung. Mithilfe der Services und Standardimplementierungen kann ein Entwickler sehr schnell einen eigenen grafischen Editor erstellen. Aktionen wie z. B. Move, Resize, Delete, Remove und Print stehen sofort zur Verfügung. Diese erste Version sollte man dann aber nicht als Prototyp betrachten, den man wegwerfen muss. Vielmehr kann er mit wachsendem Graphiti-Know-how und steigenden Ansprüchen nach und nach zu einem vollwertigen Produkt erweitert werden. Anders ausgedrückt: Der Entwickler kommt erst einmal sehr schnell zu einem funktionierenden Editor. Nach und nach wird sie dann verschönert (z. B. Farbverläufe) und mit zusätzlicher Funktionalität ausgestattet (z. B. Direct Editing, Erweiterung der Kontextmenüs und Kontextbuttons). Hauptaufgabe des Diagram Type Agents ist die Pflege der verschiedenen Modelldaten. Da gibt es auf der einen Seite das Pictogram Model (inkl. Link Model), dessen Metamodell durch Graphiti bereitgestellt wird, und auf der anderen Seite das domänenspezifische Modell, das der Entwickler mitbringt. Diese Modelle werden im Folgenden erklärt.

Geschrieben von
Christian Brand, Matthias Gorning, Tim Kaiser, Jürgen Pasch und Michael Wenz
Kommentare

Schreibe einen Kommentar

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