MDSD

• Glossar: Liste von Begriffen + Erklärungen
• Taxonomie: hierarch. Einordnung von Begriffen in Kategorien
• Thesaurus: Taxonomie mit zusätzlichen Synonym-/Verwandtschafts-Beziehungen
• Ontologie (Begriffsnetz, sematisches Netz) begriffe mit Eigenschaften,beliebigen Relatiunen und Axiomen (Aussagen die in Domäne immer wahr sind)

• nach Notation: rein textuell/graphisch mit textuellen Beschrifutngen
• nach Implementierung: Spezialisierung einer Universalsprache (Uml-Profile,..) / Blackbox-Einbettung in eine Wirtssprache (z.B. reguläre Ausdrücke,..) / White-Box-Einbettung in eine Wirtssrpache: internere DSL (EasyMock mit Wirtssprache Java) / eigenständige Sprache: externe DSL (HTML, Unix shell script)

Legt fest WIE etwas formuliert werden kann: spezifiziert Notation der Sprache (Schlüsselwörter, Symbole,...) -> bei textuellen DSLs z.B. mit Hilfe von regulären Ausdrücken und/oder EBNF

-> ist die Benutzerschnittstelle der DSL und entscheidend für Lesbarkeit der DSL durch Menschen

Legt festr was formuliert werden kann: spezfiziert Struktur der Sprache (Konzepte + deren Beziehungen), z.b. mit Metamodell als abstrakter Syntaxgrpah (ASG) oder abstrakter Syntaxbaum (AST)

-> zu einer abstrakten Syntax kann es mehere konkrete Syntaxformen geben (textuell + graphisch, ...)

-> abstrakte Syntax ist entscheidend für automatisierte Verarbeitung dessen was der Bentuzer mit der DSL formuliert

Regelt die Wohlgeformtheit von Formulierungen: explizit in Form von Konsistenzregeln für abstrakte Syntaxgraphen (z.b. eindeutige Namen für Entitäten verlagnen, Variablen vor Verwendung definieren, ..)

regelt die Bedeutung von Formulierungen : implizit in Form von Transformatioren für abstrakte Syntaxgraphen

-> transformatoren erzeugen aus jedem sprachkonzept etwas bestimmtes

-> z.b. compiler aus Variablendefinition eine Speicherreservierung

• Parser
• Serialisierer
• Editor
• Interpreter/Transformatoren/Generatoren

Wandelt konkrete Syntax in abstrakte Snytax

-> muss nur bei externen DSLs jeweils neu implementiert werden

Wandelt abstrakte Syntax in konkrete Syntax

-> nicht immer notwendig

ermöglicht interaktives Bearbeiten von konkreter /abstrakter Syntax

verarbeiten die in abstrakter Syntax vorliegende Info

-> legen dynamische Semantik der DSL fest

Mit einem UML-Profil

• Stereotypen: Spezialisierungen von Modellelementen
• Tagged Values: Attribute der Steereotypen
• Constrains: Konsistenzregeln für mit Stereotypen markeirte Modellelemente

• abstrakte Syntax von UML mit Stereotypen und Tagged Values: als Metasprache das UML-Klassendiagramm
• statische Semantik von UML mit Constrains: Metsprache = Object Constraint Language OCL
• konkrete Syntax mit graphischen Symbolen: einem Steretotyp kann graphisches Symbol zugeordnet werden

Object Contstrais Language -> spezifizieren Constraints und machen Aussagen üder die Gültigkeit von Modellen (statische Semantik)

(UML)

• Invarianten: Bedingungen die bei jdem Objekt der genannten Klasse zu jedem Zeitpunkt erfüllt sein müssen (z.b. wertebreiche beschränken) : 
  context Klasse
  inv:Bedingung
• Vorbedingungen (Preconditions) und Nachbedingungen(Postcondidions): Bedigungeng die vor/nach Methodenaufruf erfüllt sein müssen
  context Methode
  pre: Bedingung
  post: Bedingung

Sollte man unbedingt

• Metasprache DTD (Document Type Definintion)
• Metasprache XSD (XML Schema Definition)

