MDSD

• in getrennten Übersetzungseinheiten: durch wechselsetitge Verwendung von Namen (Variablenzugriffe, ..) -> kein prinzipieller Unterschied zu Abhängigkeitne vom Plattform-Code, zur Etnschärfung lose Coupling beachten
• in einer Übersetzungseinheit:Abähnigkeiten entstehen druch Einbettung (z.B. in generierter Methode Implementierung ganz oder teilweise manuell) -> manuelle Teile gehen bei erneuter Generuerung verloren wenn nicht besonders geschützt!

• Präprozessortechnik: trennt auf Dateiebene -> generierter, meueller Code in getrennten Dateien, per Präprozessor zu übersetzbarem Code kombinieren -> führt tendenziell zu schwer lesbarem Code, erleichtert Versionsverwaltung
• Objektorierientierte Entwurfsmuster: trennt auf Klassenebene -> abstrakte Oberklasse generieren, abstrakte Methoden manuell implementieren (komplexe Vermischungen mit Template-Entwurfsmuster entflechten)
• Geschützte Berecihe: Einbettung manueller in generierter Code -> mit spez. generatorspezifischen Kommentaren markeren damit bei Neugenerierungen übernommen wird, erschwert Versionsveraltung, kann auch verloren gehen(umbeneonnen/löschen von Modellelementen,..)
• Codetemplates: Einbettung generierter in Manueller -> im manuellen Code generatorspezifische Anweisungen einbetten die generierten Code einfügen -> aktuell bevorzugte Technik
• Modellanreicherung: erlaubt Einbettung von manuellem Code auf Modellebene -> vermediet Versionsprobloeme, führt zu schwer lesbaren unübersichtlichen Modellen, beeinrträchtigt Pattformunabhängigkeit des Modells

• Templatesprachen: beschreiben Einbettung von Modellelementen in zielcode -> bieten Sprachmittel für Zugriff auf abstrakten Syntaxbaum des Modells, erlauben Transformationen in nicht-formale Sprachen, Templates ähneln dem generierende Code  --> VTL, StringTemplate
• MSM-Sprachen: (Relationssprachen) beschreiben Relationen zwischen Elementen der Quellsrapche und Elementen der Zielsprache: erlauben das Formulieren von Regeln für abbildung von Knoten des Quel-AST auf Knoten des ZielAST, verlagen gemeinsames Metamodell -> ATL, XSLT

Modell Driven Architecture -> Leitfaden der OMG mit dem Ziel komplexe Systeme mit Hilfe von Modellen besser zu beherrschen

Schwerpuntkt ist Plattformunabhängigkeit von Softwaresystemen 

Modelle reoräsentieren Systeme: Domänenmodell, logisches Systemmodell Implementierungsmodell, ..

Metamodelle definieren Sprachen in denen Modelle ausgedrückt werden

Transformationen erzeugen aus Modelle andere Modelle

Eclipse Modelling Framework -> unterstützt Generierung von Werjkzeugen und Anwendungen aus strukturiertem Datenmodell

Entwhält als Kern das Metamodell Ecore, mit dem abstrakte Syntax von dAtenmodellen definiert werden kann 

Aspektorientierte Programmierung in Java -> erweirtert Java um Sprachliche Modualisierung

auf Metaprogrammierung beruhender Programmierstil bei dem Programmierer zunächst eine oder mehrere DSLs für ihre Problemstellung entwerfen und die Problemlösung dann mit diesen DSLs fomulieren

Es werden (Meta) Programme geschriben die (Objekt) Programme verarbeiten

-> mgöliche Formen der Verarbeitung: analysieren, transfomieren, generieren

bei der Programmierung von Algorithmen und Datenstrukturen von konkreten Typen abstrahieren. Die Typen werden erst bei Benutzung der Algorithmen/Datenstrukturen ergänzt

den schematischen Code

DSL, Generator und Templates für eine spezielle Zielplattform

• Layer M0: Objekte
• Layer M1: Klassen
• Layer M2: Programmiersprache, Java-ausdrücke
• Layer M3: Grammatik, BNF

Non Turing Accetable > Turing Acceptable > dedidable > context-sensitive > context-free > regular

Eine eigene, ist aber eine vereinfachte EBNF-Notation

Einfache ERstellung textueller DSLs, Minimierung der Entwicklungszeit und Kosten von DSLs, optimale Toolunterstützung für Anwender

• Struktur der fachlichen Domäne (fachgebiete)
• Struktur der technischen Plattform (Multitieranwendungen,..)
• Struktur der Abläufe/Daten, softwaretechnische Prinzipien (separation of concerns,..)
• Organistation der beteiligten Entwickler (Firmen, Abteilungen, Teams, ..)

Ein Aspekt dominiert auf Kosten der anderen

• höhere, niedere Abstraktionsebene
• höhere -> niedere : Konkretisiergung
• niedere -> höher: Abstrahierung

• problemorientierter (Was-Modellierung)
• domänenspezifischer
• mehr generalisierend
• -> UML abstrakter als Quellcode

• lösungsorientierter (wie-programmierung)
• plattformspezifischer
• detaillierter, spezialisierter
• mehr Redundanz
• -> Klasse konkreter als interface

• externe <-> interne
• explizite <-> implizite

Wenn software Annahme über Kontext in dem sie eingesetzt wird enthält 

z.B. datenaufkommen, Hardware, OS, standardsoftware

innerhalb einer Software bauen Lösungen für Teilprobleme aufeinander auf oder sind vermischt

-> fachliche, technische Aspekte vermischt

programmiersprachlich formuliert, zur Complie/Linkzeit überwacht

-> abhängigkeit zwischen Klassen durch Methodenaufrufe

stillschweigende Annahmen, nicht autoatisch überwacht

-> reihenfolge von Elementen in einer collection, ...

horizontaler

Zu vertikaler

Zu mehr Abhängigkeiten

zu impliziten internen Abhängigkeiten