Es werden sechs Lektionen vorgestellt, die beim Einsatz einer textuellen Domain Specific Language (DSL) für die modellgetriebene Entwicklung eines User Interfaces (UI) gelernt wurden.

1. ●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
© itemis AG
●
●
DSL for UI Developement
Lessons from the Practice
Eclipse DemoCamp Kepler 2013 Berlin

2. ●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
© itemis AG
Agenda
 Vorstellung des Studien-Objektes „FormDSL“
 Die Lektionen
2

3. ●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
© itemis AG
DAS STUDIENOBJEKT
Vorstellung der FormDSL

4. ●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
© itemis AG
 Modellierung der UI-Komponenten einer Maske
• Textfelder, Checkboxen, Buttons, Tabellen etc.
• Einige Spezial-Komponenten, z.B. Widget für die Anzeige und Auswahl von Katalog-Einträgen
 Databinding zum Businessobjekt-Modell
• Widgets werden mit Businessobjekt-Attributen verbunden
• Übernahme von Datentypen, Feldlängen aus dem Businessobjekt-Modell
• Swing-Komponente eines Widgets aus seinem Datentyp abgeleitet (Boolean  Checkbox)
• Databinding auch zu berechneten Werten außerhalb des Businessobjekt-Modells möglich
 Layout-Informationen
• Anordnung der Widgets in der Maske in textueller Syntax (kein graphischer Layout-Editor)
• Angabe von Layout-Constraints (für MiG Layout)
 DSL mit Xtext, Generator mit Xpand
FormDSL – Die Idee
Eine DSL + Generator für Masken einer Swing-Anwendung
4

5. ●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
© itemis AG
FormDSL – Ein Beispiel-Modell
5

6. ●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
© itemis AG
 Generierung mehrerer Klassen pro Maske für MVC-Pattern
• View-Klassen für das Erzeugen und Zusammenfügen der Swing-Komponenten
• Model-Klasse mit Methoden für Databinding
• Stubs für Unittest-Klassen
 Generation Gap Pattern
• Kontinuierlich generierte Base-Klassen (Ableitung von Framework-Klassen)
• Einmalig generierte Klassen für manuelle Implementationen (Ableitung von Base-Klassen)
FormDSL – Der Generator
Was aus einem Masken-Modell entsteht
6

7. ●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
© itemis AG
 Einsatzzeitraum dreieinhalb Jahre
• Entwicklungsbeginn war Anfang 2010
• Produktionsreife nach ca. 6 Monaten erreicht
 Genutzt von einem großen Entwicklungsteam aus durchschnittlich 10 Masken-Entwicklern
 Große Personalfluktuation
• Insgesamt wurde die FormDSL bislang von 18 Entwicklern eingesetzt
 Anwendung enthält knapp 500 Masken, davon 293 mit der FormDSL erzeugt
 Eine Handvoll weiterer DSLs im Einsatz: Businessobjekte, Kataloge, Integrationstests,
Maskennavigation
FormDSL – Das Einsatz-Umfeld
Unter welchen Bedingungen muss die DSL sich bewähren
7

8. ●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
© itemis AG
DIE LEKTIONEN
Was es zu lernen gibt

9. ●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
© itemis AG
 Bei Generator-Fehlern oder Feature-Wünschen kann die Reaktionszeit des DSL-Entwicklers
großzügiger ausfallen
• Fehlerbehebung oder Workaround durch den Masken-Entwickler in den generierten Base-Klassen
 Manuelle Änderungen an generierten Base-Klassen können als Referenzimplementation für den
Generator dienen
 Problematisch, wenn mehrere Masken-Entwickler an derselben Maske arbeiten, da manuelle
Änderungen versehentlich überschrieben werden können
 Regelmäßige Kontrolle auf manuelle Änderungen, indem in einem Batch-Lauf alle Masken generiert
werden und die generierten Klassen mit dem Source Repository abgeglichen werden
• Verhindert, dass faule Masken-Entwickler ständig in den generierten Klassen herumschreiben
 Bonus-Vorteil: Es muss nur das Eclipse-interne Build-System für das Generieren durch die Entwickler
funktionieren
• Kein zusätzliches Herumärgern mit einem Headless Build auf dem Build-Server
Lektion 1: Generierten Code kann man einchecken
Der Umweg über ein Source Repository bringt Vorteile
9

10. ●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
© itemis AG
 Wenige vollständig manuell programmierte Masken dienen als Referenzimplementation
 Iteratives Aufbauen von DSL und Generator
• Frühzeitiges Verwenden der DSL für einfache Masken
• Nach und nach Umsetzen von komplexeren Masken, um fehlende Sprach-Features zu
identifizieren
• Erfahrungen der Masken-Entwickler mit der DSL und dem generierten Code können einbezogen
werden
 Geschwindigkeit der Maskenentwicklung zunächst geringer
