© DrHitch/Shutterstock.com
DSL mit Xtext/Xtend

2 Feldführungstexte bearbeitet die Fachabteilung selbst


Wie das oft zitierte Beispiel „Tom streicht den Zaun“ [1] zeigt, ist es immer erstrebenswert, Arbeiten von anderen erledigen zu lassen, indem man sie passend verpackt. Umso besser, wenn diejenigen, die in dem Teilbereich entscheiden, ihre Vorgaben in einer Weise bereitstellen können, die ohne einen „Abtipper“ direkt in die Entwicklung einfließt. Hier sei auf den Verkaufserfolg von Spracherkennungssoftware verwiesen, die bei Medizinern und Anwälten das „Bitte schreiben Sie: …“ der 60er-Jahre ersetzt hat. Mit einer speziellen DSL, die gemeinsam mit der Fachabteilung erstellt wird, kann über eine simple Textdatei der Informationsfluss zwischen Nutzer und entwickeltem Produkt gestrafft und vereinfacht werden. Die Fachabteilung ist stärker an der Entwicklung beteiligt, und die klare Abtrennung bringt sichtbare Erfolgserlebnisse für die ehedem zur Passivität verdammten zukünftigen Nutzer der Anwendung, die erstellt wird. Im ersten Kapitel haben wir mit Xtext und Xtend die Festlegung eines Datenmodells nach einer Reihe von Winword-Dokumenten in meinem 4GL Repository erheblich beschleunigt. Um die notwendigen Teile einer Ladedatei zu generieren, haben wir mit Xtext eine DSL definiert, mit der wir die Steuerdaten für den Generator eingeben konnten, die alle in den Vorgabedokumenten enthalten waren. Für diese Arbeit haben wir uns eine DSL geschaffen, die auch nur „von uns Experten“ genutzt wurde. Deshalb konnten wir auf Fähigkeiten aufbauen, die für einen Entwickler selbstverständlich sind, wie das Behandeln von Hochkommas in Strings. Einmal auf den Geschmack gekommen, wollen wir jetzt der Fachabteilung eine Möglichkeit schaffen, ihr Expertenwissen direkt in die Entwicklungsarbeit einzubringen.

Eine aus dem 4GL Repository erzeugte DSL-Datei dokumentiert den Istzustand; zugleich kann diese einfache Textdatei direkt die Änderungen aufnehmen und ist mit geringem Aufwand von dem Entwickler in das Repository geladen. Der neue Istzustand wird wieder als DSL-Datei dokumentiert, eine weitere Iteration kann starten. Der Zeitaufwand für den Entwickler ist, gemessen am bisherigen Abtippen, minimal.

Fachliche Texte für das rein technische Datenmodell

Das Datenmodell, das im ersten Kapitel beschrieben wurde, war in einem Dokument festgelegt, und es ist selbstverständlich die Aufgabe des Entwicklers, diese Informationen in das 4GL Repository zu bringen, da es sich hierbei um eine „rein technische“ Arbeit handelt. Aber bei der ersten „Proof of Concept“-Maske in der 4GL wird die Fachabteilung die Feldführungstexte bemängeln, die nur den Feldnamen zeigen (Abb. 2.1).

merkel_2_1.png

Abbildung 2.1: Die Maske zeigt als Label die Feldnamen, da das Repository noch keine Labeltexte enthält

Üblicherweise wird der Entwickler jetzt von den unterschiedlichsten Mitgliedern der Fachabteilung mit Ausdrucken der Bildschirme samt eingekritzelter Texte von allen Seiten bombardiert – und allesamt sind in das Datenmodell einzutippen. Noch netter wird es, wenn der Entwickler in Meetings der Fachabteilung seinen persönlichen aktuellen Stand vorstellt und dann ein langwieriger Streit um den richtigen Text entbrennt, an deren Ende oft unklar bleibt, was denn in den Erfassungsmasken zu erscheinen habe.

Die Fachabteilung in die Entwicklung einbinden

Im Sinne der agilen Softwareentwicklung sollten die Fachabteilungen schon in frühen Entwicklungsphasen ihr Feedback geben und Korrekturen einbringen können. Mit einer Variante unserer ersten DSL können wir die Fachabteilung direkt an der Entwicklungsarbeit beteiligen.

Aus dem aktuellen Stand des Repositorys werden zum Beispiel die Feldführungstexte (Labels) als DSL-Datei erzeugt und der Fachabteilung sowohl zur Begutachtung des aktuellen Stands als auch für eventuelle Korrekturen zusammen mit dem Ausdruck einer Proof-of-Concept-Maske übergeben.

Ein einfach zu verstehender Text, der auch mit Notepad oder Winword zu bearbeiten ist, integriert die Fachabteilung in traditionelle Entwickleraufgaben. Die Fachabteilung modifiziert den DSL-Text intern. So kann sich die Entwicklungsabteilung elegant aus der gesamten Diskussion um den richtigen Text heraushalten.

Die als Änderungsantrag übergebene DSL-Datei muss der Entwickler nur formal im DSL-Editor prüfen, gegebenenfalls syntaktisch korrigieren und dann die generierte CIF-Datei in das Repository laden. Der Entwickler selbst erspart sich so tagelanges Abtippen. Als Dokumentation der Änderungen wird eine aktuelle DSL-Datei generiert, und die Fachabteilung kann in eine neue Iterationsschleife eintreten.

Das Ziel

Wieder geht es um eine CIF-Ladedatei, die aber nur auf bestehende Entitäten und Felder zugreifen kann, fachliche Texte auflistet und gleichzeitig das Medium zur Änderung darstellt.

Wir bauen unsere Grammatik auf umeCif1.xtext auf (Listings 2.1 und 2.2) und bieten Änderungsmöglichkeiten für Beschreibung, Label und Kommentare an.

// umeCif1c.xtext
grammar de.ulrichmerkel.UmeCif1c with org.eclipse.xtext.common.Terminals

generate umeCif1c "http://www.ulrichmerkel.de/UmeCif1c"

Model:
datamodel=Datamodel
entities+=Entity*
;
Entity:
'entity' name=ID 'description=' description=STRING? aComment=AComment?
'{' fields += Field* '}'
;
Datamodel:
'datamodel' modelName=ID 'description='description=STRING? aComment=AComment?
;
AComment: {AComment}
'comment=' commentText=STRING?
;
ALabel: {ALabel}
'label=' labelText=STRING?
;
Field:
'field' name=ID 'description=' description=STRING? aLabel=ALabel? aComment=AComment?
;

Listing 2.1: Grammatik: umecif1c.xtext

// UmeCif1cGenerator.xtend
package de.ulrichmerkel.generator

import de.ulrichmerkel.umeCif1c.AComment
import de.ulrichmerkel.umeCif1c.ALabel
import de....

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