© DrHitch/Shutterstock.com
DSL mit Xtext/Xtend

1 Blitzerstellung eines 4GL-Datenmodells mit Xtext


Schon seit vielen Jahren ersparen mir „Generatoren“ langweilige Tipparbeiten, seien es geschickte SQL-Reports oder auch Winword-Serienbriefe plus Excel-Tabellen. Deshalb verfolge ich aufmerksam die DSL-Entwicklungen, besonders die von Xtext, und die im Vergleich mit meinem Arbeitsalltag sehr produktiven Editoren, die man quasi zum Nulltarif gleich dazu erhält. Nun ist es Zeit, sich auch einmal an konkreten Beispielen mit der DSL-Entwicklung vertraut zu machen. Nach dem Ansatz „we build to learn“ werde ich kleine Teilaufgaben angehen, die sich mit meiner 4GL-Arbeit kombinieren lassen. Es ist eine Erarbeitung von Xtext in „Babysteps“. Dennoch erstaunt es, wie viel Nutzen man schon aus wenigen Zeilen Xtext- bzw. Xtend-Code ziehen kann.

Ich bin Jahrgang 1953 und habe mir als Kind in der Vorweihnachtszeit die Nase an den Schaufensterscheiben platt gedrückt, hinter denen animierte Puppen in kleinen Märchenszenen den Blick auf Artikel lenkten, die höchstens als Weihnachtsgeschenke zur Erleichterung der täglichen häuslichen Arbeit beitragen würden, ansonsten aber unerreichbar waren. Jedes Jahr die gleiche Faszination: der Blick in ein Wunderland, in dem das Leben leichter und einfacher ist. Genauso bin ich mir in den letzten Jahren vorgekommen, wenn ich bei Konferenzen wie der JAX in Wiesbaden bzw. Mainz oder all den Eclipse DemoCamps den Fortschritt der Softwareentwicklung verfolgt habe.

Auch wer, so wie ich, nicht direkt mit Eclipse arbeiten kann, sondern für die Tagesarbeit an ein proprietäres 4GL-Entwicklungssystem aus den neunziger Jahren gekettet ist, braucht deshalb nicht in tiefste Depression zu verfallen („ich Armer in diesen Salzminen der puren Handarbeit“), sondern kann erhebliche Vorteile aus Werkzeugen ziehen, die im Umfeld von Eclipse entstehen.

Das tägliche Geschäft in einer 4GL der neunziger Jahre

„Meine“ 4GL – derselbe Euphemismus des Besitzes, der auch in langen Ehen auftritt – zeichnet sich durch ein datenbankgebundenes Repository aus, in dem neben einer Vielzahl von Parametern für den Quellcode pro Event ein eigenes Datenbankfeld vorgesehen ist. Die „Entwicklung“ besteht darin, isoliert gesehene Textfelder mit etwas Sinnvollem zu füllen. Kern ist das Datenmodell, das neben dokumentierenden Texten auch die Standardkodierung und den Feldführungstext enthält. Für erstellte Masken können diese als Vorgabewerte direkt genutzt oder aber lokal modifiziert werden.

Mit vielen Tastendrücken und Mauswechseln arbeitet man sich auf dem Stand der frühen neunziger Jahre in großen Datenerfassungsmasken (Abb. 1.1) zu den wenigen Zielfeldern vor, fühlt sich aber an die Siebziger und Achtziger erinnert. Damals gab es noch das Berufsbild des „Data Entry Clerk“, der mit fantastischer Geschwindigkeit Tag für Tag Daten aus langen Listen „in den Computer“ eintippte.

merkel_1_1.png

Abbildung 1.1: Große Erfassungsmasken: man „tabt“ sich zu den wenigen Feldern durch, die auszufüllen sind

Es geht auch eleganter

