18.3. Weiterführende Überlegungen

18.3.1. Überblick

Für die meisten kleineren Aufgaben reicht das oben beschriebene Vorgehen vollkommen aus. Für die Entwicklung umfangreicher Plugins, ist das beschriebene Vorgehen in verschiedenen Punkten hinderlich für eine effiziente Entwicklung. Insbesondere treten die Folgenden zwei Probleme auf:

  1. Das Cubetto Toolset muss bei jeder Änderung des Plugin-Codes eine Aktualisierung des Plugins vornehmen.

  2. Die Typisierung des Cubetto Toolsets verstreut sich über eine Menge von Klassen, wobei sich eine aufwändige Anpassung des Quellcodes bei Veränderungen in der Typisierung ergibt.

Beide Probleme werden in den folgenden Abschnitten behandelt.

18.3.2. Aktualisierung eines Java-Plugins

Das Problem der Aktualisierung der Plugins bei jeder Veränderung des Plugin-Codes ergibt sich aus der Art und Weise wie das Cubetto Toolset seine Plugins verwaltet. Diese werden beim Programmstart einmal initialisert und stehen danach für die weitere Arbeit zu Verfügung. Da die Initialisierung nur einmal während des Programmstarts erfolgt, muss nach jeder Code-Änderung eine Reinitialisierung erfolgen. Dieser Vorgang wird durch den Menüpunkt Plugins neu laden ausgeführt. Alternativ führt ein Neustart des Cubetto Toolset ebenfalls zur Aktualisierung der Plugins.

Plugins neu laden

Abbildung 18.6. Plugins neu laden

18.3.3. Kapselung der Cubetto-Typisierung

Der zweite Problempunkt in komplexen Plugins ist der Zugriff auf spezifische Modellelemente, welcher meistens über den Typ der Modellelemente erfolgt. Um einen umständlichen Zugriff auf einzelne Modellelemente über die komplexe Struktur der Typisierung zu vermeiden und gleichzeitig eine möglichst typnahe Notation innerhalb des Programmcodes zu gewährleisten erfolgt eine grammatikspezifische Kapselung der Cubetto-API in separaten Klassen welche während der Typisierung in einer Klassenbibliothek bereitgestellt wird.

Die folgenden Code-Beispiele zeigen einen Auszug aus der Bibliothek zur Typisierung des Modellbeispiels der Knoten und Kanten.

package kkmt;
public class KuK extends com.semture.ecube.api.elements.Model {

    public java.util.Collection getKnotens() {
    }
    public kkmt.kuk.Knoten addKnoten(java.lang.String) {
    }
    public java.util.Collection getTyps() {
    }
    public kkmt.kuk.Typ addTyp(java.lang.String) {
    }
    public java.util.Collection getKantes() {
    }
    public kkmt.kuk.Kante addKante(java.lang.String) {
    }
    public java.util.Collection getSichts() {
    }
    public kkmt.kuk.Sicht addSicht(java.lang.String) {
    }
}

Die Bezeichnung der Zugriffsmethoden erfolgt dabei entsprechend der Typbezeichnungen. Wie im oberen Abschnitt zu erkennen werden innerhalb einer ModelAPI-Klasse Methoden der Form get[OT]s() sowie add[OT](String name) erzeugt. Dies geschieht für jeden Objekttyp innerhalb des Modelltyps wobei [OT] für die jeweilige Bezeichnung des Objekttyps steht.

Wie im folgenden Codeabschnitt zu sehen efolgt die Bezeichnung der Zugriffsmethoden innerhalb der API-Klassen der einzelnen Objekttypen ähnlich. Propertytypen, für die maximal ein Wert zugelassen ist (min:..., max:1) werden mittels get[PropT]() und set[PropT](java.lang.Object) bearbeitet. Propertytypen mit den Multiplizitäten (min:..., max: >1) können über Methoden der Form get[PropT]() sowie add[PropT](java.lang.Object) und remove[PropT](java.lang.Object) verändert werden.[PropT] steht hierbei für die Bezeichnung des Propertytypen.

package kkmt.kuk;
public class Kante extends com.semture.ecube.api.elements.Object {

    public java.util.Collection getKnoten() {
    }
    public void addKnoten(java.lang.Object) {
    }
    public boolean removeKnoten(java.lang.Object) {
    }
    public java.lang.Object getName() {
    }
    public void setName(java.lang.Object) {
    }
    public kkmt.KuK getModel() {
    }
}

Die grammatikspezifische Kapselung der Cubetto-API ermöglicht somit einen einfachen Zugriff auf die modellierten Objekte auf der Typebene und verkürzt den entsprechenden Programmcode um ein Vielfaches. Der folgende Programmcode zeigt den Zugriff exemplarisch am genannten Beispiel.

//Kopieren des Schlüsselquellcodes des Modells als Ausgangspunkt (Bearbeiten-Menü)
var model = manager.getE3Object(725055, 1200569724939, 16570625, 32, 1200485162662, 10678617).getAPIObject();

//z.B. Ausgabe aller verbundenen Kanten
for (var i = model.getKantes().iterator(); i.hasNext(); ) {
    var kante = i.next();
    if (!kante.getKnotens().isEmpty()}
        out.println(kante.getName())
    }
}

//Erstellen von Objekten
model.addKante("Neue Kante");

//Erstellen von Sichten / Präsentationen
model.addViewKK;
viewType.addKnoten_und_Kanten;

//Setzen / Löschen von Einzelwerten (min = 0/1; max = 1), wirft ggf.
IllegalArgumentExeption bei Wertebereichsverletzung
knoten.setName("Knoten 1");
knoten.setName(null);

//Einfügen / Entfernen von Werten
knoten.addKante(kante);
knoten.removeKante(kante);

//Herstellen einer grafischen Verbindung [po1.connect(po2, "VerbinderPO1", "VerbinderPO2")]
po1.connect(po2, 0815, 4711);

//Grafiken / Figuren bewegen:
po.setLocation(Point2D);
po.setLocation("Name der Figure", Point2D);

18.3.4. Externe Verwendung der API-Bibliothek

Zur externen Verwendung der während der Typisierung im Hintergrund erstellten Klassenbibliothek besteht die Möglichkeit, diese in ein JAR-Paket zu exportieren, welches dann innerhalb einer externen Entwicklungsumgebung als Bibliothek eingebunden werden kann. Dies ermöglicht die Verwendung der API-Bibliothek bei der Entwicklung von Cubetto-Plugins.

Typisierung exportieren

Abbildung 18.7. Typisierung exportieren

WICHTIG:

Beim Deployment des Plugins darf die API-Bibliothek nicht mit in das .jar-Paket des Plugins exportiert werden.