DSLs mit Xtext

Was ist eine DSL?

Abstraktionen einer Software-Architektur (Architekturkonzepte, Patterns, Layers, …) als Sprache (DSL) beschreiben (Architektur als Sprache)
- Sprachkonzepte entsprechen Architekturkonzepten (-strukturen)
- Potential für Missverständnisse wird stark reduziert
- habe immer eine Baseline die meine Architektur beschreibt
Um damit konkrete Anwendungen (Architekturen) zu beschreiben
semantisch sinnvoll beschreiben → mehr analysieren können und Code generieren können
technologieunabhängige Defnition
Mapping definieren (im Generator) → das können dann Experten machen
Trennung hat den Vorteil, dass man sich erstmal konzeptionell beschäftigt und nicht schon mit Technologieaspekten
- gewisse Technologieunabhängigkeit → nicht sagen "wir machen Webservice" sondern "wir kommunizieren syncron oder asyncron"
  - dann Abbildung auf XML und SOAP / MQ …

Validieung (Analyse) ob semantisch richtig ist
- gibt es Komponenten die keiner nutzt?
- eindeutige Namen
- statisch erkennbare fehler
- je mehr ich beschreibe je mehr Dinge werden statisch validierbar

wann lohnt es sicht
- je größer das System je mehr Benefit
- 3 - 5 Leute für ein paar Monare → lohnt es sich
- Produktlinien (es wäre leichtsinnig das dort nicht zu benutzen) → ist ja bei den meisten VW Systemen der Fall (sehr langer Lifecycle)

Architecture description Language (generisch) vs. spezifisch (DSL)
- mit DSL bin ich sehr viel näher an der Domäne
- bei generischer Sprache habe ich mehr als ich brauche und mir fehlt eventuell noch was
- generisch: wie verbiege ich die UML damit ich das ausdrücken kann was ich ausdrücken will (sterotypisieren)

grafische Beschreibung vs. textuell
- textuelle sind erweiterbarer
- versionierung (diff, merge, …)
- man kann auch visualisieren (Bilder generieren)
- produktiver

Umstrieg von JMS auf Webservice → Nachrichtenstruktue bleibt die gleiche → dann ändert sich nur der Generator und der generierte Code → der hangeschriebene Code nicht…

DSL
- Archiktektur
- Fahrkarten (mit Hund aber ohne Fahrrad)
- Zustandsmaschinen
- damit es sich lohnt muss es ausreichend oft vorkommen

Domain Specific Language
sich selber eine Sprache bauen die einen bei einem bestimmten Aspekt der Systementwicklung helfen
da Sprache genau auf das abgestimmt ist was man beschreiben will (die Domäne)
Verhalten, Strukturen, …, kurz und prägnant ausdrücken

DSL hat weniger code → besser lesbar
Trennung von Fachlichkeit und Technik
einfachere Integration der Fachler (Fachbereich) - könnte gemeinsam mit einem Entwickler die DSL aufschreiben

interne und externe DSL
- intern: in Programmiersprache eingebettet (Ruby, Metaprogrammierung) → bei Java (noch-?) nicht möglich
- extern: eigenständige Sprache → und dann generieren