• Elemente und deren syntaktische Kombination (Schatelung, Reihenfolge <element>..</element>
• Elementattribute und deren WErtebrecheiche <element attribut="wert">
• Entities (textbausteine nur mit DTD definierbar) &entity;

• Method-Chaining: API-Methoden liefern als Rückgabewert this-Referenz -> ermöglichen Aufrufketten: .. = new StringBuilder().append("Hallo").append(" dei Mudder!").toString();
• Method-Nesting: Rückgabewerte von API-Methoden als Argumente für API-Methodenaurfue -> dadruch sind rekursive Strukturen beschreibbar
• Object-Scoping: apiMethoden liefern als Rückgabewert jeweils ein Kontext-Objekt das die als nächstes aufrufbaren Methoden festlegt und Zwischenergebnisse speichert -> bestimmte Aurfrufreihenfolgen für Method-Chaining definierbar

Mit regulären Ausdrücken als Metasprache

• Zeichenklassen: a, [abc-e], [^abc-e], .
• Quantifizierung: r{2}  (zweimal hintereinander), r{1,3} (ein bis dreimal), r? {0 oder 1 mal),...
• Verknüpfung: rs, r|s, (r)  ->Klammerung zum Überschreiben der Vorrangregeln

Mit der Erweiterten Backus-Naur-Form (EBNF) als Metasprache

• Terminale: "abc -> Zeicehnfolge abc
• Nichtterminale: Name  -> metasprachliche Variable
• Symbolfolgen: S t -> s gefolgt von t, s | t -> entweder s oder t, {s} -> bel. viele inkl. keinmal, ...
• Produktionsregeln: Nichtterminal = Symbolfolge;

Mit welchen Regeln ein Parser seine Eingabe zerlegt hat

(Abstract Syntax Tree) -> entsteht aus Parse-Tree indem man die Knoten der Nicht-Terminale und der rein syntaktisch motivierten Terminale daraus entfernt.

• mit regulären Ausdrücken und EBNF konkrete Syntax der DSL definieren -> Tokens (Schlüsselwörter, ..) defininieren mit regex, EBNF für def der Token-Folge, daraus Erzeugung eines Parsers der Syntax prüft
• zusätlzlich Rückgriff auf Programmiersprache um abstrakte Syntax und statische Semantik einer DSL zu defnieren -> als Progsprache empfieht lsich Impl.sprache des Parsers. EBNF und erforderliche Programmfragmente werden oft in einer Quelle gemischt, dann sogar autom. Erzeugung eines Parsers der konsistenten abstrakten Syntaxgraphen liefert

flex und bison (eheals lex und yacc) -> Linux/Unix klassiker

ANTLR bzw ANTLWorks -> besonders im Java-Umfeld

(fast lexical analyser) -> generiert Scanner der Symbole(Tokens) in einem Text findet

Generiert Parser der Tokenfolgen auf syntaktische Korrektheit prüft

(Anather tool for language Recognition)(Version 4) -> generiert Klassen für Erkennung von Tokens (Lexer statt Scanner genannt) und die syntaxanalyse. Aus einer Grammatikbeschreibung Name.g4 entstehen im Falle von Java:

• NameLexer.java
• NameParser.java
• NameListener.java
• NameBaseListener.jav

Unterschied zu flex/bison(und älteren Versionen von ANTLR) sooll Gramattikbeschreibung keine Atkionen mit Progcode enthalten, aktionen sollen stattdessen getrennt von Grammatik in einer Listener-Implementierung bereitgerstellt werden

• Modelle bevorzugt mit DSLs formulieren -> Modellerstellung kompakter, wenigerfehleranfällig, verständlich. aber: Entwicklung einer DSL evt. sehr aufwendig
• Graphisch oder textuelle DSL? ->komplexe Beziehungen = Graphik vl besser, Werkzeugunterstützung für text aber besser
• UML-Spezialisierung als DSL? -> Profile durch UML-Werkzeuge nicht wirklich gut unterstützt, Einschränkungen der Mächtigkeit von UML mittels OCL sehr mühsam
• XML-Spezialisierung als DSL? -> wenig Spielraum beim Sprachdesign, großer syntaktischer Ballast aber sehr gute Werkzeugunterstützung
• interne DSL? wenig spielraum beuim Sprachdesign, beschränkt auf programmierer die mit sprache klar kommen, geriner implementierungsaufand, geeringer Lernaufwand für Zielgruppe
• Externe dsl? max. Spielraum beim Sprachdesign, Impl.-,Pflege-, Lernaufwand kann sehr groß werden

M2M

Abbildung eines quellmodells auf ein Zielmodell, Formuleirung der Transformationsvroschriften auf Ebene der Metamodelle, beide Metamodelle müssen das glecihe Meta-Metamodell haben

M2T 

Abbildung eines Quellmodells direkt auf eine textuelle Repräsentation des Zielmodells, für die Abbildung wird kein Zielmetamodell und damit auch kein gemeinsames Meta-Metamodell  benötigt.

-> übliche Weg bei Softwaregenerierung