Seminar Informatik. 07 Fakultät für Information-, Medien und Elektrotechnik Studiengang: Master Technische Informatik. Domain Specific Language

Transkript

1 07 Fakultät für Information-, Medien und Elektrotechnik Studiengang: Master Technische Informatik Seminar Informatik Thema: Professor: Student: Domain Specific Language Prof. Dr. Hans W. Nissen Tuwana Abdulla Matrikelnummer:

2 Inhaltsverzeichnis 1. Einführung in Domain Specific Language Problem Domain Solution Domain Domain Specific Language Wann ist ein Domain Specific Language notwendig? DSL beim praktischen Einsatz Domain Specific Language mit Java erstellen Domain Specific Language mit Groovy erstellen Internal- und External DSL Internal DSL External DSL UML mit Domain Specific Language UML Profile mit UML UML Profile mit Meta-Object Facility Von der Domain-Analyse zur UML Profile Domain Specific Language Integration Internal DSL Integration DSL Integration mit Java 6 Scripting Engine DSL Integration mit Spring External DSL Integration UML Model Integration Fazit Literatur...22

3 1. Einführung in Domain Specific Language Hinweis: Die Informationen in diesem Kapitel und in allen Unterkapiteln stammen von folgende Quelle: [ghos11] Um zu verstehen was ein Domain Specific Language ist, dann muss man zuerst klären, was ein Domain genau bedeutet. Aus der allgemeinen Sprachgebrauch bedeutet ein Domain ein Gebiet. In jedes Fachgebiet gibt es verschiedene Entitäten und Prozesse. Jedes Fachgebiet lässt sich in ein Problem Domain und ein Solution Domain aufteilen. Das Domain Specific Language ist das Bindeglied zwischen den Problem Domain und den Solution Domain. Was genau das Problem Domain und das Solution Domain sind und welche Rolle dabei das Domain Specific Language spielt, wird in den unteren Unterkapiteln erläutert. 1.1 Problem Domain Das Problem Domain sind Entitäten und Prozesse in einem Fachgebiet, die man analysiert. In einem Linux Betriebssystem sind z.b. Ordner und Dateien die Entitäten. Ein Ordner verschieben ist ein Prozess. Ein Problem im Problem Domain setzt sich aus den jeweiligen Entitäten und Prozesse zusammen. Eine Datei von einem Ordner in einem anderen Ordner zu verschieben ist ein Problem, dass Teil des Problem Domains ist. 1.2 Solution Domain Wie der Name es schon andeutet, gibt das Solution Domain die Lösung für das Problem in einem Problem Domain an. Doch wie sieht so eine Lösung aus? Die Lösung des Solution Domains setzt sich aus den Werkzeugen und zusätzliche Prozessen zusammen, die Notwendig sind, um das Problem des Problem Domains zu lösen. Zum Beispiel wäre das Werkzeug, zum verschieben einer Datei, das Betriebssystem selbst. Die zusätzlichen Prozesse wären hier die Programme im Betriebssystemkern, die für den Interrupt verantwortlich sind oder ob der User berechtigt ist die Datei zu verschieben. Es ist wichtig zu wissen, dass die Lösung im Solution Domain von der Anforderung abhängt. Denn zu einem Problem gibt es verschiedene Lösungen. Die Anforderung legt fest, welcher Lösung für welches Problem durchgeführt werden soll. 1.3 Domain Specific Language Wenn sich zwei Menschen unterhalten, dann ist die Sprache das entscheidende Kriterium. Erst wenn beide Personen die selbe Sprache verwenden, dann kann eine vernünftige Unterhaltung entstehen. Dies ist hier nicht anderes. Das Problem Domain und das Solution Domain müssen die selbe Sprache verwenden, um für einen Problem eine Lösung angeben zu können. Die Sprache, dass von einem Problem Domain und einem Solution Domain verwendet wird heißt Domain Specific Language (DSL). Mit Hilfe des Domain Specific Languages wird das Problem genau erfasst. Im Solution Domain wird das Domain Specific Language interpretiert und eine Lösung wird durchgeführt. 1

