# Eclipse Plugin Entwicklung: Editor für Flussdiagramme



## ChristianB (6. Jun 2011)

Hallo,

ich bräuchte ein wenig Hilfe und Tipps bei der Herangehensweise an ein Projekt.
Es geht darum einen Editor als eclipse-plugin (für eigene RCP) zu entwickeln, mit dem man Flussdiagramme erstellen kann und dann in einem bestimmten XML-Format abspeichern kann. 
Das Flussdiagramm kann dabei diverse spezielle Ablaufelemente enthalten. (das ganze geht sogar mehr in Richtung grafische Programmierung) 
Ein Beispiel, wie man sich das im Endeffekt vorstellen könnte (natürlich soll mein Editor erstmal 
viel einfacher gehalten sein, aber vom Prinzip her passts): 

Screenshot von einem ähnlichen Programm

Was suche ich also genau?

Ich suche einen Opensource-Editor, mit dem man per Drag and Drop Flussdiagramme grafisch zusammenstellen kann. Dieser Editor würde dann die Grundlage bilden und ich würde ihn um zusätzliche Ablaufelemente erweitern oder bestehende Ablaufelemente bearbeiten (z.B while- und for-Schleife). Ein Editor, der also leicht zu erweitern ist und schon die grundlegenden Funktionen (wie drag and drop von Ablaufelementen aus einer toolbox, grafische Darstellung der Elemente etc.), wäre sehr hilfreich, da ich nicht das Hauptaugenmerk auf die Programmierung des Editors an sich legen möchte.

Ich würde mich also freuen, wenn ihr Ideen zu den folgende Fragen habt:


Kennt ihr freie Editoren, die meinen Anforderungen entsprechen?
Ist es unter Umständen einfacher, den Editor von Grund auf selbst zu bauen? (z.B. mit GMF)
Wie würdet generell an das Projekt herangehen? 

Vielen Dank schon mal im Voraus und ich hoffe ich habe mein Anliegen klar formuliert, falls nicht einfach nachfragen 

Chris


----------



## Wildcard (6. Jun 2011)

*ins richtige Forum verschieb*
Eclipse bietet dir an dieser Stelle wirklich sehr viel. Ich würde das Modell in jedem Fall auf EMF basieren lassen.
Für die Visualisierung hast du mehrere Möglichkeiten:
1. Alles selbst machen mit Draw2D als Grafikbibliothek 
alle der nachfolgenden Möglichkeiten setzen übrigens auch auf Draw2D auf
2. Einen GEF Editor schreiben 
GEF ist ein mächtiges Framework für grafische Editoren, erfordert initial aber recht viel Code
3. Einen Zest basierten Editor bauen 
mit Zest kommt man schnell ans Ziel, es sieht schick aus, ist aber mehr für Viewer gedacht und etwas beschränkt in den Möglichkeiten
4. Einen GEF Editor mit GMF generieren lassen
Damit kommst du sehr schnell (wenn du mal kapiert hast wie man es bedient) zu einer initialen Version die auch recht viel kann aber bescheiden aussieht. Danach kommt das customizing für Optik und Bedienung. Man kann sehr viel damit machen, aber der Code ist nicht ganz trivial
5. Einen Graphiti Editor stellen
Graphiti ist ebenfalls ein Draw2D + GEF Aufsatz und das jüngste der Frameworks. Ich habe noch nicht allzuviel damit gemacht, aber mir gefällt die Optik und Benutzerführung sehr gut und die API ist wesentlich einfacher als GEF.

Mein Tipp wäre ein EMF Modell + einen Graphitieditor. Scheint mir derzeit der beste Kompromiss aus Optik, Bedienbarkeit, Anpassbarkeit und Aufwand.
Zest ist die einfachste Variante (bedient sich wie ein TreeViewer), aber eben beschränkt. Wenn Zest alles kann was du brauchst (und in Zukunft brauchen wirst), kannst du auch Zest verwenden.
Schau dir ruhig auch mal GMF an. Ich bin zwar kein großer Freund davon, aber man kann viel damit machen wenn man die Zeit investiert.
Abraten würde ich von Variante 1. und 2., reines Draw2D, oder GEF API direkt verwenden. Das ist mit viel Arbeit verbunden.

Graphical Modeling Framework
Graphiti Home
Zest


----------



## ChristianB (7. Jun 2011)

Vielen Dank für die super ausführliche Antwort!

Habe mir gestern GMF noch angeschaut und zumindest noch ganz gute Tutorials gefunden. Scheint wirklich ziemlich komplex sein, aber halt auch wirklich gute Features. Z.B. die Validierung des Diagramms mit Anzeigen der Fehler und farbliche Markierung davon klingt sehr gut. 

