MGSE

Ein Meta-Metamodell ist ein Modell von Metamodellen usw.

Meta-Metamodelle werden bei Model-zu-Modell-Transformationen gebraucht
(wir kommen darauf in Teil 4 bei den Modelltransformationen zurück)

Ein selbstbeschreibendes (Meta-)Metamodell beendet die Meta-Rekursion

• Entity Objekt, das durch seine individuelle Existenz gekennzeichnet ist.
  Seine Attributwerte können sich über die Lebenszeit ändern.

• Value Object Objekt, das nur durch seine Attributwerte gekennzeichnet ist.
  Seine Attributwerte sind unveränderlich. Kopien sind austauschbar.

• Aggregat durch eine Entity gekapselte Sammlung von Objekten

• Domain Event Objekt, das ein in der Domäne relevantes Ereignis repräsentiert

• Service Operation, die keinem bestimmten Objekt zuzuordnen ist

• Repository Objekt, über das andere Objekte auffindbar sind

• Factory Objekt, über das andere Objekte erzeugbar sind

• Metamodelle

Modelle sollen Instanzen eines Metamodells sein.
Das Werkzeug muss gültige (d.h. zum Metamodell konforme)
von ungültigen Modellen unterscheiden können.

• Modelltransformationen

z.B. in Form von APIs für den Zugriff auf Modelle und Metamodelle,
oder mittels Transformationssprachen, ...

Beispiel: Microsoft Visio 2010 ist kein UML-Modellierungswerkzeug

• "Modelle an sich" von ihrer Repräsentation unterscheiden

ein und dasselbe Modell kann mit verschiedenen Mitteln erstellt und dargestellt werden (textuell, graphisch, interaktiv)

wir kommen darauf beim Thema domänenspezifische Sprachen zurück

• unterschiedliche Aspekte getrennt voneinander modellieren

eventuell Subdomänen definieren und dafür getrennte Modelle erstellen (z.B. technische Subdomäne(n) und fachliche Subdomäne(n) unterscheiden)

mit Subdomänen können umfangreiche Problemfelder modularisiert und damit für ein arbeitsteiliges Vorgehen erschlossen werden

Beispiel für eine technische Subdomäne: GUI-Layout

Arbeits-, Wissensgebiet, auf dem jemand besonders gut Bescheid weiß,
auf dem er sich speziell und besonders intensiv betätigt ...
(Duden Fremdwörterbuch, 1982)

Jede Software wird für eine bestimmte Domäne entwickelt,

z.B.:

• Übersetzung von Programmiersprachen

• Kommunikation in verteilten System

• Grafische Benutzeroberflächen

• Web-Shop

• Buchhaltung

• Waschmaschinensteuerung

• ...

Traditionell wird Domänenwissen in Bibliotheken (und Frameworks) erfasst, die ihrerseits in einer universellen Programmiersprache implementiert sind.

Die Aufteilung Sprachen universell und Bibliotheken domänenspezifisch ist im Prinzip ein Erfolgsmodell, hat aber trotzdem auch Nachteile:

• Das Domänenwissen muss mit Hilfe der Konzepte der Programmiersprache ausgedrückt werden (z.B. mit Funktionen oder Objekten). Die dadurch bedingte semantische Lücke ist eine Fehlerquelle und führt zu Redundanz in Form von sich wiederholendem Standardcode (Boilerplate).

Beispiele: GUI-Programmierung mit Java Swing, Datenverwaltung mit Java Collections

• Bibliotheksimplementierungen binden Domänenwissen an bestimmte Plattformen und an bestimmtes Laufzeitverhalten.

macht die Integration mehrerer Bibliotheken für unterschiedliche Domänen in einer Anwendung mitunter schwierig erfordert gegebenenfalls viele aufwendig zu pflegende Varianten einer Bibliothek

DSL (Domain Specific Language, auch: Fachsprache)

Eine formale Sprache, die speziell für ein bestimmtes Problemfeld (die Domäne) entworfen und implementiert wird.

Potentielle Vorteile einer DSL:

• die relevanten Aspekte einer Domäne (und möglichst nichts darüber hinaus) lassen sich kompakt und korrekt beschreiben und können auf unterschiedliche Implementierungen abgebildet werden

wenige spezialisierte Konzepte mit möglichst wenig syntaktischem Ballast

• Domänenexperten können damit umgehen, d.h. sie können zumindest mit der DSL verfasste Beschreibungen verstehen

Anlehnung an die in der Domäne üblichen Notationen

Entwurfsschritte für eine DSL:

• Domänenanalyse zum Bestimmen der relevanten Aspekte

• Sprachklasse, Syntax und Semantik festlegen

Menge von Symbolen mit Regeln für zulässige Kombinationen der Symbole

z.B. Programmiersprachen

formale Sprache zum Beschreiben formaler Sprachen (d.h. zum Definieren der Symbole und Regeln)

