DSL - Vom Hype zur Praxis am Beispiel esel. Daniel Goetze Gunther Popp

Transkript

1 DSL - Vom Hype zur Praxis am Beispiel esel Daniel Goetze Gunther Popp

2 Contributions l Das ABS-Team (ABS = Anwendungsbezogene BriefSchreibung) è Peter Fuhrmann è Lars Orta è Gunther Popp è Daniel Goetze l Wikipedia ( 2

3 Araber sind edel, schön und schnell 3 3

4 Aber: Manchmal tut s auch ein esel 4 4

5 Esel und esel Unterschiede l Der Hausesel l esel (ohne Artikel) (Equus asinus asinus) (event shipment expression language) ist ein weltweit verbreitetes Haustier. Seine Stammform ist der Afrikanische Esel. ist eine ausschließlich lokal verbreitete, zur Laufzeit interpretierte domänenspezifische Sprache. Ihre Stammform ist nicht eindeutig bestimmbar. 5

6 Was ist eine DSL? DSL Domain-Specific Language Eine domänenspezifische Sprache (englisch domain-specific language, DSL) ist eine formale Sprache, die speziell für ein bestimmtes Problemfeld (die Domäne) entworfen und implementiert wird. Beim Entwurf einer DSL wird man bemüht sein, einen hohen Grad an Problemspezifität zu erreichen: die Sprache soll alle Probleme der Domäne darstellen können und nichts darstellen können, was außerhalb der Domäne liegt. Dadurch ist sie durch Domänenspezialisten ohne besonderes Zusatzwissen bedienbar. Quelle: Wikipedia 6

7 Im DSL-Himmel Versprechungen Programmierung durch den Fachbereich Hohe Umsetzungsgeschwindigkeit und Produktivität Verständlicher Code Geringe Redundanz Domain-Specific Language Spezifikation und Implementierung in einem Rutsch Leicht erlernbar Gute Wartbarkeit 7

8 Das Projekt l Fachlicher Kontext: Migration eines Systems zur zentralen Briefschreibung bei einer Lebensversicherung l Migrationsumfang: è Briefvorlagen für ca. 300 Geschäftsvorfälle l Rendervolumen: è max. 1,1 Mio. Seiten / Tag (im Endausbau) l Herausforderungen: è Parallel Online- und Batchverarbeitung è Parallelbetrieb Alt- und Neusystem è Keine Veränderung der Schnittstellen von den Bestandssystemen è Fachliche und technische Neustrukturierung, aber keine inhaltliche Änderung der Verarbeitung è Was steckt eigentlich fachlich alles im Altsystem? 8

9 Die spezifische Domäne (Ausschnitt) Welche Dokumente? Über welchen Weg ausgegeben? An welchen Empfänger? Sachbearbeiter Bestandssystem Wie in Umschlägen zusammengefasst? Versand Versicherungsnehmer SST??? Portal Makler Batch Komplexe Logik (überraschend?): è Im Altsystem: Für ca. 300 Geschäftsvorfälle ~ IF-Anweisungen. Archiv Wie archiviert? 9

10 und unsere Lösung für diese Domäne esel, die Event Shipment Expression Language Eingangsschnittstelle (Briefauftrag) esel (Umschlagbildung und Versandsteuerung) Instanziierte Dokumente Physische Dokumente (Druck, Kuvertierung, Versand, Archivierung) ID: Event: BRIEF_01 Event BRIEF_01 BA :E:Hugo:VN Shipment when E.Rolle == VN ANSCHREIBEN VN to E SCHREIBEN to E BA :U1 D1:ANSCHREIBEN D2:SCHREIBEN 1:E:Erwin:BB 2:K:Hugo:VN Shipment when E.Rolle == BB ANSCHREIBEN BB to E SCHREIBEN to K BA :U2 D1:ANSCHREIBEN Eigenentwicklung Textsystem + Customizing 10

11 Was kann esel? l esel beschreibt für einen bestimmten Geschäftsvorfall ( Business Event ): è Welche Dokumente müssen erzeugt werden? è Wie sollen diese Dokumente in Umschlägen zusammengefasst sein? è Über welchen Weg sollen die Umschläge versendet werden? (Post, elektronisch, über Sachbearbeiter, ) è Wie müssen die Dokumente archiviert werden? (Archivparameter je Event / Umschlag / Dokument) è... l esel Skripts können unabhängig von Releases ausgeliefert werden è Schnelle Reaktion auf fachlich geforderte Änderungen l esel Skripts werden zur Laufzeit interpretiert 11

12 Was kann esel nicht? l Dokumentinhalt und -layout beschreiben è Das machen wir mit DocWrite und DocDesign von Assentis l Dokumente formatieren und rendern è Das machen wir mit DocBase von Assentis l Eine universelle Programmiersprache mit Arrays, Schleifen, Klassen, Methoden, ersetzen è Dafür haben wir Java 12

13 esel Event Skripts l Event Skripts steuern è welche Dokumente für welche Umschläge in welcher Reihenfolge instanziiert werden sollen è Event-spezifische Parameter für Rules Umschlag 1 Dokument 11 Dokument 12 SST Briefauftrag Event Skript Umschlag 2 Dokument 21 Dokument 22 13

14 esel Event Skript - Beispiel event TUTORIAL_01 vars global SourceStruct Empfaenger UmschlagEmpfaenger ; local // keine lokalen Variablen im Skript rule Archiv ( Archivbereich = Archivbereich::Einzel, Vorgangsart = "Bestand", Belegart = "Schriftwechsel", Briefname = "Unser allererstes Eventskript" ) // Es gibt nur eine Art von Umschlag in diesem Event. // Der wird bei jedem Briefaufruf erzeugt. shipment when true // Alle Dokumente im Umschlag an den Umschlagempfänger. document #ANSCHREIBEN to UmschlagEmpfaenger when true enddocument document #SCHREIBEN to UmschlagEmpfaenger when true enddocument endshipment endevent 14

15 esel Rule Skripts l Rule Skripts steuern è das Füllen der generischen Dokumentdaten von instanziierten Schriftstücken (Adressat, Absender, Unterschrift, ) è die Belegung der Metadaten für Versandziel, Archivierung, Dokument SST Fachdaten Adressat Absender Unterschrift Event Skript Parameter Rule Skript Archivmetadaten Metadaten 15

16 esel Rule Skript - Beispiel (1/2) Parameter und Variablen rule VersandzielMailSB mandatory // keine mandatory Parameter optional // keine optional Paramaeter vars global TargetStruct Versandziel versandziel ; String USERID ; // BAT_PAKET: UserId String BATNR ; // BAT_PAKET: BAT- Nr. mapping if versandziel.versandzieltyp == VersandzielTyp::MailSB then target VersandzielMailSB batnr = BATNR ; absender = "DocManager" ; empfaenger = USERID ; betreff = "Dokumente zu BAT- Nr.: " + BATNR ; mailtext = "Anbei erhalten Sie die gewünschten Dokumente." ; endtarget endif endrule 16

17 esel VariableDefinitions l Das VariableDefinition Skript è stellt die Verbindung her zwischen l Strukturen / Variablen in Java und l Strukturen / Variablen in esel è definiert die in Event- und Rule-Skripts verfügbaren Variablen. è ist Teil der Software-Auslieferung und kann daher nur mit Releases angepasst werden. SST Briefauftrag <xxx> <a> </a> <b> </b> </xxx> VariableDef String a; BigDecimal b; 17

18 esel VariableDefinitions - Beispiel definitions // Typen types // Archivbereiche Enum Archivbereich = Einzel, Kollektiv,...; // Quellstruktur Empfänger Struct Empfaenger { String ort ; String name ;... } ; // Variablen paket... String BDFD = "paket/absender/bd/fd" ; BigDecimal BDNR = "paket/absender/bd/nr" ;... brief... vardat BigDecimal GPKOMMUN ; vardat String ABRGNR ;... enddefinitions 18

19 Wie entwickeln wir esel? Sprachentwurf l Iterativ, pragmatisch und mit vielen konstruktiven Diskussionen l Fachlicher Input: è Anforderungen der Fachbereiche und Domänenspezialisten è (Code-)Analyse des Altsystems è Analyse der Entwicklungsprozesse è Gesunder Menschenverstand (steht manchmal im Widerspruch zu den Ergebnissen der Analyse) l Manchmal ist erst die Idee für das Skript da, dann die Umsetzung in esel l Manchmal ist erst die Umsetzung im Interpreter da, dann versuchen wir ein brauchbares Skript damit zu schreiben 19

20 Wie entwickeln wir esel? Die 4 wichtigsten Prinzipien Separation of Concerns: Klar definierte fachliche Funktionsbereiche, in denen die DSL eingesetzt wird. Lose Kopplung: Klar definierte, produktneutrale Schnittstelle zum Textsystem. Keep it simple : Sprachumfang (bewusst) reduziert auf das Nötigste lieber erst mal was weglassen als zu viel Features bieten. Test Driven: Sehr gute Testbarkeit der DSL-Skripte. Testfälle können vom Fachbereich bereits vor der Implementierung bereitgestellt werden. 20

21 Wie entwickeln wir esel? Technische Basis l è Framework zur Umsetzung von textuellen DSLs è Entwicklung seit Anfang 2008 im Rahmen des Eclipse Modeling Projects Funktionsumfang (out-of-the-box): l Xtext Grammar Language (XGL) für den Entwurf der Grammatik l Generierung direkt aus der Grammatik: è Parser è AST-Builder è Validatoren è Serializer è Code Formatter è Eclipse Editor 21

22 Wie entwickeln wir esel? Komponenten l Xtext Grammatik für die esel-sprache l esel-interpreter l Xtext basierte esel SEU l esel-testframework auf Basis JUnit (Ausführung) und Excel (Testdaten) um die Skripts abzusichern l Maven-Plugin zur Auslieferung der Skripte in das Repository des Produkts Assentis 22

23 Xtext Grammar Language Beispiel Parse hidden(ws, ML_COMMENT, SL_COMMENT) : ( VarsDefinitionSection EventDefinitionSection RuleDefinition ) ; /* Hier ist die Syntax fuer die Rules */ RuleDefinition : "rule" rule=id params=params ( varsection=varsection )? mapping=mapping "endrule" ; Params : {Params} ( mandatoryparams=mandatoryparams )? ( optionalparams=optionalparams )? ; MandatoryParams : {MandatoryParams} "mandatory" ( mandatory+=variabledeclaration )* ; OptionalParams : {OptionalParams} "optional" ( optional+=localvariabledefinition )* ; ( ) 23

24 Xtext Grammar Language Festlegung der DSL-Syntax (1) l Schlüsselwörter sind der Einstiegspunkt in die Grammatik RuleDefinition : "rule" rule=id params=params ( varsection=varsection )? mapping=mapping "endrule" ; Schlüsselwort Params : {Params} ( mandatoryparams=mandatoryparams )? ( optionalparams=optionalparams )? ; MandatoryParams : {MandatoryParams} "mandatory" ( mandatory+=variabledeclaration )* ; OptionalParams : {OptionalParams} "optional" ( optional+=localvariabledefinition )* ; rule Versandziel mandatory optional vars global mapping endrule 24

25 Xtext Grammar Language Festlegung der DSL-Syntax (2) l Parser-Regeln definieren die Sprachstruktur RuleDefinition : "rule" rule=id params=params ( varsection=varsection Params )? mapping=mapping "endrule" ; Params : {Params} ( mandatoryparams=mandatoryparams )? ( optionalparams=optionalparams )? ; MandatoryParams : {MandatoryParams} "mandatory" ( mandatory+=variabledeclaration )* ; Parser-Regel OptionalParams : {OptionalParams} "optional" ( optional+=localvariabledefinition )* ; rule Versandziel mandatory optional vars global mapping endrule 25

26 Generierung des AST Grammatik RuleDefinition : "rule" rule=id params=params ( varsection=varsection )? mapping=mapping "endrule" ; Xtext Generator Modell (Abstract Syntax Tree AST) public interface RuleDefinition extends Parse { String getrule(); void setrule(string value); Params getparams(); void setparams(params value); } 26

27 Parser, AST und Interpreter esel Grammatik Parse-Baum esel SEU Event Skript Xtext Parser Semantisches Modell (AST) esel Interpreter 27

28 Wie entwickeln wir mit esel? esel SEU in Eclipse 28

29 Wie entwickeln wir mit esel? esel-seu l Entwicklungsumgebung: è Eclipse mit Xtext Plugin è SVN + Assentis DocRepo è Maven basierter Build-Prozess è Testframework (basierend auf JUnit) l Features in Eclipse: è Farbliche Hervorhebung der esel Syntax è Validierung der Skripte während der Eingabe (generelle Syntax, Variablennamen, Enum-Konstanten, etc.) è Anzeige von Fehlern direkt im Editor und gesammelt in speziellen Problem-Views è Vereinfachte Struktur-Ansicht von umfangreichen Skripten è Testausführung 29

30 Wie helfen wir anderen, mit esel zu entwickeln? Nutzungskonzept, Tutorials, Beispiele 30

31 Im DSL-Himmel Versprechungen revisited Programmierung durch den Fachbereich Hohe Umsetzungsgeschwindigkeit und Produktivität Verständlicher Code Geringe Redundanz Domain-Specific Language Spezifikation und Implementierung in einem Rutsch Leicht erlernbar Gute Wartbarkeit 31

32 Unser Fazit l Würden wir es wieder so machen? è Ja, bei vergleichbaren Rahmenbedingungen (Anforderungen, Organisation, eingesetzte Produkte, Team, ) l Würden wir wieder Xtext nehmen? è Für SEU: Erfolgsentscheidend wg. Integration in Eclipse è Für DSL selber und Interpreter: eher unkritisch. l Wurden die Erwartungen erfüllt? è Hohe Umsetzungsgeschwindigkeit (der DSL und mit der DSL). Unabhängig von spezifischen Produktfeatures des Textsystems. è Gute Betreibbarkeit, Performance, Skalierbarkeit, Stabilität, l Die DSL und die eingesetzten Tools machen s nicht alleine: è SEU, Deployment, Testkonzept, Integration in Entwicklungsprozesse, Nutzungskonzept, è Das Team und die Skills im Team 32

33 Ihre Fragen? 33

34 Kontakt Daniel Goetze Gunther Popp iteratec GmbH Inselkammerstr Unterhaching 34