Kennst du EuGENia?
Das klang gerade für den Einsteig in GMF sehr gut, wenn man allerdings mehr Funktionalität will muss man .eol Scripts basteln, 
was nicht sehr gut klingt (EuGENia Customization)

Graphiti sieht auf den ersten Blick sehr interessant aus. Werde ich mich auf jeden Fall mal genauer informieren, ist halt die Frage, ob das Framework nicht noch zu jung ist. GMF wirkt halt schon sehr ausgereift.


----------



## Wildcard (7. Jun 2011)

> Habe mir gestern GMF noch angeschaut und zumindest noch ganz gute Tutorials gefunden. Scheint wirklich ziemlich komplex sein, aber halt auch wirklich gute Features. Z.B. die Validierung des Diagramms mit Anzeigen der Fehler und farbliche Markierung davon klingt sehr gut.


Sollte mit Graphiti auch kein Problem sein. EMF Modelle liefern die notwendige Validierungslogik sowieso schon mit.



> Kennst du EuGENia?


Ja, ich kenne Eugenia, auch wenn ich es noch nicht benutzt habe. Die Syntax ist kompakter, aber man kommt auch mit den GMF Editoren ganz gut klar, das ist IMO nicht das große Problem. Die Schwierigkeiten liegen IMO mehr im Code der ber GMF (zumindest war das früher so) schwierig zu erweitern ist (da sehr komplex).



> Graphiti sieht auf den ersten Blick sehr interessant aus. Werde ich mich auf jeden Fall mal genauer informieren, ist halt die Frage, ob das Framework nicht noch zu jung ist. GMF wirkt halt schon sehr ausgereift.


Das Framework ist zwar ein junges Eclipse Projekt, ist aber eigentlich schon einige Jahre alt und bei SAP entwickelt (und dort produktiv im Einsatz).
Wir haben mit einem frühen Milestone einen ersten Prototyp implementiert und das ging schon sehr gut.
Also für meine Begriffe ist es angenehmer mit Graphiti zu entwickeln als mit GMF, aber am besten investierst du einfach mal ein paar Stunden/Tage in beide Frameworks und entscheidest selbst welches für dich am besten passt.


----------



## ChristianB (8. Jun 2011)

Wildcard hat gesagt.:


> Sollte mit Graphiti auch kein Problem sein. EMF Modelle liefern die notwendige Validierungslogik sowieso schon mit.


Klingt gut, bin schon fast überzeugt von Graphiti  Das Hauptproblem was ich noch sehe ist die Dokumentation, Tutorials und allgemein Infos, die man am Netz dazu findet. Zu GMF gibts da halt wirklich ne Menge. Bei Graphiti siehts eher ein bissal mau aus. Anfangstutorials gibt es schon, aber z.B. zur Validierung ist das einzige was ich gefunden habe, dass es mit den Boardmitteln von EMF möglich ist (wie du auch schon sagtest)



Wildcard hat gesagt.:


> Die Schwierigkeiten liegen IMO mehr im Code der ber GMF (zumindest war das früher so) schwierig zu erweitern ist (da sehr komplex).


Hast dafür vielleicht noch ein konkreteres Beispiel? Ich kann mir das noch nicht ganz so vorstellen. So wie ich das jetzt verstehe werden bei GMF aus diversen Models in mehreren Schritten Code generiert. Die Models bzw. auch der generierten Code (gmfgraph, gmfmap, gmftool, gmfgen, siehe GMF-Überblick) kann nun weiter modifiziert werden. Komplex sind dabei wahrscheinlich die vielen verschieden Models, an denen man rumbasteln muss und auch das Testen des Editors stell ich mir nicht so schnell vor, da man immer wieder neu Code generieren muss. Was ist z.B wenn ich zunächst gmfgen und im danach gmfgraph modifiziere und aus diesem wieder den gmfgen geniere. Sind die vorherigen Modifikationen am gmfgen dann verloren?



Wildcard hat gesagt.:


> Also für meine Begriffe ist es angenehmer mit Graphiti zu entwickeln als mit GMF, aber am besten investierst du einfach mal ein paar Stunden/Tage in beide Frameworks und entscheidest selbst welches für dich am besten passt.


Ich glaube dir auf jeden Fall sofort, dass Graphiti angenehmer ist zu verwenden. Nur in Java entwickeln -  was gibt es Schöneres  Auch das Antesten der beiden Frameworks werde ich auf jeden Fall machen. Allerdings werde ich wohl auch nach dem Rumprobieren nicht wirklich entscheiden können, was sich bezüglich Erweiterbarkeit besser eignet. Das ist schwierig abzuschätzen, ohne bei den Frameworks in die Tiefe zu gehen.