eine unendliche Meta-Rekursion ist durch selbstbeschreibende Metasprachen vermeidbar z.B. erweiterte Backus-Naur-Form (EBNF)

• Glossar

Liste von Begriffen mit Erklärungen

• Taxonomie

hierarchischer Einordnung von Begriffen in Kategorien

• Thesaurus

Taxonomie mit zusätzlichen Synonym-/Verwandtschafts-Beziehungen

• Ontologie (Begriffsnetz, semantisches Netz)

Begriffe mit Eigenschaften, beliebigen Relationen und Axiomen

Axiome sind Aussagen, die in der Domäne immer wahr sind

Taxonomien und Thesauren sind im Prinzip Spezialfälle von Ontologien
mit fest vorgegebenen Relationstypen und ohne Axiome

Klassifizierung nach Notation:

• rein textuell

• grafisch mit textuellen Beschriftungen

Klassifizierung nach Implementierung:

• Spezialisierung einer Universalsprache

z.B. UML-Profile, XML-Dialekte

• Black-Box-Einbettung in eine Wirtssprache

Kapselung in Strings oder Kommentaren der Wirtssprache

z.B. reguläre Ausdrücke, printf-Formatstrings, Dokumantationskommentare in Java

• White-Box-Einbettung in eine Wirtssprache (interne DSL)

Realisierung als Ausdrücke in der Wirtssprache

z.B. EasyMock mit Wirtssprache Java

• eigenständige Sprache (externe DSL)

z.B. HTML, Unix shell script, Makefile

- konkrete Syntax

- abstrakte Syntax

die konkrete Syntax einer DSL legt fest, wie etwas formuliert werden kann:

spezifiziert im Detail die Notation der Sprache (Schlüsselwörter, Symbole, ...),
z.B. bei textuellen DSLs mit Hilfe von regulären Ausdrücken und/oder EBNF

die konkrete Syntax ist die Benutzerschnittstelle der DSL und ist entscheidend für die Lesbarkeit der DSL durch den Menschen

die abstrakte Syntax einer DSL legt fest, was formuliert werden kann:

spezifiziert die Struktur der Sprache (Konzepte und deren Beziehungen ...), z.B. mittels eines Metamodells, das als abstrakter Syntaxgraph (ASG)
bzw. abstrakter Syntaxbaum (AST) instanziert wird

zu ein und derselben abstrakten Syntax kann es mehrere konkrete Syntaxformen geben z.B. eine textuelle und eine grafische Notation

die abstrakte Syntax ist entscheidend für die automatisierte Verarbeitung dessen,was der Benutzer mit der DSL formuliert

- statische Semantik

- dynamische Semantik

die statische Semantik regelt die Wohlgeformtheit von Formulierungen:
explizit in Form von Konsistenzregeln für abstrakte Syntaxgraphen

z.B. eindeutige Namen für Entitäten verlangen

z.B. bei Programmiersprachen: Variablen müssen vor ihrer Verwendung definiert werden

die dynamische Semantik regelt die Bedeutung von Formulierungen:

implizit in Form von Transformatoren für abstrakte Syntaxgraphen

Transformatoren erzeugen aus jedem Sprachkonzept etwas Bestimmtes

z.B. erzeugt der Compiler einer Programmiersprache aus einer Variablendefinition
eine Speicherreservierung

Werkzeuge machen eine DSL erst praktisch einsetzbar:

• Parser

wandelt konkrete Syntax in abstrakte Syntax

muss nur bei externen DSLs jeweils neu implementiert werden

• Serialisierer

wandelt abstrakte Syntax in konkrete Syntax

ist nicht immer erforderlich

• Editor

ermöglicht das interaktive Bearbeiten von konkreter und/oder abstrakter Syntax

je nach Sprachklasse und gewünschtem Komfort entweder Wiederverwendung

oder spezielle Implementierung

• Interpreter / Transformatoren / Generatoren

verarbeiten die in abstrakter Syntax vorliegende Information

legen die dynamische Semantik der DSL fest

Ein UML-Profil besteht aus

• Stereotypen Spezialisierungen von Modellelementen

• Tagged Values Attribute der Stereotypen

• Constraints Konsistenzregeln für mit den Stereotypen markierte Modellelemente

Ein UML-Profil modifiziert

• die abstrakte Syntax von UML mittels Stereotypen und Tagged Values

als Metasprache wird im Prinzip das UML-Klassendiagramm verwendet,

siehe dazu auch den MOF-Standard (Meta Object Facility)

• die statische Semantik von UML mittels Constraints

als Metasprache wird die Object Constraint Language (OCL) verwendet

• die konkrete Syntax von UML mittels graphischen Symbolen

einem Stereotyp kann ein graphisches Symbol zugeordnet werden

Constraints werden mit OCL (Object Constraint Language) formal spezifiziert.

Sie machen Aussagen über die Gültigkeit von Modellen (statische Semantik).

• Invarianten

context Klasse
inv: Bedingung

