1.
●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●© itemis AG●●DSL for UI DevelopementLessons from the PracticeEclipse DemoCamp Kepler 2013 Berlin

2.
●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●© itemis AGAgenda Vorstellung des Studien-Objektes „FormDSL“ Die Lektionen2

3.
●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●© itemis AGDAS STUDIENOBJEKTVorstellung 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 XpandFormDSL – Die IdeeEine DSL + Generator für Masken einer Swing-Anwendung4

5.
●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●© itemis AGFormDSL – Ein Beispiel-Modell5

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 GeneratorWas aus einem Masken-Modell entsteht6

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,MaskennavigationFormDSL – Das Einsatz-UmfeldUnter welchen Bedingungen muss die DSL sich bewähren7

8.
●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●© itemis AGDIE LEKTIONENWas es zu lernen gibt

9.
●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●© itemis AG Bei Generator-Fehlern oder Feature-Wünschen kann die Reaktionszeit des DSL-Entwicklersgroß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 denGenerator 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 generiertwerden 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 Entwicklerfunktionieren• Kein zusätzliches Herumärgern mit einem Headless Build auf dem Build-ServerLektion 1: Generierten Code kann man eincheckenDer Umweg über ein Source Repository bringt Vorteile9

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 zuidentifizieren• Erfahrungen der Masken-Entwickler mit der DSL und dem generierten Code können einbezogenwerden 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 unddie 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 FeaturesLektion 2: Inkrementelles DSL-Design schafft AkzeptanzFrühzeitiges Einbeziehen von Entwickler-Erfahrungen und -Wünschen10

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 zukö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 undArchitekturLektion 3: Framework-API und DSL gemeinsam designenVorgaben und Anforderungen beider Teile beeinflussen einander11

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öhen2) Anknüpfungspunkte in Framework-API und generiertem Code schaffen, um exotische oderkomplizierte 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ältniszu seiner Nutzungs-Häufigkeit Große Verlockung, Konzepte in die DSL aufzunehmen, die mit Databinding und Layout nichts zu tunhaben, z.B. Verhalten oder Navigation zwischen Masken• Spezifische DSLs für diese Konzepte sinnvoller• Modelle in verschiedenen DSLs können sich aufeinander beziehenLektion 4: Überfrachten der DSL ist verführerischFokussieren der DSL auf ihre primäre Bestimmung12

13.
●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●© itemis AG DSL wird von vielen Entwicklern über einen langen Zeitraum genutzt und trägt einen Großteil der Lastbei 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-ModelleLektion 5: DSL als professionelles Werkzeug ansehenProfessionelle Werkzeuge verlangen professionelle Pflege13

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 geschriebenemCode 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 EntwicklungsteamsLektion 6: DSL für UI lohnt sichDie Vorteile generativer Softwareentwicklung sind bei UI vielfältig14

15.
●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●© itemis AGitemis AG | Am Brambusch 15-24 | D-44536 Lünen | www.itemis.deRoland Mückeitemis AGNiederlassung Leipzigroland.muecke@itemis.de