• Feedback zum DSL-Entwickler und fehlende Features kosten Zeit
• Die zunächst manuell programmierte Masken müssen anschließend mit der DSL erneut gebaut und
die bestehende Fachlogik übertragen werden
• DSL- und Generator-Entwicklung in dieser Phase Full-Time-Job, später nur noch Maintenance, d.h.
Fehlerbehebung und kaum noch neue Features
Lektion 2: Inkrementelles DSL-Design schafft Akzeptanz
Frühzeitiges Einbeziehen von Entwickler-Erfahrungen und -Wünschen
10

11. ●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
© itemis AG
 Generierter Code setzt auf der API eines zugrundeliegenden Frameworks auf
• Generator „kennt“ diese API und generiert Code gegen diese API
• DSL nutzt Konzepte der API oder abstrahiert von ihnen, z.B. „Widget“, „Button“ oder „Action“
 Elegante Sprachkonstrukte der DSL nur möglich, wenn die Framework-API sie ermöglicht
• Anforderungen der DSL beim API-Design berücksichtigen
 Hooks in der API der generierten Klassen anbieten, um manuelle Anpassungen vornehmen zu
können
• Überschreiben von preXxx()- und postXxx()-Methoden sowie createXxx()-Methoden
 Übrige Wege verschließen (Methoden in Base-Klassen sind final)
• Entwickler bekommen nach Möglichkeit exakt einen Weg geboten, ihr Problem zu lösen
• Diese Weg soll der bequemste für die Entwickler sein und der eleganteste bzgl. der API und
Architektur
Lektion 3: Framework-API und DSL gemeinsam designen
Vorgaben und Anforderungen beider Teile beeinflussen einander
11

12. ●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
© itemis AG
 Diskrepanz zwischen der Ausdrucksmächtigkeit der DSL und der Komplexität von Masken und UI-
Komponenten
 Es gibt zwei Wege, damit umzugehen:
1) Ausdrucksmächtigkeit der DSL erhöhen und damit die Komplexität der DSL erhöhen
2) Anknüpfungspunkte in Framework-API und generiertem Code schaffen, um exotische oder
komplizierte Anforderungen in der Ziel-Programmiersprache zu realisieren
 Komplexe DSL ist von den Masken-Entwicklern schwerer zu erlernen und zu bedienen
 Realisierungs- und Wartungsaufwand eines exotischen DSL-Features steht in schlechtem Verhältnis
zu seiner Nutzungs-Häufigkeit
 Große Verlockung, Konzepte in die DSL aufzunehmen, die mit Databinding und Layout nichts zu tun
haben, z.B. Verhalten oder Navigation zwischen Masken
• Spezifische DSLs für diese Konzepte sinnvoller
• Modelle in verschiedenen DSLs können sich aufeinander beziehen
Lektion 4: Überfrachten der DSL ist verführerisch
Fokussieren der DSL auf ihre primäre Bestimmung
12

13. ●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
© itemis AG
 DSL wird von vielen Entwicklern über einen langen Zeitraum genutzt und trägt einen Großteil der Last
bei der Masken-Entwicklung
• DSL hat maßgeblichen Einfluss auf die Produktivität des Teams
• DSL hat das Experimental-Stadium des Xtext-Geeks verlassen
 Es bestehen ähnliche Erwartungen an die Qualität wie für externe Werkzeuge
• Nicht-funktionale Features wie z.B. Gestaltung des Outline-Views, Editor-Icon, Formatter
• Referenz-Dokumentation und ggf. Schulungs-Material für neue Team-Mitglieder
• Saubere Plugin-Entwicklung z.B. Plugin-Namen und –Versionen
 Höhere Turnaround-Zeiten für neue DSL-Features sind einzukalkulieren
 Große Änderungen der DSL als „Zwischen-Projekte“ einplanen
• Nicht abwärtskompatible Änderungen erfordern u.U. das Anpassen hunderter Masken-Modelle
Lektion 5: DSL als professionelles Werkzeug ansehen
Professionelle Werkzeuge verlangen professionelle Pflege
13

14. ●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
© itemis AG
 Naheliegend: Vermeiden des Schreibens von Boilerplate-Code, wie er in der UI-Programmierung
üblich ist
• Höhere Produktivität jedes Masken-Entwicklers
 Einheitliche Programmierung mit Swing
• Über viele Entwickler hinweg
• Über eine lange Zeit hinweg
 Generierter Code gibt ein Gerüst vor, das von den Masken-Entwicklern mit manuell geschriebenem
Code gefüllt wird
• Stets mit den selben Pattern, in den selben Klassen und mit den selben Konventionen
 Einfaches Einarbeiten in den Code von Masken, die andere Entwickler gebaut haben
 Abweichungen von den üblichen Konventionen leicht zu finden
 Höhere Produktivität des gesamten Entwicklungsteams
Lektion 6: DSL für UI lohnt sich
Die Vorteile generativer Softwareentwicklung sind bei UI vielfältig
14

15. ●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
© itemis AG
itemis AG | Am Brambusch 15-24 | D-44536 Lünen | www.itemis.de
Roland Mücke
itemis AG
Niederlassung Leipzig
roland.muecke@itemis.de