Ich bin ein langsamer Tipper und deshalb geneigt, langwierige Aufgaben zu erleichtern, indem ich zumindest Teilbereiche automatisiere. Bei genauerem Hinschauen zeigt sich, dass selbst in proprietären Programmierumgebungen, die nicht auf Textdateien aufbauen, ein beträchtlicher Aufgabenteil ausgelagert werden kann, selbst, wenn der extern erzeugte Codeblock dann per Copy and Paste in den eigentlichen Programmcode übernommen werden muss. In vielen Repository-orientierten Entwicklungsplattformen, so auch der unseren, gibt es Ladeschnittstellen, um z. B. CASE-Tools anbinden zu können. Diese bieten einen Ansatz für unsere eigene Schnelleingabe.

Die Nutzung einer DSL samt Codegenerator kapselt die Vorschriften einer technikorientierten Ladedatei und erlaubt es, uns auf das Wesentliche zu konzentrieren. Im Prinzip reicht es also aus, gerade genügend Aufwand in die Entwicklung einer DSL zu stecken, um eine gegebene Aufgabe durchzuführen, die wir alternativ auch durch viel Tipparbeit erreichen könnten.

Die Aufgabe

Zumindest in meiner 4GL-Welt beginnt alles damit, erst einmal das Datenmodell anzulegen, mit dem dann gearbeitet werden soll. Mal entwickelt sich das Datenmodell im Laufe der Zeit, und die „Sklavenarbeit“ verteilt sich mit den anderen Tätigkeiten. Aber ab und zu fängt das Ganze damit an, dass ein Tsunami von Eintipparbeit zu bewältigen ist.

Kürzlich landete ich bei sehr alten Projektnotizen, der recht umfangreichen Beschreibung des Vorhabens, eine Zolltarifdatenbank mit 100+ Tabellen in mein 4GL-System einzubringen. In größeren Winword-Dokumenten waren die einzelnen Tabellen beschrieben. Zwei kleine Beispiele zeigen Tabelle 1.1 und 1.2, Primärschlüssel sind kursiv, das Feld „KURZ_BESCHR“ ist jeweils optional.

Feld

Datenelement

Format

ABG_SATZ_KOMP_ID

Abgabenart-ID (TARIC2)

CHAR(2)

DAT_START

Datum Gültigkeitsbeginn (TARIC2)

DATE

DAT_END

Datum Gültigkeitsende (TARIC2)

DATE

ABG_SATZ_KOMP_ANW_CODE

Code der Anwendbarkeit eines Abgabensatzes (TARIC2)

CHAR(1)

MASS_EINH_ANW_CODE

Anwendbarer Code der Maßeinheit (TARIC2)

CHAR(1)

WAEHR_EINH_ANW_CODE

Anwendbarer Code der Währungseinheit (TARIC2)

CHAR(1)

AKRONYM

Abkürzung (TARIC2)

CHAR(5)

KURZ_BESCHR

Kurztext (TARIC2)

VARCHAR2(100)

Tabelle 1.1: Art der Abgabe

Feld

Datenelement

Format

BESCH_ART_CODE

Bescheinigungsartcode (TARIC2)

CHAR(1)

BESCH_KONTR_NR

Bescheinigungsreferenznummer (TARIC2)

CHAR(3)

DAT_START

Datum Gültigkeitsbeginn (TARIC2)

DATE

DAT_END

Datum Gültigkeitsende (TARIC2)

DATE

KURZ_BESCHR

Kurztext (TARIC2)

VARCHAR2(100)

Tabelle 1.2: Lizenzen

Das Ziel

Die in dem Dokument enthaltenen Informationen sollen sich im 4GL Repository wiederfinden, wobei die Regeln des Repositorys berücksichtigt werden müssen. So dürfen Beschreibungen nur zwanzig Zeichen groß sein u...

Neugierig geworden? Wir haben diese Angebote für dich:

Angebote für Gewinner-Teams

Wir bieten Lizenz-Lösungen für Teams jeder Größe: Finden Sie heraus, welche Lösung am besten zu Ihnen passt.

Das Library-Modell:
IP-Zugang

Das Company-Modell:
Domain-Zugang