4 Um zum Beispiel eine Datei zu verschieben, können wir dies dem Betriebssystem mitteilen, indem wir es in der Linux-Shall eingeben. Das eingegebene Befehl, für die Verschiebung der Datei, ist ein Domain Specific Language. Das Betriebssystem interpretiert den eingegebene Befehl und verschiebt die Datei. Domain Specific Language ist keine rarität. Fast überall begegnet uns solche Sprachen. Viele von uns haben es sogar mehrfach verwendet. Zu Domain Specific Language gehören zum Beispiel Sprachen wie SQL, HTML, CSS oder ANT. Sie alle teilen die gleiche Eigenschaft. Sie sind hervorragend geeignet, um bestimmte Aufgaben zu lösen. Aber man kann sie nicht allgemein verwenden. Zum Beispiel kann man mit HTML keine Algorithmen programmieren, dafür aber einfach eine statische Internetseite realisieren. 1.4 Wann ist ein Domain Specific Language notwendig? Die Entscheidung, ob ein Domain Specific Language in einem Projekt notwendig ist, hängt davon ab, ob es einem Vorteile bringt. Domain Specific Language hat allgemein folgende Vorteile: Domain Specific Language ist ausdrucksstark: Domain Specific Language ist angelehnt an das jeweilige Fachgebiet. Die Fachbegriffe, die dort verwendet werden, werden auch in der Domain Specific Language verwendet. Dadurch ist es möglich Spezialisten in die Entwicklung zu integrieren, die nicht in der IT-Welt zuhause sind (z.b Aktienhändler). Domain Specific Language ist prägnant: Dank des Domain Specific Languages kann ein User einfach das geschriebene Code nachvollziehen. Dies ist zum Beispiel bei einem C++ Code nicht der Fall. Die Einarbeitung, in einem schon geschriebenen C++ Code, kann unter Umständen lange dauern. Außerdem hätten Spezialisten, die in der IT-Welt nicht Zuhause sind, keine Chance den Code zu verstehen. Domain Specific Language bietet einen hohen Level an Abstraktion: Bei einem Domain Specific Language spielen Implementierungstechniken keine Rolle. Die Sprache ist nach Möglichkeit vollkommen an das jeweilige Fachgebiet angegliedert. Dadurch wird die Sprache auch für Experten interessant, die keine Ahnung von der Softwareentwicklung haben. Domain Specific Language hat nicht nur Vorteile, sondern auch Nachteile: Die Entwicklung der Sprache: Bevor man ein Domain Specific Language verwenden kann, muss dies erst mal entwickelt werden. Dies kann unter Umständen sehr komplex werden. Ist die Sprache noch nicht entwickelt, dann werden die Kosten für die jeweiligen Projekte höher sein, da die Entwicklung eines Domain Specific Languages ein eigenständiges Projekt ist. Vielleicht kann das Domain Specific Language in anderen Projekten wiederverwendet werden, was auf Dauer sich wieder rentiert. 2

5 Aber am Anfang bleiben die hohen Kosten und diese müssen bei der Entscheidung, ob für das Projekt ein Domain Specific Language notwendig ist, berücksichtigt werden. Performance bedenken: Wegen der hohen Level an Abstraktion kann es zu Performance-Problemen kommen. Solche Performance-Probleme sind bei normalen Anwendungssoftware zweitrangig aber bei Programmen in eingebetteten System sind solche Performance-Probleme sehr bedenklich. Es gibt sicherlich auch andere Vor- und Nachteile und hängt meistens vom jeweiligen Fachgebiet ab. Auch diese Merkmale müssen bei der Entscheidung, für oder gegen den Einsatz von Domain Specific Language, in Betracht gezogen werden. 3

