Doma¨nen-spezifische Sprachen dienen der Spezifikation von Modellen einer Anwendungsdoma¨ne. Neben der Syntaxpru¨fung ist es zunehmend erforderlich auch semantische Pru¨fungen der Modelle durchzufu¨hren. In den klassischen Werkzeugen zur Entwicklung Doma¨nen-spezifischer Sprachen aus dem Gebiet der Modell-basierten Entwicklung wird ha¨ufig OCL zur Spezifikation solcher Bedingungen im Meta-Modell eingesetzt. Dem gegenu¨ber stehen Technologien aus dem Gebiet des U¨ bersetzerbaus wie beispielsweise attributierte Grammatiken, die ebenfalls die Spezifikation semantischer Bedingungen ermo¨glichen. In diesem Beitrag stellen wir diese Technologien gegenu¨ber und untersuchen deren Performanz der syntaktischen und semantischen Analyse und die Qualita¨t von Fehlermeldungen.
(z.B. Makefiles2 ) werden Elemente (”Aktionspunkte“) definiert und Elemente benutzt, die zur Durchfu¨hrung der Aktion verwendet werden. Nutzen und Aufwand der Entwicklung von Doma¨nen-spezifischen Sprachen ist gut verstanden[MHS05]. DSLs und dazugeho¨rige Editoren lassen sich aus Spezifikationen generieren. Zur Pru¨fung der statischen Semantik von DSLs, wie zum Beispiel, dass alle verwendeten Bezeichner definiert werden, kommen im U¨bersetzerbau oft Attributgrammatiken[ALSU06, Knu68], im modell-basierten Umfeld ha¨ufig die Object Constraint Language (OCL), zum Einsatz[KER99, Pan11]. Beiden gemein ist, dass zu einem Kontext Vor- und Nachbedingungen bzw. Invarianten spezifiziert werden ko¨nnen; diese ko¨nnen als Spezifikation der Semantik verstanden werden.
Basierend auf unseren Erfahrungen aus der Anforderungsmodellierung in der Pumpendoma¨ne untersuchen wir anhand eines fiktiven Beispiels die Beziehung von Definition und Verwendung von Elementen (hier: Anforderungen). Diese Beziehung muss azyklisch sein, damit die Anforderungen eine Hierarchie statt eines beliebigen Graph bilden. Erst durch die Hierarchie ko¨nnen den Anforderungen Personen und Zeiten zugeordnet werden. Bei der Anforderungsmodellierung ebenfalls wichtig ist, dass Anforderungen nicht ausserhalb der Hierarchie liegen, denn dies deutet darauf hin, dass eine Anforderung nicht analysiert wurde oder gar nicht beno¨tigt wird. Wir vergleichen die Pru¨fung eben genannter Problematik – Pru¨fung auf Azyklizita¨t, Finden nicht-beno¨tigter Anforderungen und Ermitteln nicht vorhandener Anforderungen – am Beispiel der Abha¨ngigkeitsstruktur von Anforderungen in der Doma¨ne Pumpenentwicklung anhand zweier Implementierungen. Wir stellen die Methoden des U¨ bersetzerbaus der Verwendung von OCL in Modell-basierten Werkzeugen gegenu¨ber. Unser Hauptaugenmerk liegt auf der Fehlergenauigkeit und der Geschwindigkeit dieser Analysen. Ist eine Analyse langsam, kann dies eine Produktivita¨tssenkung aufgrund von Ablenkung, wie in [DL85] beschrieben, verursachen. Soll dies bei einer langsamen Analyse vermieden werden, so muss diese ”u¨ber Nacht“ laufen, beno¨tigt dann aber am na¨chsten Morgen eine sehr detaillierte Fehlerausgabe. Aufgrund der langen Laufzeit muss diese Fehlerausgabe dann auch Fehler erkennen, die u¨blicherweise erst nach der Behebung von Fehlern gefunden werden andernfalls wu¨rde die Produktivita¨t weiter sinken, da eine erneute Analyse (u¨ber Nacht) notwendig wa¨re.
Die Vorstellung des laufenden Beispiels und damit einhergehender Kriterien und Abstraktionen ist Gegenstand von Abschnitt 2. Abschnitt 3 gibt eine kurze Einfu¨hrung in die zum Versta¨ndnis der nachfolgenden Abschnitte notwendigen Definitionen. Die Umsetzung mittels Werkzeugen des U¨ bersetzerbaus und mittels OCL im modell-basierten Umfeld beschreiben wir in Abschnitt 4. Wir vergleichen die Laufzeiten und die Fehlerausgaben der beiden Implementierungen in Abschnitt 5. In Abschnitt 6 diskutieren wird die Mo¨glichkeiten im Modell-basierten Umfeld die statische Semantik von Sprachen zu spezifizieren und zeigen, dass bisher noch keine Gegenu¨berstellung der Mo¨glichkeiten mit den Methoden des U¨ bersetzerbaus erfolgt ist. Eine Zusammenfassung und offene Fragen finden sich in Abschnitt 7. 2
Wie in Abschnitt 1 ausgefu¨hrt, basieren unsere Beispiele auf der Doma¨ne ”Pumpenentwicklung“ und dabei auf dem Teilgebiet der Anforderungsmodellierung. Folgendes, laufendes Beispiel stellt fiktive Anforderungen dar3.
Anforderungsnummer 1 2 3 4 5 6 7
Es sollen Druck und Durchfluss fu¨r Anlage A erzeugt werden Es muss der Druck ermittelt werden Es muss der Druck erzeugt werden Eine Anbindung an die Anlage muss existieren Es wird ein Antrieb beno¨tigt Die Temperatur muss gemessen werden Es soll ein GPS-Navigationssystem zur Verfu¨gung stehen beno¨tigt: 2, 3, 4, 5, 8 4 4 2, 3 Beispiel 1 – Die Anforderung mit der Nummer 1 ist die sog. Wurzelanforderung – die Anforderung, die umgesetzt werden soll. Anforderung 8 wird beno¨tigt, aber ist undefiniert. 2z.B. via GNU make, http://www.gnu.org/software/make 3Echte Beispiele eignen sich aufgrund aktueller Gescha¨ftsrelevanz und Komplexita¨t nicht fu¨r eine Vorstellung im wissenschaftlichen Rahmen. In dem Beispiel der Druckerzeugung fu¨r Anlage A sind wesentliche Fehler enthalten, die es einem Projektmanager unmo¨glich machen diese Anforderungen so zu verteilen, dass diese darin mu¨nden, dass die Wurzelanforderung umgesetzt ist: Druckermittelung (4), Druckerzeugung (3) und Anlagenanbindung4 (2) sind zyklisch, von den Anforderungen 6 und 7 ha¨ngt keine Anforderung ab, es ist also egal, ob diese umgesetzt werden oder nicht. Wenn eine oder beide der Anforderungen 6 oder 7 umgesetzt werden, so wird Arbeitszeit verschwendet. Die Anforderung 8 wird zwar beno¨tigt, ist aber nirgendwo spezifiziert: ein Projektmanager kann gar nicht festlegen wer diese Anforderung umsetzen soll. Die Anforderung mit der Nummer 7 ist keine Anforderung um ein Pumpe zu erstellen, sondern stammt aus einer anderen Doma¨ne.
Abbildung 1 stellt die Abha¨ngigkeiten aus Beispiel 1 dar, der undefinierte Knoten 8 ist explizit markiert. 1 6 7
8 2 4 3 5
In den folgenden Abschnitten zeigen wir, wie die obigen Ausfu¨hrungen in statischen Analysen mu¨nden und wie diese gepru¨ft werden ko¨nnen. Beispiel 1 dient hierbei der Veranschaulichung der Ergebnisse und wird in weiteren Abschnitten verwendet um die Implementierungen geeignet gegenu¨ber zu stellen. 3
In diesem Abschnitt werden die fu¨r diesen Beitrag notwendigen Grundlagen und Begriffe eingefu¨hrt. Zur Spezifikation der Implementierung Doma¨nen-spezifischer Sprachen werden im Modell-basierten Umfeld Meta-Modelle genutzt; im U¨ bersetzerbau werden die abstrakte Syntax, sowie als Darstellungsform zum Programmierer die konkrete Syntax verwendet.
Definition 1. Eine kontextfreie Grammatik ist ein Tupel G , (T; N; P; Z), wobei
N ein endliches Alphabet der Nicht-Terminalsymbole, T ein endliches Alphabet der Terminalsymbole ist, P
N
(T [ N ) die Menge der Produktionsregeln und
Z 2 N ein ausgezeichnetes Startsymbol ist.
Wenn die durch G definierte Sprache L(G) die gu¨ltige Folge von Grundsymbolen angibt, dann bezeichnen wir G als konkrete Syntax; definiert die Grammatik Baumaufbaukonstruktoren, so bezeichnen wir G als abstrakte Syntax. Sei p 2 P , dann nutzen wir zur Darstellung der Regel ! fu¨r die konkrete Syntax und ::= fu¨r die abstrakte Syntax. Seien X; Y 2 T [ N Symbole der rechten Seite einer Regel und A 2 N , dann ist A ! XjY die Kurzschreibweise fu¨r A ! X, A ! Y ; A ! X+ Kurzschreibweise fu¨r A ! Xs X, Xs ! XjXs X und X die Kurzschreibweise fu¨r A ! Xsj", wobei " fu¨r das leere Wort steht; analoges gilt fu¨r die abstrakte Syntax. Nichtterminale nt 2 N werden mittels hnti markiert.
Im Modell-basierten Umfeld ist das Vokabular ein Anderes, doch den Prinzipien des U¨bersetzerbaus sehr a¨hnlich[Zim13]. Fu¨r das Versta¨ndnis dieser Arbeit sind folgende Ausfu¨hrungen ausreichend: wird bei Doma¨nenspezifischen Sprachen von Programmen oder Beschreibungen gesprochen, wird dies als Instanz eines Modells im Modell-basierten Umfeld bezeichnet. Wird im U¨ bersetzerbau von der abstrakten Syntax gesprochen, ist im Modell-basierten Umfeld Meta-Modell gemeint. Da dieses Meta-Modell, genauso wie Spezifikationen, auch eine Doma¨nen-spezifische Sprache sind, wird deren Implementierung bzw. Spezifikation als Meta-Metamodell bezeichnet[SVEH07, KWB03, CSW08].
4Vom Querschnitt dieser Anbindung sind Eingangsdruck und Antriebsleistung abha¨ngig. 1 root
ref 1
id:Symbol 1 use usedId * deps
def-use fusedId.id = defnId.idg * defs
1 parent defnId 1 def
id:Symbol Abbildung 2 – Beispiel eines Klassendiagramms zur Darstellung eines Meta-Modells
Klassen entsprechen den Knoten der abstrakten Syntax (siehe Abbildung 3) Da es keine einheitliche Definition fu¨r Modell und Meta-Modell gibt[SVEH07, KWB03, CSW08, Par10], geben wir hier nur eine kurze Definition fu¨r Meta-Modell wieder, entnommen aus [CSW08], die fu¨r diesen Beitrag ausreicht.
Definition 2. Ein Modell abstrahiert von einem System, Produkt oder Eigenschaften. Ein Meta-Modell ist ein Modell, das die konkrete und abstrakte Syntax einer Modellierungssprache sowie die Semantik dieser Sprache definiert. Ein Objekt ist eine Instanz eines Modells und muss Modellkonform sein, d.h. der durch das Meta-Modell beschriebenen Syntax und Semantik des Modells genu¨gen.
Ein Meta-Modell muss Teil einer Meta-Modell-Architektur sein, in [CSW08] wird dies als Meta-Metamodell bezeichnet. Zur Darstellung der Beziehungen eines Modells oder Meta-Modells ist es u¨blich Klassendiagramme oder Entity-Relationship-Diagramme zu nutzen[Par10, CSW08]. Ein Beispiel eines solchen Metamodells zeigt Abbildung 2.
Um semantische Eigenschaften, spezifiziert als Vor- und Nachbedingungen bzw. Invarianten, zu pru¨fen, kommen im U¨ bersetzerbau oft Attributgrammatiken zum Einsatz[ALSU06, Knu68, WG84], im Modell-basierten Umfeld wird ha¨ufig OCL verwendet[KER99, HJK+11].
Definition 3. Eine attributierte Grammatik ist ein Tupel AG , (G; A; R; B) wobei
G , (T; N; P; Z) eine Grammatik ist, die eine abstrakte Syntax definiert, A , ]X2(T [N)A(X) eine endliche Menge von Attributen (fu¨r jedes Symbol X der Grammatik) ist, R , ]p2P R(p) eine endliche Menge von Attributierungsregeln ist und
B , ]p2P B(p) eine endliche Menge von Bedingungen ist.
Notation: Wir schreiben X.a fu¨r ein Attribut a 2 A(X) fu¨r ein Symbol X 2 (T [ N ). Fu¨r eine Produktion p 2 P , geschrieben p : X0 ::= X1 Xn, hat eine Attributierungsregel dann die Form Xi f ( Xj , : : :, Xk) fu¨r i; j; k 2 [0; n] und f eine Funktion. Wir verzichten auf das Schreiben der Funktion, wenn f eine konstante Funktion oder die Identita¨tsfunktion ist (d.h. Xi id(Xj ) wird zu Xi Xj ). Operationen, die in der Mathematik via Infixoperation geschrieben werden, werden auch bei uns so geschrieben. Eine Bedingung fu¨r eine Produktion p in obiger Form schreiben wir '( Xj , : : :, Xk), wobei ' ein Pra¨dikat ist.
Attributierte Grammatiken wurden so erstmals von Knuth in [Knu68] vorgestellt, die hier verwendete Definition entstammt [WG84].
Quelltext 1 zeigt ein Beispiel zur Attributierung zweier Produktionsregeln, die Pfeilnotation (!ferror herror argumentsig) dru¨ckt aus, dass wenn die Bedingung nicht eingehalten wird, eine Fehlermeldung ausgegeben werden soll. Durch herror argumentsi werden die aufgelisteten Parameter angegeben.
In vielen Programmen zur Generierung der Attributauswertung ist das Attribut sym vordefiniert und erlaubt den Zugriff auf das lexikalische Ergebnis fu¨r ein Terminalsymbol. Eine explizite Attributierung ist dafu¨r nicht notwendig und wird von uns daher auch nicht durchgefu¨hrt.
Ist ein Modell oder ein Meta-Modell in einem UML-Klassendiagramm gegeben, kann mittels OCL die Semantik dieses Modells oder Meta-Modells angegeben werden. OCL ist eine typisierte Sprache zur Formulierung logischer Ausdru¨cke. Im folgenden werden einige Konstrukte von OCL beschrieben.
U¨ ber Context hKlassennamei inv hOptNamei : hOCL-Ausdrucki wird eine Klasseninvariante fu¨r die Klasse mit dem Namen Klassenname erzeugt. Die Invariante kann einen Namen OptName haben. Durch def h namei =hexpri wird ein Attribut oder eine Abfragefunktion mit dem Namen name erzeugt. In einem Klassendiagramm wird mittels des Punkt-Operators auf Elemente und Rollen einer Klasse und Assoziation zugegriffen, mit dem Operator -> auf Elemente als Menge oder auf Funktionen. Ausgehend von dem Kontext Klassenname kann mit diesen Operationen zu anderen Elementen des Klassendiagramms navigiert werden. In dieser Arbeit werden die folgenden Funktionen benutzt: closure(name) Es wird der transitive Abschluss u¨ber die Rolle mit dem Namen name gebildet. Das Ergebnis ist eine Menge. set->includesAll(set0) Pru¨ft ob set0
set ist. set->forAll(cjOCL Ausdruck) Fu¨r jedes Element c 2 set wird der Wahrheitswert der Auswertung des Ausdrucks OCL Ausdruck bestimmt. Ist dieser Wert fu¨r alle Elemente c ”wahr“, dann ist das Ergebnis dieses Aufrufs ebenso ”wahr“, andernfalls ”falsch“. set->excludes(c) Pru¨ft ob c 2= set ist.
Ein OCL-Ausdruck ist ein logischer Ausdruck, der (u.a.) obige Funktionen und Navigation verwenden kann, d.h. der Ausdruck self->defs.def.id->asBag() = self->defs.def.id->asSet() zur Pru¨fung eindeutiger (nicht mehrfach vorkommender) Definitionen ist ein gu¨ltiger OCL-Ausdruck. 4
Wie bereits in Abschnitt 1 erwa¨hnt, werden in vielen DSLs Bezeichner definiert und verwendet, daher abstrahieren wir nun von der konkreten Problematik – Anforderungsmodellierung in der Pumpendoma¨ne – zu Darstellungen, die nur aus Definition und Nutzung bestehen, ab. Die Abstraktion ist in Abbildung 3 in Form einer abstrakten Syntax abgebildet; hierbei ist id ein Bezeichner. Abbildung 2 (vorheriger Abschnitt) zeigt das zur abstrakten Syntax zugeho¨rige Meta-Modell.
hDescriptioni hDefinitioni hRootStati hDependencyi hDefIdi hUseIdi ::= hRootStati hDefinitioni* ::= hDefIdi hDependencyi* ::= hUseIdi ::= hUseIdi ::= id ::= id Abbildung 3 – Abstrakte Syntax zur Umsetzung der Beispiele hnti sind Nichtterminale, id bezeichnet Terminale, j die Alternative und den endlichen Abschluss Der endliche Abschluss entspricht einer Listenproduktion. Beispiel 2 zeigt die komplette Listenproduktion fu¨r hDefinitioni . hDefinitionsi
::= hDefininitionsi hDefinitioni j "
Beispiel 2 – Ersetzung des endlichen Abschluss durch Listenproduktionen fu¨r hDefinitioni In Produktionen steht die Liste X demnach fu¨r das Nichtterminal Xs und die Produktionen Xs ::= Xs X und X ::= ". In der ersten Produktion schreiben wir Xs0 fu¨r die linke Seite der Produktion, Xs1 fu¨r die rechte Seite um die Nichtterminale Xs auseinander zu halten.
Einen Ausschnitt aus der konkreten Syntax zur Anforderungsmodellierung im Pumpenumfeld stellt Abbildung 4 dar.
hRequirementi hOptlabeli hOptuidi hReqStati ! ‘rq’ label hOptuidi j ‘rq’ hOptlabeli hOptuidi ‘{’ hReqStati* ‘}’ ! label j hemptyi ! uid j hemptyi ! ‘desc’ hOptdoti text j ‘label’ hOptdoti label j ‘uid’ hOptdoti guid j ‘bug’ hOptdoti integer j ‘requires’ hOptdoti (hReferencei j hReferencesi) hReferencei hReferencesi ! guid j label ! ‘[’ hReferencei+ ‘]’ Abbildung 4 – Konkrete Syntax zur Anforderungsmodellierung (Ausschnitt), + entspricht dem nicht-leeren endlichen
Abschluss Wie bereits erwa¨hnt, wollen wir die Abha¨ngigkeiten von Anforderungen analysieren, der dafu¨r notwendige Graph sei auf Basis der abstrakten Syntax wie folgt definiert: Definition 4. Ein Quadrupel Dep , (G; DefIds; UseIds; R) mit
G , (V; E) ein gerichteter Graph mit V , DefIds [ UseIds und E DefIds der Menge der definierten Bezeichner, UseIds der Menge der benutzten Bezeichner und R der Menge der Wurzeln DefIds
UseIds, heißt Abha¨ngigkeitsgraph.
Der Abha¨ngigkeitsgraph kann unter Verwendung der abstrakten Syntax konstruiert werden. In Definition 4 entha¨lt V auch Elemente, die undefiniert sind oder nicht verwendet werden. Diese Definition entspricht der Mo¨glichkeit den Graph anhand der abstrakten Syntax aus Abbildung 3 (Abschnitt 4) zu beschreiben. Die abstrakte Syntax selbst hat nur begrenzt Aussagekraft bezu¨glich der Korrektheit des Graphen. Diese Korrektheit gilt es in einer Implementierung zu pru¨fen.
Auf der Basis des Abha¨ngigkeitsgraph ko¨nnen die Eigenschaften definiert werden, die durch die Implementierung einer DSL fu¨r die Anforderungsmodellierung bei der Pumpenentwicklung zu pru¨fen sind.
Die folgende Eigenschaft beschreibt die klassische Namensanalyse mit der zusa¨tzlichen Eigenschaft, dass die Wurzelelemente definiert sind. In der Pumpendoma¨ne gibt es nur eine ausgezeichnete Wurzel (siehe Abschnitt 1). Definition 5. Ein Abha¨ngigkeitsgraph Dep , (G; DefIds; UseIds; R) heißt vollsta¨ndig genau dann, wenn UseIds
DefIds und R
DefIds.
Notation: Ist ein Abha¨ngigkeitsgraph nach dieser Definition vollsta¨ndig und jRj = 1, nutzen wir statt der Menge R das Element r 2 DefIds als ausgezeichnetes Wurzelelement.
Ohne die grundlegende Eigenschaft der Vollsta¨ndigkeit, insbesondere dem Teil, der der Namensanalyse entspricht, ko¨nnen die anderen Eigenschaften nicht gepru¨ft werden. Die Anzahl der Wurzeln ist bereits durch die abstrakte Syntax und das Metamodell gesichert. Eine weitere Eigenschaft, die bereits in der Einleitung, wie auch in Abschnitt 2 motiviert wurde, ist dass, ausgehend von der Wurzel, jede Anforderung mindestens einmal verwendet werden muss.
Definition 6. Ein vollsta¨ndiger Abha¨ngigkeitsgraph Dep , (G; DefIds; UseIds; r) heißt gebunden genau dann, wenn fu¨r alle v 2 V ein Pfad von r nach v in G existiert.
Definition 7. Ein vollsta¨ndiger Abha¨ngigkeitsgraph Dep , (G; DefIds; UseIds; r) heißt azyklisch genau dann wenn G azyklisch ist.
Definitionen 5, 6 und 7 mu¨ssen fu¨r die Anforderungsmodellierung in der Pumpendoma¨ne erfu¨llt sein, dabei darf es nur eine ausgezeichnete Wurzel geben, da alle Anforderungen sich aus der Anforderung fu¨r Druck und Durchfluss der Pumpe ergeben. Die Azyklizita¨t dient dem Sicherstellen, dass es eine Anforderungshierarchie gibt. Ist die ”Hierarchie“ zyklisch kann keine Aufgabenfolge zur Implementierung von Abha¨ngigkeiten definiert werden, die gleichzeitig auch parallelisierbar ist. Bei Werkzeugen zur Erstellungsautomatisierung wie GNU make[SMS13] ist die Bindung von Elementen so streng wie von uns gefordert nicht notwendig, jedoch Azyklizita¨t und Vollsta¨ndigkeit[SMS13] – aus Sicht der Anforderungsmodellierung werden in einem Makefile mehrere Produkte beschrieben, sodass es mehrere Ausgangsanforderungen geben kann. Auch bei Werkzeugen zur Erstellungsautomatisierung gibt fu¨r eine Ausfu¨hrung des Werkzeugs eine ausgezeichnete Wurzel: den vom Nutzer angegebenen Parameter oder das Element all.
Wir verzichten darauf weitere Eigenschaften der Namensanalyse wie Mehrfachdeklaration und Blockschachtelung zu definieren und zu pru¨fen, da wir keine Erkenntnisse erwarten, die nicht bereits bekannt sind: mit [KW91] findet sich bereits ein Modul fu¨r die Namensanalyse im U¨bersetzerbau, ebenso existiert mit [CGQ+06] eine Bibliothek von Ausdru¨cken zur Verwendung im Modell-basierten Umfeld.
Im folgenden beschreiben wir die Umsetzung zur Pru¨fung dieser Kriterien auf Basis der gewa¨hlten Abstraktion – ohne Analyse oder Darstellung weiterer Informationen bei der Anforderungsmodellierung – anhand zweier mo¨glicher Implementierungen. Unsere Implementierungen sind zueinander kompatibel, sodass eine Umwandelung der Modelle in das entsprechende Format schnell durchfu¨hrbar ist. 4.1
Mittels OCLinEcore wurde ein Meta-Modell des Eclipse Modelling Framework (EMF) um Konsistenzpru¨fungen erweitert, analog wie es mit Kermeta in [JBF11] durchgefu¨hrt wird.
Der Vorteil von OCLinEcore besteht darin, dass einerseits mit [CGQ+06] eine Sammlung von nu¨tzlichen OCLAusdru¨cken besteht und somit der Modellierungsaufwand verringert wird und andererseits, dass OCL-Ausdru¨cke kompakt sind und damit eine Anpassung an die konkrete Struktur des Meta-Modells leichter fa¨llt. Die Pru¨fungen der Bindung und Azyklizita¨t sind in Zeile 2 bzw. 8 von Quelltext 2 aufgefu¨hrt. Die Bedingungen in den Kontexten DefId und UseId dru¨cken die Namensanalyse aus. Die Modellierung u¨ber das Metamodell aus Abbildung 2 erlaubt mit wenigen Anpassungen auch die Eingabe der Daten im XML-Austauschformat (XMI) ohne einen generierten Editor. Einfachere Metamodelle zur Anforderungsmodellierung, wie z.B. in [MS09] genutzt, erfordern das Wissen um die Indizes der Anforderungen um die Benutztung einer solchen eingeben zu ko¨nnen. Die Pru¨fung auf eine Wurzel ist nicht notwendig, da dies durch das Metamodell (2) bereits spezifiziert ist. Die genutzte OCL-Operation closure ermittelt die transitive Hu¨lle, bspw. u¨ber Rollen. Damit lo¨st diese Operation ein weiter gefasstes Problem, als dies fu¨r das Finden von Zyklen notwendig ist, allerdings ist es gleichzeitig die einzige Mo¨glichkeit dies in OCL auszudru¨cken. Der OCL-Ausdruck zum Finden von Zyklen entspricht einer Standardlo¨sung[CGQ+06]. Diese Umsetzung basiert auf OCLinEcore unter Verwendung der modernen Pivot-Implementierung von OCL, da hier zuerst die closure-Operation zur Verfu¨gung stand. Ohne diese Operation muss die zu pru¨fende Menge manuell, u¨ber Mengenvereinigung und Navigation aufgebaut werden. Andere Implementierungen wurden von uns im Rahmen dieser Arbeit nicht betrachtet.
Die Anzahl der Zeilen der OCLinEcore-Variante betra¨gt 45 Zeilen, wobei circa 20 Zeilen auf die Definition des Metamodells und der darin verwendeten Rollen und Multiplizita¨ten entfallen.
Quelltext 3 zeigt die detaillierte Attributierung zum Aufbau des Abha¨ngigkeitsgraph, die Namensanalyse und den Aufruf der semantischen Funktion zur Feststellung der Azyklizita¨t und Gebundenheit (letzten 4 Zeilen von Quelltext 3). Durch die Verwendung der Attribute defs und env ist es uns mo¨glich Benutzung vor Definition zu erlauben, sodass ein Bezeichner vor der Definition in der Beschreibung verwendet werden kann. Wir verwenden zur Implementierung das Werkzeug eli (siehe u.a. [GLH+92]), welches geordnete Attributgrammatiken[Kas80] bereit stellt. Wir ko¨nnen in der Implementierung angeben, ob bei einem Fehler die Attributauswertung abbrechen soll. Da in Quelltext 3 viele Details nicht notwendig sind und viele Werkzeuge zur Generierung der Attributauswertung Erweiterungen bieten, nutzen wir folgende Definition aus, um die Attributierung zu vereinfachen.
Definition 8. Fu¨r eine attributierte Grammatik AG , (G; A; R; B) mit abstrakter Syntax G , (T; N; P; Z) und einer Liste X existieren folgende typische Muster : Durchreichen von Attributen Sei Y::= u X v eine Produktion aus P , u; v 2 (N [ T ) . Die Attributierungsregel X.a f (: : :) eines Attributes a 2 A steht dann fu¨r 1 rule Y ::= u Xs v 2 attr Xs.a f(: : :) und Quelltext 3 – Attributierung zum Aufbau des Abha¨ngigkeitsgraphen mit Namensanalyse und Pru¨fung des Graphen u¨ber die Bedingungen in Zeilen 50 bis 53 Kettenberechnungen ([GLH+92]) chain a for X steht fu¨r die Attributierungsregeln des Attributs a mit 1 rule Xs ::= Xs X 2 attr Xs1.aIn Xs0.aIn 3 X.aIn Xs1.aOut 4 Xs0.aOut X.aOut 5 rule Xs ::= " 6 attr Xs.aOut XsaIn aIn
Xs
aOut aIn
Xs aOut aIn
X
aOut Contributions (u.a. [Hed11]) Contributions5 erweitern Kettenberechnungen um die Initialisierung von aIn und die Berechnung von X.aOut, wenn mengenwertige Attribute (bzw. Listen) berechnet werden; dabei steht contribution a for X. b fu¨r 1 chain b for X 2 3 rule Y ::= u X v 4 attr Xs.bIn ; 5 6 rule X ::= u 7 attr X.bOut
X.bIn [ f X.a g wobei die erste Regel fu¨r alle Produktionen mit X gilt, und die zweite Regel fu¨r Produktionen mit linker Seite X steht.
Die Definition fu¨r typische Muster nutzt rein syntaktische Ersetzungsregeln, eine Erweiterung der Semantik von Attributgrammtiken ist nicht notwendig.
Unter Verwendung der typischen Muster (Definition 8) ergibt sich Quelltext 4 fu¨r die Attributberechnungen aus Quelltext 3. Weitere Reduzierungen lassen sich in der Implementierung unter Ausnutzung anderer Erweiterungen attributierter Grammatiken, wie z.B. Vererbungsmechanismen, erreichen. Quelltext 4 zeigt, wie mit Attributgrammatiken der vollsta¨ndige Abha¨ngigkeitsgraph aus Definitionen 4 und 5 aufgebaut wird. Dabei pru¨fen wieder die letzten 4 Zeilen auf Gebundenheit und Azyklizita¨t. Die Menge UseIds (Definition 5) kann aus der Kantenmenge bestimmt werden.
Wird zur Pru¨fung der Bindung eine klassische Implementierung u¨ber Referenzza¨hlung genutzt, dann kann es zu ungenauer Fehlerausgabe und falsch-positiven Ergebnissen kommen. Zur Problemveranschaulichung sei folgende Variante als Alternative angenommen: Statt in Quelltext 4 Kanten zu erzeugen werden in der Menge der definierten Bezeichner zusa¨tzlich gespeichert ob ein Bezeichner verwendet wurde. Nicht-gebundene Bezeichner sind dann jene, die nicht in dieser Menge als ”benutzt“ markiert sind. Die Markierung und Abfrage der Markierung erfolgt u¨ber SetUsed und IsUnused. Der entsprechende Ausschnitt ko¨nnte damit wie in Quelltext 5 aussehen. 5engl. Beitrag 1 chain defs for Dependency 2 rule Definition ::= DefId Dependency 3 attr Dependency.defsIn Definition.defsIn 4 Definition.defsOut Dependency.defsOut 5 6 rule UseId ::= id 7 attr UseId.defsOut SetUsed(UseId.defsIn, UseId.sym) 8 9 rule Description ::= Statements 10 attr Description.unused f x 2 Statements.defs : IsUnused(x)g 11 cond Description.unused = ; ! 12 ferror "U N U S E D S Y M B O L S" Description.unused g
Quelltext 5 – Umsetzung u¨ber Referenzza¨hlung mit Seiteneffekt auf der Definitionstabelle ”defs“
einzige Wurzel B
C
D
F
E G
H J
I Abbildung 5 – Nicht-gebundene Elemente bei Verwendung von Referenzza¨hlung
unerkannt durch gestrichelte Kante G ! H; Wurzel = oval, gestrichelt Bei dieser Implementierung muss dann jedoch das Kettenattribut defs auch ein Kettenattribut fu¨r Dependency sein. Die Folge solch einer Implementierung la¨sst sich gut durch Abbildung 5 veranschaulichen: Aufgrund der Implementierung aus Quelltext 5 sind alle Knoten gebunden, jedoch nicht an die Wurzel. Die Implementierung wu¨rde hier also ein falsch-positives Ergebnis im Sinne von Definition 6 bestimmen. Wird die Kante G ! H entfernt, so wa¨re nur das Element H als ungebunden markiert, jedoch sind auch die Elemente E; F; G; H; I; J nicht an die Wurzel gebunden. Letztlich bleibt noch die Alternative direkt in der Attributgrammatik die Tiefensuche anzugeben und auf Basis der aktuell gebundenen Bezeichner die benutzten Bezeichner zu markieren und zu den noch zu betrachtenden hinzuzufu¨gen. Dieser Ansatz ist mit geordneten Attributgrammatiken nicht mo¨glich, auch wird beim Erlauben von Zyklen in vielen Werkzeugen gefordert, dass es einen Fixpunkt gibt, der mittels Fixpunktiteration gefunden werden kann.
Da Graphen nicht nur im U¨bersetzerbau (siehe dazu u.a. Abschnitt 1) eine ha¨ufig einsetzbare Abstraktion bilden, existieren bereits sehr viele Bibliotheken zur Darstellung und Analyse von Graphen. Wir arbeiten momentan daran, auf Basis der Boost Graphbibliothek[SLL02], die Funktionen acyclic, bound, cyclesOf und unboundOf mit Einstellungen zu Abbruchkriterien und Fehlerausgabe fu¨r eli zur Verwendung mit Attributgrammatiken zur o¨ffentlichen Verfu¨gung zu stellen.
Das Werkzeug um die Attributberechnungen durchzufu¨hren und fu¨r das wir die genannten Funktionen zur Verfu¨gung stellen wollen ist eli[GLH+92]. Die Spezifikation zur Umsetzung in eli ohne Hilfsfunktionen zum Bibliotheksaufruf besteht aus 124 Zeilen, wovon 18 Zeilen auf die Weitergabe von Kommandozeilenoptionen entfallen. 40 Zeilen entfallen auf die reine Namensanalyse, sowie weitere 22 Zeilen, welche Quelltext 4 entsprechen.
Anhand von Beispiel 1 zeigen wir in Abschnitt 5.1 die Fehlerausgabe durch die beiden Umsetzungen, zuvor betrachten wir jedoch die Laufzeiten der Implementierungen. Das Testsystem ist ein Sabayon Linux mit Kernel Version 3.11. Das System hat eine Intel Core i7-3770 CPU und verfu¨gt u¨ber 16 GiB Arbeitsspeicher. Die Reallaufzeiten wurden unter Verwendung von GNU Time 1.17 ermittelt. Java ist in Version 1.7.0u45 vorhanden.
Durch einen Testgenerator wurden fu¨r beide Implementierungen der abstrakten Syntax aus Abschnitt 4 entsprechende Eingaben erstellt. Da Graphprobleme behandelt werden, stellt dieser Testgenerator einige Optionen zur Verfu¨gung, die sich in Tabelle 1 wiederfinden. Die Spalte ”zyklisch“ bezeichnet, dass zyklische Graphen generiert werden sollen. Mittels der Option ”Tot“ wird die Prozentzahl der nicht-erreichbaren Knoten des Graphen festgelegt – die eigentliche Anzahl an Knoten mittels ”Knoten“. Mit der Option ”Dichte“ wird, nach Abzug der toten Knoten, festgelegt, wieviele Prozent der maximal noch mo¨glichen Kanten (einem vollsta¨ndigen Graphen entsprechend) zu erzeugen sind. Die Eigenschaft ”Knoten“ bestimmt die definierten Bezeichner, die anderen Eigenschaften deren Benutzung. Der Testgenerator erzeugt keine Dokumente in denen undefinierte Bezeichner verwendet werden. Zur besseren Vergleichbarkeit wurde die Laufzeit zur Pru¨fung der Definition 6 getrennt aufgeschlu¨sselt, dabei sind Ein- und Ausgabe, Programmstart sowie ggf. Graphaufbau mit einbezogen. Ebenfalls getrennt aufgeschlu¨sselt (Spalte ”Parse“) wurden die Zeiten, die beno¨tigt werden um ein Dokument einzulesen, ohne Ausgabe zu erzeugen oder die Semantik zu analysieren. Die Beschreibungen fu¨r Verwendung mit der OCL-Variante sind, aufgrund des zugrunde-liegenden XML-Formats, ho¨chstens 40% gro¨ßer als die entsprechenden Dokumente fu¨r die eli-Variante. Ecore bezieht sich in Spalte ”Parse“ auf die der OCL-Variante zugrunde liegenden Technologie. ”OEcore“ bezeichnet die Laufzeiten fu¨r die Eingabe und das Analysieren mittels OCL. Die Spalten Gesamt beziehen sich hingegen auf die Gesamtlaufzeit der Programme und enthalten auch die Analyse aller Definitionen aus Abschnitt 4. Zur Ermittlung der aufgefu¨hrten Zeitwerte wurden je Knotenzahl und Zeitwert 1000 Versuche durchgefu¨hrt und das arithmetische Mittel der Laufzeit bestimmt. Dauerte ein einzelner Versuch la¨nger als 10 Minuten wurde dieser abgebrochen und neu gestartet. Gab es zehn aufeinanderfolgende Versuche mit jeweils mehr als 10 Minuten Laufzeit wurde der Versuchslauf abgebrochen – in Tabelle 1 sind diese Versuchsla¨ufe fett markiert. Ebenfalls markiert mit ; sind die Werte, in denen die OCL-Variante kein Ergebnis liefern kann, da ein Stapelu¨berlauf auftritt. Bemerkung 1. Die Ursache fu¨r den Speicheru¨berlauf sind die Standardeinstellungen der Java VM. Erst eine Vervierfachung des zula¨ssigen Speicher sorgt dafu¨r, dass fu¨r die markierten Beispiele Ergebnisse durch OCLinEcore geliefert werden ko¨nnen. Jedoch sollte es der Java VM mo¨glich sein bei ca. 14 GiB freiem Speicher automatisch mehr zu nutzen. Weiterhin ist die closure Operation unter Verwendung von Introspektion und Rekursion so implementiert, dass selbst ein aggressiver U¨ bersetzer keine Optimierung durchfu¨hren kann. Wird der erlaubte Speicher vergro¨ßert, dann kann OCL, aufgrund des fehlerhaften Modells, fru¨hzeitig abbrechen. Dieses Verhalten ergibt sich aus der Kurzauswertung logischer Ausdru¨cke. Kann OCL jedoch nicht fru¨hzeitig abbrechen, d.h. das Modell ist korrekt, ist die Laufzeit von OCL verglichen mit der eli-Variante um Gro¨ßenordnungen schlechter. Da wir die Laufzeit und nicht den Speicherverbrauch betrachten, wurden keine ausfu¨hrlichen Tests mit anderen Speichereinstellungen der Java VM durchgefu¨hrt. Die Spru¨nge bei den Laufzeiten (Zeilen 8 bis 10 der 6Aus Zeitgru¨nden konnten zur Bestimmung diesen Eintrags bisher nur zehn Testla¨ufe durchgefu¨hrt werden. Tabelle) fu¨r die eli-Variante ergeben sich aus der umfangreicheren Ausgabeerzeugung fu¨r zyklische Komponenten. Bei den reinen Zeiten fu¨r die reine Syntaxanalyse ergibt sich, dass die Initialisierung von Java zusa¨tzlich Zeit beno¨tigt. Die Spru¨nge der Parsezeiten bei nahezu gleichen an den Testgenerator u¨bergebenen Eigenschaften ergibt sich aufgrund der unterschiedlichen Hierarchie, die durch den Testgenerator (zufallsbasiert) erstellt wird: la¨ngere Laufzeiten bedeuten eine flachere Hierarchie, aber einen breiteren abstrakten Syntaxbaum, d.h. mehr Kanten pro Knoten.
Die Anzahl der Anforderungen fu¨r die Beispiele wurde der ta¨glichen Praxis entnommen. Bei ersten Umwandelungen in unser Format hat die Anforderungshierarchie eine Dichte im einstelligen Prozentbereich, sodass die von uns gewa¨hlten Beispiel durchaus realistisch sind.
Bemerkung 2. Eine Laufzeitanalyse fu¨r eine Variante mit XText haben wir nicht durchgefu¨hrt. Nach unserem Eindruck hat XText Probleme mit der Verwendung von Zeichenketten, sodass Laufzeit und Speicherverbrauch ungeeignet fu¨r große Beispiele sind. Zeichenketten kommen jedoch gerade bei der Anforderungsmodellierung, in Form von Anforderungsbeschreibungen, Verantwortlichkeiten oder bei Angaben zur Dokumentenerzeugung, ha¨ufig vor.
Quelltext 6 zeigt die Ausgabe der eli-generierten Anwendung fu¨r Beispiel 1. Es ist klar zu erkennen, welche Elemente und Kanten einen Zyklus ausmachen und wo diese im Quelltext vorkommen, sowie welche Elemente nicht erreichbar (Zeilen 16; 17) sind.
Quelltext 6 – Fehlerausgabe (eli-Variante) fu¨r Pumpenbeispiel aus Abschnitt 2 1 ERROR: Diagnosis of DescriptionImpl@32b9bd47ffile:pump.xml#/g 2 ERROR: The ’bound’ constraint is violated on 3 ’DescriptionImpl@32b9bd47ffile:pump.xml#/g’ 4 ERROR: The ’acyclic’ constraint is violated on 5 ’DescriptionImpl@32b9bd47ffile:pump.xml#/g’
Quelltext 7 – Fehlerausgabe (OCL-Variante) fu¨r Pumpenbeispiel aus Abschnitt 2 Demgegenu¨ber steht die Ausgabe durch die Variante, die OCL zur Pru¨fung nutzt. Die Ausgabe der OCL-Variante ist in Quelltext 7 zu sehen. Quelltext 8 zeigt die Fehlerausgabe einer alternativen Umsetzung der OCL-Invariante zur Pru¨fung auf Zyklen. Die A¨ nderung besteht darin diese Invariante (ohne forAll) in den Kontext des Elements zu schieben. Der Nachteil an dieser Invariante ist, dass die Laufzeit der OCL-Variante dadurch weiter erho¨ht wird: die Laufzeit zur Pru¨fung auf Azyklizita¨t in Tabellenzeile 3 braucht statt der angegebenen die doppelte Zeit, die vorletzte Zeile circa 30 Minuten zum Finden der zyklischen Komponente wenn erho¨hter Speicherverbrauch eingestellt wurde. 1 ERROR: Diagnosis of DescriptionImpl@4d3b6cf3ffile:pump.xml#/g 2 ERROR: The ’bound’ constraint is violated on 3 ’DescriptionImpl@4d3b6cf3ffile:pump.xml#/g’ 4 ERROR: The ’bound’ constraint is violated on 5 ’DefinitionImpl@7c7686f8ffile:pump.xml#//@defs.1g’ 6 ERROR: The ’acyclic’ constraint is violated on 7 ’DefinitionImpl@4997439effile:pump.xml#//@defs.2g’ 8 ERROR: The ’acyclic’ constraint is violated on 9 ’DefinitionImpl@69d85fd0ffile:pump.xml#//@defs.3g
Quelltext 8 – Erweiterte Fehlerausgabe (OCL-Variante) fu¨r Pumpenbeispiel aus Abschnitt 2 Wie anhand der Quelltexte 6,7 und 8 erkannt werden kann, ist es in der eli-generierten Variante selbst bei großen Zyklen mo¨glich die Elemente eines Zyklus zu finden, wohingegen die OCL-Varianten nicht einmal eine Kante angeben kann, die bei Entfernung den Zyklus aufheben wu¨rde; bei Nutzung eines generierten Editors wu¨rden die Fehlermeldungen statt z.B. @defs.1 den Bezeichner enthalten.
Wie am Ende von Abschnitt 4.2 beschrieben, lassen sich die zur Pru¨fung und Fehlerausgabe genutzten Funktionen in der eli-Variante parametrisieren, sodass detaillierte Fehlerausgabe, umfangreichere Fehlerausgabe oder schneller Abbruch ermo¨glicht werden. Die reine Bestimmung ob Zyklen vorhanden sind, ist schnell erledigt – selbst fu¨r sehr große Beispiele (> 5000 definierte Elemente mit einer Dichte von 10%) in weniger als anderthalb Sekunden. Sollen dagegen alle Zyklen mit allen dazugeho¨rigen Pfaden ausgegeben werden, so entspricht dies der Ausgabe aller Zusammenhangskomponenten. Die mo¨glichen Parameter kann der Endanwender dem U¨ bersetzer u¨bergeben. 6
Zur Analyse von Anforderungen und deren Umsetzung mittels Doma¨nen-spezifischer Sprachen gibt es eine Reihe von Arbeiten und Werkzeugen, einen etwas a¨lteren U¨ berblick u¨ber die offenen Probleme der Anforderungsanalyse gibt [NE00]. Viele Arbeiten im Bereich der Anforderungsanalyse mittels Doma¨nen-spezifischer Sprachen, wie [DCS+13, GKvdB10], beschreiben nur dass und ggf. wie eine Sprache umgesetzt wurde, selten wird auf die Pru¨fung der Semantik der Sprache eingegangen, wie wir es hier getan haben. Keine der uns bekannten Arbeiten der Anforderungsanalyse bietet in diesem Rahmen einen Laufzeitvergleich an. Vielmehr sind Umfang der Beschreibungen (im Sinne von Modellinstanz) und die umgesetzten Analysen von Interesse, so auch bei [T A˚J12], einer Arbeit, die zeigt wie (ersetzbare) Referenzattributgrammatiken genutzt wurden um ein bestehendes System auf Basis von Attributgrammatiken zu ersetzen.
Referenzattributgrammatiken (RAGs) wurden unter diesem Namen erstmals in [Hed00] beschrieben, jedoch reicht unserer Ansicht nach die Motivation in [Hed00] nicht aus, da fu¨r die gewa¨hlten Beispiele an Problemen mit reinen Attributgrammatiken eine Definitionstabelle ausreichend ist. In [Hed00] kommt zur Pru¨fung der Typhierarchie von PicoJava, einer Teilmenge der Java-Sprache, unter Verwendung von Attributgrammatiken dieselbe Pru¨fung zum Einsatz, wie wir sie in OCL genutzt haben (siehe Quelltext 2, Zeile 2). Eine Erweiterung von RAGs, ersetzbare Referenzattributgrammatiken, wurden alternativ zu der von uns genutzten Variante, die auf[Gro09] basiert, in [T A˚J12] benutzt um die Semantik von Modellen spezifizieren zu ko¨nnen. Das Hauptaugenmerk von [T A˚J12] ist nicht Laufzeit sondern Umfang der Implementierung – der Umfang des Quelltext wurde von der per Hand geschriebenen Variante um 75% reduziert. Die wenigen Aussagen, die [T A˚J12] zur Laufzeit trifft deuten an, dass, trotz verla¨ngerter U¨ bersetzungsdauer und langsamerer Namensanalyse, der erzeugte Interpreter inetwa gleich schnell wie die urspru¨ngliche (handgeschriebene) Variante ist. Ersetzbare Referenzattributgrammatiken (ReRag) wurden u.a. in [EH04] vorgestellt und dort in einem Vergleich der Laufzeiten eines Werkzeugs zur Pru¨fung der statischen Semantik von Java 1.4 mit der Laufzeit des Java U¨ bersetzers verglichen: die Laufzeit unter Verwendung von ReRAG war anna¨hernd 4 mal ho¨her als die des Java U¨bersetzers. Die eben genannten Arbeiten ordnen wir, trotz Einbettung in die Meta-Modellierung, dem U¨ bersetzerbau zu.
JastAdd (siehe u.a. [Hed11]) ist ein weiteres Werkzeug zur Generierung von Programmen aus Attributgrammtiken. Die in [Hed11] als Contributions bezeichnete Technik la¨sst sich mit Hilfe weniger Bibliotheksfunktionen auch in eli ausdru¨cken. In [JBF11] wird gezeigt, dass die Semantik von Meta-Modellen, bzw. statische Analysen, unter Verwendung von OCL umgesetzt werden ko¨nnen. Die Arbeit selbst beschreibt das Werkzeug ”Kermeta“, das, analog zu eli[GLH+92], eine Verbindung mehrerer Technologien bereitstellt und diese zur vereinfachten Sprachentwicklung verknu¨pft. Auch [JBF11] bietet keine Laufzeiten zum Vergleich an. [HJK+11] zeigt, wie OCL auch in der beschriebenen DSL genutzt werden kann, jedoch gehen diese Arbeiten nicht auf die maschinelle Pru¨fung der so beschriebenen Semantik ein.
Einen U¨berblick u¨ber OCL entha¨lt [Pan11], in dem auch beschrieben wird, dass OCL zur Pru¨fung der Semantik von Sprachen sowie Modelltransformationen genutzt wird. 7
Die Mo¨glichkeit Beschreibungen und Programme in Form von Graphen darzustellen und diese zu transformieren ist im Rahmen des U¨ bersetzerbaus bekannt. Zur Beschreibung der statischen Semantik von DSLs kann OCL zwar genutzt werden, doch lassen sich mit den Methoden des U¨ bersetzerbaus Programme generieren, die nicht nur um 3-4 Gro¨ßenordnungen performanter sind, sondern ebenso eine bessere Fehlerdiagnose bereitstellen. Zwar zeigen [JBF11, KER99] die Mo¨glichkeit OCL zur Definition der statischen Semantik von Sprachen zu nutzen. Dennoch ist im Modell-basierten Umfeld die Spezifikation der Semantik einer Sprache noch eine offene Fragestellung [FR07, SGBvB12]. Unsere Erkenntnisse zeigen, dass Attributgrammatiken ein geeigneter Formalismus im Modell-basierten Umfeld sein kann.
Wie bereits [SSF+07], bei der exemplarisch eine Doma¨nen-spezifische Sprache unter Verwendung von OCL und manueller Transformation in Attributgrammatiken erstellt wurde, motiviert auch unsere Arbeit die Implementierung der automatischen Transformation von OCL-Ausdru¨cken in schnelle Attributgrammatiken. Wenngleich sich mit wenig Einarbeitungszeit erste Doma¨nen-spezifische Sprachen im Modell-basierten Umfeld erstellen lassen, so ist die Performance dieser nach unseren Erkenntnissen ungeeignet um die modell-basierte Organisation[CFK+13] zu unterstu¨tzen. Trotz des ho¨heren Abstraktionsniveau von OCL kann unter Verwendung von Hilfsfunktionen und Mustern auch bei Attributgrammatiken ein nahezu vergleichbares Abstraktiosniveau erreicht werden. Auch bei OCL ha¨ngt das Abstraktionsniveau stark von Bibliotheken und vordefinierten Funkionen ab. Auch mit Attributgrammatiken lassen sich kurze Spezifikationen erstellen, durch die Erweiterungen kann das Versta¨ndnis sogar noch gesteigert werden. UUAG[VSM12] stellt Attributgrammatiken in Haskell zur Verfu¨gung, sodass auch bei den semantischen Funktionen selbst ein ho¨herer Abstraktionsgrad gewonnen werden kann. Eine ausfu¨hrliche Betrachtung der Erweiterungen und Implementierungsformen von Attributgrammatiken war jedoch nicht Gegenstand dieser Arbeit.
Die von uns gewa¨hlten Beispiele sind zwar durch einen Generator erstellt, doch sind die Einstellungen dieses Generators so gewa¨hlt, dass dieser realita¨tsnahe Dokumente erzeugt. Aus Sicht eines Endanwenders ist es irrelevant, ob OCL oder Attributgrammatiken genutzt wurden um die Sprache zu implementieren, Geschwindigkeit und Fehlerausgabe sind von Relevanz. Einer Sprachentwicklung durch Doma¨nen-Experten stehen wir aus Sicht des U¨ bersetzerbaus kritisch gegenu¨ber. Unserer Ansicht nach mu¨ssen Sprach-Experte und Doma¨nen-Experte gemeinsam an der Entwicklung einer DSL beteiligt sein.
Bemerkung 3. Beide Autoren haben an der Implementierung einer industriellen DSL, Hart-DD, mitgewirkt. Die Sprache wurde nahezu ausschließlich durch Doma¨nen-Experten spezifiziert. Hierbei zeigte sich einerseits, dass Sprachdefinitionen bei steigendem Umfang mehrdeutig wurden. Andererseits wurden Konstrukte eingefu¨hrt, die Definitionen (von Bezeichnern) in anderen Namensra¨umen so beeinflussen konnten, dass die Definition selbst ersetzt wurde (LIKE und IMPORT).
Nicht nur in den Eingangs erwa¨hnten Sprachen werden Bezeichner definiert und benutzt, auch in [DR07], einer Sprache zur Beschreibung eingebetteter Steuerungen in Echtzeit-Systemen, ist dies der Fall. Gleiches gilt auch fu¨r SysML, einer in der Automobilindustrie verwendeten Modellierungssprache (siehe u.a. [AP10]). Unsere Betrachtung hat also in sehr vielen Sprachen Relevanz, wenngleich die Wichtigkeit der Informationen unterschiedlichen Grad haben. Es liegt in der Natur der unterschiedlichen Doma¨nen, dass unterschiedliche Eigenschaften bei der Modellierung wichtig sind – Zyklen sind nicht immer ein Fehler, Gebundenheit ist je nach Sprache nur zur Optimierung notwendig. Wenngleich es mehr als eine OCL-Implementierung gibt, so war es nicht unser Anliegen diese unterschiedlichen Implementierungen untereinander zu vergleichen, sondern fu¨r ausgewa¨hlte Probleme OCL und Attributgrammatiken gegenu¨ber zu stellen. Wie sich die Implementierungen fu¨r eine Variante zur Semantik-Spezifikation – OCL oder Attributgrammatiken – untereinander verhalten, ist eine noch offene Fragestellung.
Im Umfeld von Eclipse existieren bereits eine Reihe von Technologien zur Generierung von Editoren und Visualisierungen, dies ist erst in Ansa¨tzen fu¨r bewa¨hrte Werkzeuge des U¨ bersetzerbaus vorhanden[SK03]. An dieser Stelle existieren allerdings auch noch weitere Strategien oder andere Arten von Editoren, die nur zum Teil eine Umsetzung in aktuellen Technologien haben.
Im Modell-basierten Umfeld werden nicht selten im generierten Code Anpassungen vorgenommen. Die Nutzung von Bibliotheken funktioniert entweder u¨ber direkte Anpassungen des generierten Quelltext oder u¨ber direkte Nutzung generierter Klassen (z.B. Vererbung). Diese Vorgehensweise ist problematisch, weil diese manuellen Anpassungen verloren gehen, wenn der Code neu generiert wird. Auch das direkte Nutzen oder Erben generierter Klassen lo¨st dieses Problem nicht, da durch A¨ nderungen im Modell sich die Klassenstruktur vera¨ndern kann. U¨ bersetzerbauwerkzeuge zeigen hier eine andere Mo¨glichkeit, um Bibliotheksaufrufe oder Quellcode in den generierten Code einzubinden: die DSL erlaubt auch die Einbeziehung von Codefragmenten (inkl. Funktionsaufrufen) in die Modelle.
Die in dieser Arbeit gewonnenen Erkenntnisse bieten Ansatzpunkte, um umfangreiche Doma¨nen-spezifsche Sprachen, im Gegensatz zu Mini-Sprachen, im Modell-basierten Umfeld entwickeln zu ko¨nnen. Außerdem ero¨ffnet die Nutzung von U¨ bersetzerbauwerkzeugen fu¨r DSLs auch neue Mo¨glichkeiten zur Definition der statischen Semantik dieser. Damit ko¨nnen mehr Konsistenzbedingungen effizient u¨berpru¨ft werden als dies mit OCL mo¨glich wa¨re. Desweitern ko¨nnen Methoden der Programmanalyse auf DSLs u¨bertragen werden, um beispielsweise Ru¨ckverfolgbarkeit auch u¨ber verschiedene Entwicklungsphasen von der Anforderungsanalyse bis hin zur Implementierung, zu realisieren. Die durch uns gewonnenen Ergebnisse motivieren die automatische Generierung von effizienten Attributgrammatiken aus OCL-Bedingungen zu implementieren.
Wir danken unseren Projektpartnern fu¨r die gute Zusammenarbeit und die Bereitstellung umfangreicher Beispiele aus dem aktuellen Arbeitsalltag. Weiterhin danken wir dem Projekttra¨ger VDI/VDE-IT und dem BMBF, die diese Arbeit im Rahmen des Projekts ELSY (Nr. 16M3202D) betreuen und fo¨rdern. Den anonymen Reviewern danken wir fu¨r Anmerkungen, Kritik und nu¨tzliche Hinweise.
[ALSU06] Alfred V. Aho, Monica S. Lam, Ravi Sethi und Jeffrey D. Ullman. Compilers: Principles, Techniques, and Tools.
Addison Wesley, 2. ausgabe. Auflage, September 2006.
Eric Andrianarison und Jean-Denis Piques. SysML for embedded automotive Systems: a practical approach. In Conf. on Embedded Real Time Software and Systems, 2010. [BKWA11] Christoff Bu¨rger, Sven Karol, Christian Wende und Uwe Aßmann. Reference Attribute Grammars for Metamodel Semantics. In Brian Malloy, Steffen Staab und Mark Brand, Hrsg., Software Language Engineering, Band 6563 der Reihe Lecture Notes in Computer Science, Seiten 22–41. Springer, 2011. [CFK+13] Tony Clark, Ulrich Frank, Vinay Kulkarni, Balbir Barn und Dan Turk. Domain specific languages for the model driven organization. In Proceedings of the First Workshop on the Globalization of Domain Specific Languages, GlobalDSL ’13, Seiten 22–27. ACM, 2013. [CGQ+06] Dolors Costal, Cristina Go´mez, Anna Queralt, Ruth Ravento´s und Ernest Teniente. Facilitating the definition of general constraints in UML. In Model Driven Engineering Languages and Systems, Seiten 260–274. Springer, 2006.
Tony Clark, Paul Sammut und James Willans. Applied metamodelling: a foundation for language driven development., 2008. [DCS+13] Diego Dermeval, Jaelson Castro, Carla Silva, Joa˜o Pimentel, Ig Ibert Bittencourt, Patrick Brito, Endhe Elias, Thyago Teno´rio und Alan Pedro. On the Use of Metamodeling for Relating Requirements and Architectural Design Decisions. In Proceedings of the 28th Annual ACM Symposium on Applied Computing, SAC ’13, Seiten 1278–1283. ACM, 2013. Tom DeMarco und Tim Lister. Programmer Performance and the Effects of the Workplace. In Proceedings of the 8th International Conference on Software Engineering, ICSE ’85, Seiten 268–272. IEEE, 1985.
Gwenae¨l Delaval und E´ ric Rutten. A domain-specific language for multitask systems, applying discrete controller
synthesis. EURASIP
Torbjo¨ rn Ekman und Go¨ rel Hedin. Rewritable Reference Attributed Grammars. In Martin Odersky, Hrsg., ECOOP 2004 – Object-Oriented Programming, Band 3086 der Reihe Lecture Notes in Computer Science, Seiten 147–171. Springer, 2004.
Robert France und Bernhard Rumpe. Model-driven Development of Complex Software: A Research Roadmap.
In 2007 Future of Software Engineering, FOSE ’07, Seiten 37–54. IEEE, 2007. [GKvdB10] Arda Goknil, Ivan Kurtev und Klaas van den Berg. Tool Support for Generation and Validation of Traces Between Requirements and Architecture. In Proceedings of the 6th ECMFA Traceability Workshop, ECMFA-TW ’10, Seiten 39–46. ACM, 2010. [DL85]
Anneke G. Kleppe, Jos Warmer und Wim Bast. The model driven architecture: practice and promise, 2003. Richard C. Gronback. Eclipse modeling project: a domain-specific language (DSL) toolkit, 2009.
Go¨ rel Hedin. Reference attributed grammars. Informatica (Slovenia), 24(3):301–317, 2000.
Go¨ rel Hedin. An introductory tutorial on JastAdd attribute grammars. In Generative and Transformational Techniques in Software Engineering III, Seiten 166–200. Springer, 2011.
Florian Heidenreich, Jendrik Johannes, Sven Karol, Mirko Seifert, Michael Thiele, Christian Wende und Claas Wilke. Integrating OCL and Textual Modelling Languages. In Juergen Dingel und Arnor Solberg, Hrsg., Models in Software Engineering, Band 6627 der Reihe Lecture Notes in Computer Science, Seiten 349–363. Springer, 2011.
Jean-Marc Je´ze´quel, Olivier Barais und Franck Fleurey. Model driven language engineering with kermeta. In Generative and Transformational Techniques in Software Engineering III, Seiten 201–221. Springer, 2011. Uwe Kastens. Ordered attributed grammars. Acta Informatica, 13(3):229–256, 1980.
Stuart Kent, Andy Evans und Bernhard Rumpe. UML Semantics FAQ. In Ana Moreira, Hrsg., Object-Oriented Technology ECOOP‘99 Workshop Reader, Band 1743 der Reihe Lecture Notes in Computer Science, Seiten 33–56. Springer, 1999.
Donald E. Knuth. Semantics of context-free languages. Mathematical systems theory, 2(2):127–145, 1968. Juha Kuusela und Juha Savolainen. Requirements Engineering for Product Families. In Proceedings of the 22Nd International Conference on Software Engineering, ICSE ’00, Seiten 61–69. ACM, 2000.
Uwe. Kastens und William M. Waite. An abstract data type for name analysis. Acta Informatica, 28(6):539–558, 1991.
Marjan Mernik, Jan Heering und Anthony M. Sloane. When and how to develop domain-specific languages. ACM Comput. Surv., 37(4):316–344, Dezember 2005.
Niklas Mellega˚rd und Miroslaw Staron. A domain specific modelling language for specifying and visualizing requirements. In The First International Workshop on Domain Engineering, DE@ CAiSE, Amsterdam, 2009. Bashar Nuseibeh und Steve Easterbrook. Requirements Engineering: A Roadmap. In Proceedings of the Conference on The Future of Software Engineering, ICSE ’00, Seiten 35–46. ACM, 2000.
Manfred Oesterle und Fred Leidig, Hrsg. Methodisch sichere, schnelle Produktionsanla¨ufe in der Mechatronik (2M00E7S.SPRO) - Band 2 der Reihe ”Schneller Produktionsanlauf in der Wertscho¨pfungskette“. VDMA-Verlag, R. K. Pandey. Object constraint language (OCL): past, present and future. SIGSOFT Softw. Eng. Notes, 36(1):1–4, Januar 2011.
Helmut A. Partsch. Requirements Engineering systematisch. Springer, 2010. [SMS13] [SSF+07]