Da habe ich halt ein wenig Angst bei Graphiti, dass durch die zusätzliche Abstraktionsschicht von GEF gewisse Funktionalität und Erweiterbarkeit verloren geht. 
Die Elemente, die im Editor von mir dargestellt werden müssen, können recht komplex werden. Beliebige Schachtelung (z.B. Schleifen innerhalb Schleifen) muss möglich sein. Ich werde auch größere Elemente in der Palette haben (z.B eine komplette Schleife, die man als Ganzes in das Diagramm einbauen kann). 
Auf jeden Fall brauch ich schon eine Menge Spielraum bzgl. der grafischen Darstellung und eben auch bzgl. Validierung und da hab ich bei GMF insgesamt ein besseres Gefühl.


----------



## Wildcard (8. Jun 2011)

> Hast dafür vielleicht noch ein konkreteres Beispiel? Ich kann mir das noch nicht ganz so vorstellen. So wie ich das jetzt verstehe werden bei GMF aus diversen Models in mehreren Schritten Code generiert. Die Models bzw. auch der generierten Code (gmfgraph, gmfmap, gmftool, gmfgen, siehe GMF-Überblick) kann nun weiter modifiziert werden. Komplex sind dabei wahrscheinlich die vielen verschieden Models, an denen man rumbasteln muss und auch das Testen des Editors stell ich mir nicht so schnell vor, da man immer wieder neu Code generieren muss. Was ist z.B wenn ich zunächst gmfgen und im danach gmfgraph modifiziere und aus diesem wieder den gmfgen geniere. Sind die vorherigen Modifikationen am gmfgen dann verloren?


Zumindest vor 2 Jahren (da habe ich zum letzten mal mit GMF gearbeitet) gingen die meisten Änderungen in der gmfgen tatsächlich verloren.
Das fand ich allerdings weniger problematisch als das Code Mergen. Wer EMF oder Xtext einigermaßen kennt , weiß das es dort sehr einfach ist generierten Code mit händischen Anpassungen zu verwalten.
Der Merge bei EMF funktioniert super und bei Xtext hat man dank Generation Gap sowieso keine Probleme.
Bei GMF ist das etwas anders, da tonnenweise Quellcode generiert der für mich im Gegensatz zu EMF Code auch nur sehr schwer verständlich ist.
Du machst ein @generated NOT und anfängst zu customizen. Später änderst du ein paar Kleinigkeiten im gmfmap, oder sonstwo und nichts funktioniert mehr.
Du benennst die angepasste Methode um und generierst neu nur um dabei festzustellen das der Code für diese Methode plötzlich ganz anders generiert wird.
Ich fand das damals wirklich schwierig zu verwalten aber in den 2 Jahren mag sich viel getan haben.



> Die Elemente, die im Editor von mir dargestellt werden müssen, können recht komplex werden. Beliebige Schachtelung (z.B. Schleifen innerhalb Schleifen) muss möglich sein. Ich werde auch größere Elemente in der Palette haben (z.B eine komplette Schleife, die man als Ganzes in das Diagramm einbauen kann).


Ein Beispiel zum verschachteln. Ich wollte in meinem GMF Diagramm ein Container Objekt mittels Compartment realisieren.
Der Compartment Inhalt sollte nicht automatisch angeordnet werden, sondern frei verschiebbar sein (XYLayout). Weiterhin wollte ich nicht diese lächerliche Compartment Scrollbar haben wenn ein Objekt über die Ränder des Containers hinausbewegt wird, sondern ich wollte das sich der Container automtatisch vergrößert (auch über seinen relativen Nullpunkt hinaus).
Ganz ehrlich, nach 2 Wochen Arbeit habe ich die Sache hingeschmissen.
Ich will damit nicht sagen das es nicht geht, aber der generierte Code ist teils derart kompliziert das man verzweifelt wenn man sich zu weit von den GMF Defaults entfernen möchte.
Ein Kollege hat mehrere Wochen versucht eigene Anchorpoints und einen speziellen metrischen Line Router zu entwickeln (zugegeben, keine ganz triviale Aufgabe) und ebenfalls nach einigen Wochen die Waffen gestreckt.

Mit Graphiti habe ich noch nicht genug gemacht um sagen zu können das es dort besser funktioniert, aber wie gesagt, der erste Eindruck war sehr positiv.


----------



## ChristianB (15. Jun 2011)

Ich merke schon, dass ich wohl um ein ausgiebes Testen von sowohl GMF, als auch Graphiti nicht herumkomme 

Auf jeden Fall vielen Dank nochmal für deine gute und ausführliche Hilfe!
Werde das Thema dann erstmal als erledigt markieren und bei Bedarf nochmal öffnen.


----------