Beispiele: Wertebereich von Attributen beschränken
                Beziehungen zwischen Klassen / Objekten beschränken

• Vorbedingungen (Preconditions) und Nachbedingungen (Postconditions):

context Methode
pre: Bedingung
post: Bedingung

Bedingungen, die bei jedem Objekt der genannten Klasse zu jedem Zeitpunkt erfüllt (true) sein müssen.

Bedingungen, die vor bzw. nach Aufruf der Methode erfüllt (true) sein müssen.

- DTD

- XSD

XML kann als DSL verwendet werden.

Der Sprachumfang kann (und sollte unbedingt) formal spezifiziert werden:

• entweder mittels Metasprache DTD (Document Type Definition)

• oder mittels Metasprache XSD (XML Schema Definition).

Die XML-Spezialisierung betrifft:

• Elemente und deren syntaktische Kombination (Schachtelung, Reihenfolge, ...)

<element>...</element>

• Elementattribute und deren Wertebereiche

<element attribut="wert">

• Entities (Textbausteine, nur mittels DTD definierbar)

&entity;

In Java können APIs (Application Programming Interfaces) so definiert werden,

dass sie den Charakter einer DSL bekommen:

• Method-Chaining

API-Methoden liefern als Rückgabewert ihre this-Referenz,

um Aufrufketten innerhalb eines Ausdrucks zu ermöglichen

Beispiel: append-Methoden der Klasse java.lang.StringBuilder

String s = new StringBuilder()

.append("Hallo").append(" World!").toString();

• Method-Nesting

Rückgabewerte von API-Methoden als Argumente für API-Methodenaufrufe

dadurch sind rekursive Strukturen beschreibbar

• Object-Scoping

API-Methoden liefern als Rückgabewert jeweils ein Kontext-Objekt, das die

als nächstes aufrufbaren Methoden festlegt und Zwischenergebnisse speichert

dadurch sind bestimmte Aufrufreihenfolgen für das Method-Chaining definierbar

Siehe Skript 3-22 bis 3-24

Mit regulären Ausdrücken als Metasprache

kann die konkrete Syntax einfacher textueller DSLs definiert werden

(einfach heißt ohne rekursive Verschachtelungskonstrukte)

• Zeichenklassen:

a das Zeichen 'a'

[abc-e] eines der Zeichen 'a', 'b', 'c', 'd' oder 'e'

[^abc-e] keines der Zeichen 'a', 'b', 'c', 'd' oder 'e'

. beliebiges Zeichen (außer Zeilenwechsel)

• Quantifizierung:

r{2} zweimal hintereinander

r{1,3} ein bis drei Wiederholungen

r? entspricht r{0,1}

r* entspricht r{0,}, d.h. beliebig oft inklusive keinmal

r+ entspricht r{1,}, d.h. mindestens einmal

• Verknüpfung:

rs Konkatenation, d.h. erst r, dann s

r|s Alternative, d.h. r oder s

(r) Klammerung zum Überschreiben der Vorrangregeln

(Quantifizierung vor Konkatenation vor Alternative)

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

können kontextfreie Grammatiken für textuelle DSLs definiert werden

• Terminale:

"abc" die Zeichenfolge abc

• Nichtterminale:

Name metasprachliche Variable

• Symbolfolgen:

s t s gefolgt von t

s | t entweder s oder t

{s} beliebig viele s inklusive keinmal

[s] kein oder ein s

(s) Klammerung zum Überschreiben der Vorrangregeln

• Produktionsregeln:

Nichtterminal = Symbolfolge ;

• ein Parse-Tree zeigt, mit welchen Regeln ein Parser seine Eingabe zerlegt hat

• ein AST (Abstract Syntax Tree) entsteht aus einem Parse-Tree, indem man

die Knoten der Nicht-Terminale und der rein syntaktisch motivierten Terminale

daraus entfernt

• mit reguläre Ausdrücken und EBNF die konkrete Syntax der DSL definieren

reguläre Ausdrücke für die Definition der Tokens (Schlüsselwörter, Zahlen, Namen, ...)

und EBNF für die Definition der zulässigen Token-Folgen

daraus (in der Regel automatische) Erzeugung eines Parsers, der die Syntax prüft

• zusätzlich Rückgriff auf eine Programmiersprache,

um die abstrakte Syntax und die statische Semantik einer DSL zu definieren

als Programmiersprache empfiehlt sich die Implementierungssprache des Parsers

EBNF und die erforderlichen Programmfragmente werden oft in einer Quelle gemischt,

dann sogar automatische Erzeugung eines Parsers, der einen konsistenten abstrakten

Syntaxgraph liefert

• Beispiele für Parser-Generatoren:

flex und bison (ehemals lex und yacc) Klassiker unter Linux / Unix

ANTLR bzw. ANTLWorks aktuell viel verwendet, besonders im Java-Umfeld

flex (fast lexical analyser) generiert einen Scanner, der Symbole (Tokens)

in einem Text findet