6 2. DSL beim praktischen Einsatz Hinweis: Die Informationen in diesem Kapitel und in allen Unterkapiteln (Kapitel 2.4 ausgeschlossen) stammen von folgende Quelle: [ghos11] Es gibt zwei verschiedene Formen von Domain Specific Language. Die sogennanten Internal DSL und die External DSL. Ein Internal DSL basiert auf eine bereits entwickelte Sprache. Diese wird meistens weiterentwickelt. Das External DSL wird von Grund auf neu entwickelt. In der folgenden Kapiteln werden Beispiele von Domain Specific Languages gezeigt, die mit unterschiedlichen Programmiersprachen entwickelt worden sind. Es werden auch die verschiedenen Entwurfsmuster bei der Entwicklung von Internal- und External DSL gezeigt. Außerdem tauchen wir in die Welt von UML mit DSL ein. 2.1 Domain Specific Language mit Java erstellen Das folgender Code-Beispiel zeigt die Implementierung eines Domain Specific Languages in der Programmiersprache Java: Code 1: Java DSL public class Order { static class Builder { private String security; private int quantity; private int limitprice; private boolean allornone; private int value; private String boughtorsold; public Builder() { public Builder buy(int quantity, String security) { this.boughtorsold = "Bought"; this.quantity = quantity; this.security = security; return this; public Builder sell(int quantity, String security) { this.boughtorsold = "Sold"; this.quantity = quantity; this.security = security; return this; public Builder atlimitprice(int p) { this.limitprice = p; return this; 4

7 public Builder allornone() { this.allornone = true; return this; public Builder valueas(ordervaluer ov) { this.value = ov.valueas(quantity, limitprice); return this; public Order build() { return new Order(this); private final String security; private final int quantity; private final int limitprice; private final boolean allornone; private int value; private final String boughtorsold; private Order(Builder b) { security = b.security; quantity = b.quantity; limitprice = b.limitprice; allornone = b.allornone; value = b.value; boughtorsold = b.boughtorsold; //Getters und Setters public interface OrderValuer { int valueas(int qty, int unitprice); public class StandardOrderValuer implements OrderValuer { public int valueas(int qty, int unitprice) { return unitprice * qty; Das Beispiel realisiert ein Domain Specific Language für einen Trading System. Durch das Domain Specific Language sollen Experten ohne große mühe Order platzieren können. Wie so ein Order mit dem soeben erstellten Domain Specific Language aussehen kann, zeigt folgende Code 2: 5

8 Code 2: Order platzieren mit Java DSL Order o = new Order.Builder().buy(100, "IBM").atLimitPrice(300).allOrNone().valueAs(new StandardOrderValuer()).build(); Allerdings weist das Java DSL einige schwächen auf. Man kann zum Beispiel sehen, dass für den Order ein Objekt der Klasse Builder und die Methode build() benötigt werden. Diese beiden Merkmale des Java DSLs haben nichts mit dem Fachgebiet zu tun. Java braucht diese Merkmale, um den Order zusammenzustellen. Für einen Experten, in einem Fachgebiet, sind solche Java spezifischen Eigenschaften irreführend und nicht praktikabel. Wir brauchen eine andere Programmiersprache, um eine prägnantere Domain Specific Language zu erstellen. 2.2 Domain Specific Language mit Groovy erstellen Im Gegensatz zu Java bietet Groovy durch META-Programmierung bessere Möglichkeiten an, um prägnantere Domain Specific Language zu entwickeln. Code 3 zeigt ein Beispiel, wie mit Groovy das Domain Specific Language aussieht. Code 3: Order platzieren mit Groovy DSL ord = neworder.to.buy(100.shares.of('ibm')) { limitprice 300 allornone true valueas {qty, unitprice -> qty * unitprice Im Gegensatz zu Java DSL kann man sehen, dass Methoden, wie z.b. build(), in Groovy DSL nicht verwendet werden. Stattdessen ist die Sprache sehr prägnant und ausdrucksstark. Ein Experte, dass aus dem Fachgebiet des Aktienhandels stammt, wird die Sprache des Groovy DSLs den des Java DSLs vorziehen. Doch wie realisiert Groovy solch eine Domain Specific Language? Groovy kann durch META-Programmierung, sogar während der Laufzeit, Veränderungen an der Sprache vornehmen. Die Implementierung des oben aufgeführten Groovy DSLs zeigt Code 4. 6

9 Code 4: Groovy DSL class Order { def security def quantity def limitprice def allornone def value def bs def buy(su, closure) { bs = 'Bought' buy_sell(su, closure) def sell(su, closure) { bs = 'Sold' buy_sell(su, closure) private buy_sell(su, closure) { security = su[0] quantity = su[1] closure() def getto() { this //(1) def methodmissing(string name, args) { order.metaclass.getmetaproperty(name).setproperty(order, args) def getneworder() { order = new Order() //(2) def valueas(closure) { order.value = closure(order.quantity, order.limitprice[0]) //(3) Integer.metaClass.getShares = { -> delegate Integer.metaClass.of = { instrument -> [instrument, delegate] In (1) werden alle Methoden abgefangen, die in der Klasse Order nicht aufgelistet sind. 7

10 In (1) werden alle Methoden abgefangen, die in der Klasse Order nicht aufgelistet sind. Methoden wie limitprice werden abgefangen und intern zu Attributen konvertiert (siehe die Attribute in Code 4 und den Aufruf von limitprice in Code 3). Groovy bietet den sogenannten Closure an. Closure sind, vereinfacht gesagt Blocks mit Codes, die später ausgeführt werden. Hier (2) wird es verwendet, um das Domain Specific Language prägnanter und ausdrucksstärker zu machen. Der Unterschied zu Java DSL sieht man in Code 2 und Code 3 bei der Methode valueas(...). Man kann sehen, dass beim Groovy DSL ein Objekt vom Typ StandardOrderValuer nicht extra vom DSL User angelegt werden muss, um die Methode valueas(...) zu verwenden. Dank der META-Programmierung, kann man direkt Methoden in einem bereits angelegten Klasse injizieren. In unserem Beispiel (3) wurden hier die Methoden getshares und das Attribute shares der Klasse Integer injiziert. Das Resultat davon sieht man in Code Internal- und External DSL Domain Specific Language lässt sich in Internal- und External DSL einteilen. Internal DSL basiert auf die Entwickelung einer Sprache, durch eine andere Sprache. Bei Internal DSL ist die nötige Infrastructure für die Sprache schon gegeben. Bei External DSL wird eine Sprache von Grund auf neu entwickelt Internal DSL Es gibt zwei Formen von Domain Specific Language. Diese sind Generative DSL und Embedded DSL. Bei der generativen DSL geht es darum Codes zu erzeugen. Bei der Embedded DSL geht es darum eine Sprache in eine andere einzubetten. Trotz dieser Trennung findet man in der Realität Sprachen, die auf beide Konzepte zugreifen. Ein prominentes Beispiel wäre Rails. Rails ist ein Internal DSL und ist eingebettet in Ruby. Allerdings nutzt Rails die Möglichkeiten von Ruby, um Codes zu erzeugen. Rails ist daher auch ein generativer DSL. Bei der Embedded DSL gibt es folgender Konzepte, die verwendet werden, um die Sprache zu definieren. Smart API: Bei der Smart API geht es darum Methoden, wie eine Kette, miteinander zu kombinieren. Diese Methode haben wir schon mal benutzt (siehe Code 1). Manipulation des Syntaxbaums: Zunächst wird ein abstrakter Syntaxbaum einer bestehen Sprache erzeugt. Durch Manipulation des abstrakten Syntaxbaums wird das Domain Specific Language definiert. Reflective META-Programming: Bei der Smart API wurden die Methoden statisch aufgerufen. Doch was ist, wenn man den Aufruf der Methoden erst zur Laufzeit weiß? Dank Reflective META-Programming ist es möglich während der Laufzeit zu bestimmten welcher Methoden aufgerufen werden sollen. 8

11 Sprachen wie Ruby bieten solche Möglichkeiten an. Bei der generativen DSL gibt es folgender Konzepte, die verwendet werden, um die Sprache zu definieren. Runtime META-Programming: Dank der Laufzeit META-Programmierung ist es möglich während der Laufzeit Codes zu erzeugen. Dieses Konzept haben wir bereits im Code 4 verwendet, um eine prägnante und ausdrucksstarke Sprache zu erzeugen. Complie-Time META-Programming: Dieses Konzept der META-Programmierung ist jedem bekannt, der schon mal mit C++ programmiert hat. Hier kann man durch den Preprozessor, während der Kompilierung, C++ Codes erzeugen External DSL Das Parsen des geschriebenen Codes und die Ausführung des geschriebenen Codes sind fester Bestandteil des External DSLs. Beim External DSL gibt es folgender Konzepte, die verwendet werden, um die Sprache zu definieren. Context-Driven String Manipulation: Man kann Regeln definieren und diese als Strings hinschreiben. Die geschriebenen Regeln können durch einen Preprozessor in eine beliebige Programmiersprache übersetzt werden. Transforming XML to Consumable Resource: In Spring DI Framework werden die Konfigurationen für den DI Container in eine XML-Datei gespeichert. Diese XML-Datei ist ein External DSL, dass als Ressource für eine andere Anwendung bereitsteht. DSL Workbench: DSL Workbench bieten eine Entwicklungsumgebung an, mit der es möglich ist die Entwicklung und die Verwaltung eines External DSLs einfach durchzuführen. Eclipse Xtext ist ein prominentes Beispiel. Eclipse Xtext speichert Meta-Models bezüglich des Domain Specific Languages ab. Das Meta-Model kann dann in anderen Frameworks integriert werden. Zu den Frameworks gehören unter anderem Generatoren, rich editors usw. DSL mit eingebetteten fremden Code mixen: Tools wie YACC und ANTLR erlauben, mit der erweiterten Notation der Backus- Nauer Form, Parser für einen Domain Specific Language zu generieren. Auch kann man die Regeln, die man mit den erweiterten Backus-Nauer Form festgelegt hat, mit anderen Sprachen(C/C++ und Java) kombinieren, um den Parser zu generieren. Ob man sich für den Internal- oder External DSL entscheidet, hängt von der jeweiligen Anforderung an das System und die Ressourcen ab, die für das Projekt zur Verfügung stehen. Jeder muss selbst abwägen welches Konzept der Spracherzeugung für ihn sinnvoll ist. 9

12 2.4 UML mit Domain Specific Language Unified Modeling Language (UML) ist eine standardisierte grafische Modellierungssprache, dass überwiegend für die Entwicklung von Softwaresystemen eingesetzt wird. Ähnlich zu Java wird UML in vielen Fachbereichen eingesetzt. UML kann aber für bestimmte Fachbereiche spezialisiert werden. Dies ist z.b. bei modellgetriebe Softwareentwicklung notwendig. Durch das Model kann der Code automatisch erzeugt werden. Dadurch wird die Entwicklung einer Software nicht nur beschleunigt, sondern auch die Qualität erhöht, da automatisch generierter Code weniger Fehler enthalten. Das Standard-UML kann durch Erweiterungsmöglichkeiten, die in der UML vorgesehen sind, erweitert werden. Solche Erweiterungen werden durch Stereotypen, TaggedValues und Constraints vorgenommen und heißen UML Profile. Durch das UML Profile wird eine Sprache definiert, die Domain-Specific Modeling Language genannt wird. Diese Sprache spielt in der modellgetriebenen Softwareentwicklung eine entscheidende Rolle. Denn Dank einer solchen Sprache kann ein System durch das Model präzise erfasst werden UML Profile mit UML 2 Hinweis: Die Informationen in diesem Kapitel stammen von folgende Quelle: [fakh12] Wie bereits erwähnt erweitert ein UML Profile den Standard-UML und spezialisiert es für ein bestimmtes Fachgebiet. Ein UML Profile besteht aus folgenden Elementen: Metaclass: Ein Metaclass definiert ein Standard-UML Element. Das Metaclass kann durch Stereotypen erweitert werden. Stereotype: Stereotypen können einen oder mehrere Metaclass erweitern. Stereotypen können Attribute (tagged definition) und Assoziationen haben. Auch können Stereotypen von anderen Stereotypen erben (Generalisierung/Spezialisierung). Abbildung 2.1 zeigt ein Beispiel wie ein Stereotype ein Metaclass erweitert. Abbildung

13 Man kann sehen, dass das Stereotype den UML-Element Artifact erweitert, sodass es zu einem EJB-jar Archive wird. Constraints: Constraints sind viel mehr als nur Bedingungen. Man kann mit ihnen z.b. Attribute automatisch setzen, ohne das der Modelliere sich darum kümmern muss. Abbildung 2.2 zeigt das Beispiel aus Abbildung 2.1. Abbildung 2.2 Dieses mal ist es um einen Constraint ergänzt. Man kann sehen, dass das EJB-jar Archive die Datei ejb-jar.xml im Ordner META-INF haben muss. TaggedValue: Zusätzliche Angaben über einen verwendeten Model eines Stereotypen erfolgen über TaggedValue. Dies kann bei der Modellierung des Domains sehr hilfreich sein. Abbildung 2.3 zeigt ein Beispiel. 11

14 Abbildung 2.3 Das UML Profile selbst ist eine Art Package, das mehrere Stereotypen beinhaltet. Außerdem können UML Profile auch andere Profile durch <<reference>> importieren. Nachdem das UML Profile einsatzfähig ist, kann es in einer Applikation verwendet werden. Abbildung 2.4 zeigt ein Beispiel. Abbildung 2.4 Man kann sehen, dass die Applikation Web Application die beiden UML Profile Servlets und Java verwendet UML Profile mit Meta-Object Facility Eine wohl definierte Sprache bedeutet, dass es automatisch durch einen Computer verarbeitet werden kann [kwb03]. Eine solche Sprache verwendet meistens Grammatiken, die die Sprache erzeugen. Doch in der Welt der grafischen Modellierung gibt es keine Grammatiken, die die Sprache definieren, dass durch das UML und dessen Spezialisierung definiert ist. Deshalb hat das OMG den Meta-Object Facility eingeführt. Das Meta-Object Facility hat vier Schichten und jeder Schicht hat folgende Eigenschaften [niss10]: Schicht M0: Schicht M0 ist die unterste Schicht. Diese Schicht repräsentiert die konkreten Daten [niss10]. 12

15 Schicht M1: Hier sind die Modelle (Diagramme), mit der ein Modellierer ein System modellieren kann [niss10]. Schicht M2: Meta-Modelle der Schicht M2 definieren, wie die Modelle in der Schicht M1 aufgebaut sind [niss10]. Schicht M3: Meta-Meta-Modelle der Schicht M3 definieren, wie die Meta-Modelle der Schicht M2 aufgebaut sind. Außerdem definiert sich die Schicht M3 selbst [niss10]. Abbildung 2.5 zeigt ein Beispiel, wie so ein MOF aussehen könnte. Abbildung 2.5 [niss10] 13

16 Man kann die konkreten Daten der Schicht M0 anhand der Objektdiagramme sehen. M1 zeigt das Model des Systems. Die Elemente, die für das Model des Systems verwendet wurden, sind in der Schicht M2 definiert. Man kann auch sehen, dass Schicht M3 wiederum M2 definiert. Einige Fragen stellen sich sofort. Wie ist das MOF genau definiert? Kann man das Meta- Model der Schicht M2 erweitern? Ohne Erweiterungen, kann ich kein Domain spezifischer Sprache definieren, mit der ich das Domain präzise erfassen kann. Um solche Fragen beantworten zu können. Werden wir das MOF etwas genauer betrachten. Abbildung 2.6 zeigt das MOF in Zusammenspiel mit UML. Abbildung 2.6 [fakh12] hinweis: Ab hier stammen die Informationen von folgende Quelle (ausgenommen sind die Quellen die explizit angegeben wurden): [fakh12] 14

17 Wir betrachten die beiden UML Teilspezifikationen UML 2: Infrastructure und UML 2: Superstructure. Das UML 2: Infrastructure ist das Fundament der UML. Hier sind fast alle Elemente, die immer wieder verwendet werden. Das UML 2: Superstructure erweitert das UML 2: Infrastructure. Das UML 2: Infrastructure besteht aus zwei Paketen. Die Primitive Types (vordefinierte Elemente [OMG07] ) und das Infrastructure Library. Das Infrastructure Library ist in unserem Beispiel in zwei Pakten aufgeteilt. Das Paket Core bietet minimale Funktionalitäten an z.b. Klassen, Assoziationen usw [OMG07]. Das Paket Profiles bietet Mechanismen an, um das Core -Paket zu erweitern. In der Abbildung 2.6 sehen wir in der Schicht M3 das MOF. In der Schicht M2 sind die beiden Sprachen UML und CWM definiert. Man kann sehen, dass sowohl aus der Schicht M3, als auch aus der Schicht M2 auf das Core zurückgegriffen wird. Denn das UML 2: Infrastructure definiert die Metaclasses, die in der MOF, UML und CWM verwendet werden. Zu beachten ist die Sprache UML in der Schicht 2. Wir können sehen, wie das Paket Profile, aus der Infrastructure Library, durch <<merge>> im Inhalt des Pakets Profiles, aus der Sprache UML, verschmilzt. Wenn wir jetzt die Sprache UML aus der Schicht M2 spezialisieren möchten, dann greifen wir auf die Mechanismen zurück, die in der Infrastructure Library definiert sind. Alle Sprachen aus der Schicht M2, die das Paket Profiles aus der Infrastructure Library verwendeten, können über die selben Mechanismen für einen oder mehrere Domäne spezialisiert werden. Das können wir auch in der Abbildung 2.6 sehen. Wir können in der Schicht M1 sehen, wie die Sprache UML, aus der Schicht M2, für eine Domäne spezialisiert wird (Domain Profile 1). Das UML Profile Domain Profile 1 wird auch von Model User Model 3 verwendet Von der Domain-Analyse zur UML Profile Hinweis: Die Informationen in dieses Kapitel stammen von folgende Quelle: [seli07] Bei der Übergang der Domain-Analyse bis zum fertigen UML Profile sind einige Punkte zu beachten, die hier erwähnt werden. Es ist wichtig, dass bei der Erfassung des Domains das betrachtet werden soll was für das Domain wichtig ist. Dies soll unabhängig vom UML metamodel geschehen. Später sollen die Daten in das UML Profile überführt werden. Bei der Erfassung des Domains sollten folgende Daten berücksichtigt werden. 15

18 Das fundamentale Sprachkonstrukt: Zum Sprachkonstrukt gehören z.b. Entitäten und deren Eigenschaften. Im Falle von multi-tasking würden Prozesse, der Prozessor, Schedulers, Prozess Warteschlangen, Prioritäten usw. zum fundamentalen Sprachkonstrukt gehören. Beziehungen: Welche Beziehungen existieren zwischen den Entitäten? Zum Beispiel laufen auf einem Prozessor mehrere Prozesse. Constraints: Legt fest, wie die Sprachkonstrukte miteinander kombiniert werden sollen. Z.B. nach welches Kriterium soll der Prozessor die jeweiligen Prozesse ausführen. Konkretes Syntax: Auch das konkrete Syntax des Domain-Specific Modeling Languages muss in Betracht gezogen werden. Das Domain-Specific Modeling Language sollte sich an das jeweilige Domain orientieren, um so prägnant und ausdrucksstark wie möglich zu sein. Das Model des Domains wird jetzt Schritt für Schritt auf das UML Profile gemappt. Dabei sollten folgende Empfehlungen in Betracht gezogen werden. Bei der Wahl der UML-META-Klassen sollten die META-Klassen gewählt werden, bei der dessen Semantik dem des Domains am besten entspricht. Dies ist sehr wichtig, da das UML Semantik in vielen Tools verwendet wird. Überprüfe, ob es bei den Constraints im UML Profile zu Konflikten kommt. Überprüfe, ob einige Attribute verfeinert werden können. Attribute, die automatisch gesetzt werden, könnten durch Constraints z.b. aus der Modellierung entfernt werden. Diese würde das Domain-Specific Modeling Language prägnanter machen. 16

19 3. Domain Specific Language Integration Es gibt viele Möglichkeiten, um Domain Specific Languages in die jeweilige Applikation zu integrieren. Wir werden hier einige Techniken zeigen, wie man dies bewerkstelligt. 3.1 Internal DSL Integration Hinweis: Die Informationen in dieses Kapitel stammen von folgende Quelle: [ghos11] Internal DSL basieren auf bereits vorhandene Infrastruktur. Wir gehen davon aus, dass unsere bestehende Applikation mit der Programmiersprache Java geschrieben worden ist. Anhand einige Beispiele soll gezeigt werden, wie die Integration eines DSLs durchgeführt wird DSL Integration mit Java 6 Scripting Engine Wir schauen uns nochmal das Groovy DSL aus Kapitel 2.2 an (Code 4). Dieses Quellcode sei nun in der Datei ClientOrder.groovy gespeichert. Code 5 zeigt mehrere Order, die platziert werden müssen. Dieses Code ist in der Datei order.dsl gespeichert. Code 5: Groovy DSL Order platzieren orders = [] neworder.to.buy(100.shares.of('ibm')) { limitprice 300 allornone true valueas {qty, unitprice -> qty * unitprice orders << order neworder.to.buy(150.shares.of('goog')) { limitprice 300 allornone true valueas {qty, unitprice -> qty * unitprice orders << order neworder.to.buy(200.shares.of('msoft')) { limitprice 300 allornone true valueas {qty, unitprice -> qty * unitprice orders << order orders Um dieses Code in unsere Applikation zu verwenden, nutzen wir das Java 6 Scripting Engine. Code 6 zeigt wie dies bewerkstelligt wird. 17

20 Code 6: Java 6 Scripting Engine public class GroovyScriptEngine { public static void main(string[] args) throws Exception { ScriptEngineManager factory = new ScriptEngineManager(); ScriptEngine engine = factory.getenginebyname("groovy"); List<?> orders = (List<?>)engine.eval(new InputStreamReader( new BufferedInputStream( new SequenceInputStream( new FileInputStream("ClientOrder.groovy"), new FileInputStream("order.dsl"))))); System.out.println(orders.size()); for(object o : orders) { System.out.println(o); In Code 6 wird zunächst die Datei ClientOrder.groovy und order.dsl", mit Hilfe der Groovy ScriptEngine, geladen. Die Order werden in eine Liste gespeichert und in eine for- Schleife werden die jeweiligen Order ausgeführt DSL Integration mit Spring Seit Spring 2.0 wird die Implementierung eines Beans auch durch Programmiersprachen wie Ruby oder Groovy unterstützt. Dies soll anhand eines Beispiels verdeutlicht werden. Das Beispiel ist relativ einfach. Wenn man mit Aktien handelt, dann muss man einige Regeln beim Handeln beachten. Diese Regeln können gesetzlich oder aber auch nur hausgemacht sein. Die Regeln sollen über einen User per DSL eingegeben werden können. Um dies zu bewerkstelligen, sollen die Regeln mit der Programmiersprache Ruby realisiert werden. Diese Regeln sollen dann in mein Java Programm überführt werden. Zunächst zeigt Code 7 die Implementierung eines Java Programms mit Hilfe von Spring. Code 7: Trading Service Public class TradingServiceImpl implements TradingService{ //Regeln die dynamisch geladen werden private AccrudInterestCalculationRule public void dotrade(trade trade){ // Implementierung 18

21 public interface AccrudInterestCalculationRule{ BigDecimal calculate(trade trade); Das Ruby Programm wird dynamisch, Dank des Interfaces AccrudInterestCalculationRule, in das Java Programm geladen. Code 8 und Code 9 zeigen abschließend das Ruby Programm und die nötige Konfiguration in Spring. Code 8: calculate mit Ruby require 'java' class RubyAccruedInterestCalculationRule{ def calculate(trade) //Implementierung end end RubyAccruedInterestCalculationRule.new Code 9: Spring Konfiguration <lang:jruby id= accintcalcrule refresh-check-delay= 5000 script-interfaces= org.springframework.scripting. AccrudInterestCalculationRule script-source= classpath:rubyaccruedinterestcalculationrule.rb > </lang:jruby> Dies ist mehr als nur eine einfache Integration. Denn Dank der Spring Framework können wir somit die stärken der Programmiersprachen Ruby oder Groovy in Java einbinden. 3.2 External DSL Integration Zu External DSL Integration gibt es keinen Konzept wie das DSL integriert werden sollte. Es hängt maßgeblich davon ab, wofür das DSL gebraucht wird. Die Art und Weise, wie das External DSL integriert wird, ist ein entscheidender Faktor bei der Wahl, ob man einen External DSL entwickeln sollte. 19