A model-driven framework for domain specific languagesdemonstrated on a test automation language

Thesis byMartin Karlsch, 711330

In Partial Fulfillment of the Requirementsfor the Degree of

Master of Science in Software Systems Engineering

SupervisorsProf. Dr. Andreas Polze (HPI)Dr. Martin von Löwis (HPI)

Dr. Klaus Ries (BMW Group)Dipl.-Inf. Markus Hillebrand (BMW Group)

Hasso-Plattner-Institute of Software Systems EngineeringPotsdam, Germany

January 12, 2007(Submitted March 7, 2007)

ii

c© January 12, 2007Martin Karlsch, 711330

All Rights Reserved

iii

Abstract

Innovation in today’s automotive industry is largely based on electronics and software. Toget a competitive edge a company has to deliver new features steadily. This trend is boostedby a decreasing technology life cycle. The result is an exponential growth of software in-side a car. As quality plays a critical role software and hardware have to be tested properly,manual testing is not practicable anymore. At the BMW Group a framework for test au-tomation has been developed including a Microsoft Excel based test specification language.The language and its implementation approach offer various places for improvement, how-ever due to the chosen technology the emendation possibilities are limited. Therefore thedevelopment of a new domain specific language (DSL) was decided.

However, the development of a new DSL is a difficult task at the moment. The devel-oper needs expertise in the field of language development which involves design, lexicalanalysis, parser and compiler construction, implementation of a suited runtime and mostimportantly knowledge of the concepts within the specific domain. A various number oftools supporting domain specific language development is available, yet most lack in cate-gories like reusability, maintainability, interoperability or ease of use.

For that reason this thesis proposes a new framework for the development of domainspecific languages which is based on the vision of Model-Driven Engineering (MDE). InMDE models are the central artifact of software engineering and enable reuse. A domainand its language (syntax and semantic) are described by models. The framework allowsthe reuse of existing textual grammars for compiler generator tools, translating them intomodels. Thereby it becomes possible to apply a large number of MDE transformation andgeneration tools to them. In turn a language parser and generator can be produced fromthese grammar models. An additional goal is to automatically generate a suitable languageeditor and debugger to improve developer experience.

Using the proposed framework, the test automation language is reimplemented. Thisis realized by reusing an existing language and extending it. Also different problems likeerror reporting or tool support for the DSL are solved.

iv

Zusammenfassung

Die Grundlage für Innovation in der heutigen Automobilindustrie findet sich zu 90% imBereich der Elektronik- und Softwareentwicklung. Der Lebenszyklus neuer Produkte wirdimmer kürzer, und um konkurrenzfähig zu bleiben, müssen Hersteller immer schneller neueFunktionen integrieren. Das hat zur Folge, dass die Menge an Software im Auto exponen-tiell wächst. Die verwendete Software wie auch die Hardware müssen sorgfältig getestetwerden, um eine hohe Qualität garantieren zu können. Aufgrund der Menge und Komplex-ität ist dies nicht mehr manuell möglich und muss automatisiert werden. Bei der BMWGroup ist hierfür ein spezielles Testautomatisierungsframework einschließlich einer Mi-crosoft Excel basierten Testspezifikationssprache entwickelt worden. Die Sprache und ihreImplementierung lassen Raum für Verbesserungen. Dies erweißt sich allerdings aufgrundder gewählten Technologie als schwierig. Deshalb entschied man sich für die Entwicklungeiner neuen domänenspezifischen Sprache (DSL) für die Testautomatisierung.

Die Entwicklung einer neuen Sprache ist jedoch nicht trivial. Die Entwickler brauchenein breitgefächertes Repertoire an Wissen vor allem in den Bereichen Sprachdesign und-implementierung. Nicht zu unterschätzen ist die genaue Kenntnis der Domäne, für diedie neue Sprache bestimmt ist, um Syntax und Semantik möglichst domänenspezifischfestlegen zu können. Dieser Prozess wird durch eine Vielzahl an verfügbaren Werkzeu-gen unterstützt. Häufig sind diese allerdings in einem oder sogar mehreren Aspekten wieWiederverwendbarkeit, Wartbarkeit oder Interoperabilität unzureichend.

In dieser Arbeit wird ein neues Framework für die Entwicklung von domänenspezifis-chen Sprachen vorgeschlagen und implementiert. Es baut auf den Prinzipien des Model-Driven Engineering (MDE) auf, welches Modelle in das Zentrum der Softwareentwick-lung rückt und mit ihrer Hilfe eine einfachere Wiederverwendbarkeit ermöglicht. EineDomäne und ihre Sprache (Syntax und Semantik) werden mit Modellen beschrieben. DasFramework ermöglicht die Wiederverwendung von exestierenden textuellen Grammatiken,indem es sie in Grammatikmodelle überführt. Diese können mit Werkzeugen, welche eben-falls den MDE Ansatz verfolgen, modifiziert, analisiert, überprüft und umgewandelt wer-den. Außerdem ist es möglich, aus diesen Grammatikmodellen wiederum einen Parser zuerzeugen, sowie zusätzlich einen Editor und einen Debugger für die domänenspezifischeSprache, was der Verwendbarkeit durch Entwickler zu Gute kommt. Zusätzlich ist dieEntwicklung einer komplett neuen Sprache möglich.

Die bestehende Testautomatisierungsprache wird mit Hilfe des neuen Frameworks reim-plementiert – unter Wiederverwendung bestehender Artefakt und einer Erweiterung dieser.Hiermit werden Problem im Bereich Fehlerbehandlung und Werkzeugunterstützung gelöst.

v

Contents

Abstract iii

Zusammenfassung iv

Acknowledgments x

I Preliminaries 2

1 Introduction 31.1 Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31.2 Description of the remaining chapters . . . . . . . . . . . . . . . . . . . . 5

2 Technological context and related work 62.1 Domain specific languages . . . . . . . . . . . . . . . . . . . . . . . . . . 6

2.1.1 What is a domain specific language? . . . . . . . . . . . . . . . . . 62.1.2 Advantages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82.1.3 Disadvantages . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82.1.4 Development phases and patterns . . . . . . . . . . . . . . . . . . 92.1.5 Decision phase . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102.1.6 Analysis phase . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112.1.7 Design phase . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 132.1.8 Implementation phase . . . . . . . . . . . . . . . . . . . . . . . . 152.1.9 Approaches supporting DSL development . . . . . . . . . . . . . . 18

2.2 Model-Driven Engineering . . . . . . . . . . . . . . . . . . . . . . . . . . 222.2.1 Models - the foundation of MDE . . . . . . . . . . . . . . . . . . 222.2.2 Domain specific modeling languages . . . . . . . . . . . . . . . . 262.2.3 Generators and transformations . . . . . . . . . . . . . . . . . . . 282.2.4 Different MDE technologies in detail . . . . . . . . . . . . . . . . 31

2.3 Model-driven DSL development . . . . . . . . . . . . . . . . . . . . . . . 362.3.1 Model-driven DSLs by example . . . . . . . . . . . . . . . . . . . 362.3.2 Model-based domain specific language tools . . . . . . . . . . . . 37

2.4 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42

3 Domains in the automotive industry 43

vi

II Frodo 45

4 One framework to bind them all? 464.1 Requirements and solutions . . . . . . . . . . . . . . . . . . . . . . . . . . 464.2 User roles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 474.3 Framework Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . 48

4.3.1 Components of the framework . . . . . . . . . . . . . . . . . . . . 494.3.2 Language specification artifacts . . . . . . . . . . . . . . . . . . . 534.3.3 Back-end . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55

4.4 Implementation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 564.4.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 564.4.2 ECore - Metametamodel Implementation . . . . . . . . . . . . . . 574.4.3 Grammar / Syntax View Handling . . . . . . . . . . . . . . . . . . 604.4.4 Transformation Engine . . . . . . . . . . . . . . . . . . . . . . . . 634.4.5 Plugin Generation . . . . . . . . . . . . . . . . . . . . . . . . . . 634.4.6 Implementation problems and issues . . . . . . . . . . . . . . . . . 64

5 Examples 665.1 A simple state machine language . . . . . . . . . . . . . . . . . . . . . . . 66

5.1.1 Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 665.1.2 Implementation . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68

5.2 Test automation language . . . . . . . . . . . . . . . . . . . . . . . . . . 715.2.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 715.2.2 The current system . . . . . . . . . . . . . . . . . . . . . . . . . . 725.2.3 A better test automation language . . . . . . . . . . . . . . . . . . 76

III Conclusions 86

6 Future work 876.1 DSL Framework . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87

6.1.1 Theoretical outlook . . . . . . . . . . . . . . . . . . . . . . . . . 876.1.2 Practical outlook . . . . . . . . . . . . . . . . . . . . . . . . . . . 88

6.2 TestDSL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88

7 Summary 907.1 Survey . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 907.2 Contributions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91

A Fundamental Modeling Concepts 93

B Statement of Academic Honesty 96

vii

List of Figures

2.1 Simplified cost prediction for DSL-based methodologies [59] . . . . . . . . 92.2 Domain analysis, taken from [147] . . . . . . . . . . . . . . . . . . . . . . . 112.3 Different technological space and the metamodeling stacks . . . . . . . . . . 252.4 Example of MOF layers . . . . . . . . . . . . . . . . . . . . . . . . . . . . 322.5 MDA PIM to PSM (FMC) . . . . . . . . . . . . . . . . . . . . . . . . . . . 332.6 ECore metametamodel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 342.7 XMI used for exchange. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35

4.1 Proposed architecture for an model-driven DSL framework (FMC) . . . . . . 494.2 Frodo’s architecture (FMC) . . . . . . . . . . . . . . . . . . . . . . . . . . 574.3 Excerpt from Frodo grammar metamodel . . . . . . . . . . . . . . . . . . . 61

5.1 Finite state machine domain model . . . . . . . . . . . . . . . . . . . . . . 675.2 Example of a finite state machine . . . . . . . . . . . . . . . . . . . . . . . 675.3 Screenshot of the FSM editor . . . . . . . . . . . . . . . . . . . . . . . . . . 705.4 Current PyTAF architecture (FMC) . . . . . . . . . . . . . . . . . . . . . . 745.5 Excel TestDSL example . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76

A.1 FMC block diagram example . . . . . . . . . . . . . . . . . . . . . . . . . . 94A.2 FMC block diagram reference sheet . . . . . . . . . . . . . . . . . . . . . . 95

viii

List of Tables

2.1 Well known DSLs [92] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82.2 Lines of Code for different approaches to implement FDL . . . . . . . . . . 182.3 Different MDE implementations, different metametamodels . . . . . . . . . 242.4 Different tools for creating DSML . . . . . . . . . . . . . . . . . . . . . . . 272.5 Different model-to-text approaches . . . . . . . . . . . . . . . . . . . . . . 292.6 Different generator tools . . . . . . . . . . . . . . . . . . . . . . . . . . . . 292.7 Transformation engines from different technology spaces . . . . . . . . . . . 302.8 Some model-to-model transformers . . . . . . . . . . . . . . . . . . . . . . 31

ix

Listings

2.1 SPL metamodel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 382.2 SPL TCS template specification . . . . . . . . . . . . . . . . . . . . . . . 382.3 A TCSSL grammar example . . . . . . . . . . . . . . . . . . . . . . . . . 414.1 Creating an ECore metamodel for a carpool in Python . . . . . . . . . . . . 594.2 Carpool metamodel as XMI . . . . . . . . . . . . . . . . . . . . . . . . . . 594.3 Auto importing the carpool metamodel and creating a model . . . . . . . . 594.4 XMI representation of a carpool model . . . . . . . . . . . . . . . . . . . . 604.5 Excerpt from the generative grammar for ANTLR grammars . . . . . . . . 625.1 Example of FSM DSL (demo.fsm). . . . . . . . . . . . . . . . . . . . . . . 675.2 Grammar of the FSM DSL as EBNF . . . . . . . . . . . . . . . . . . . . . 685.3 The FSM parser grammar . . . . . . . . . . . . . . . . . . . . . . . . . . . 685.4 The FSM lexer grammar . . . . . . . . . . . . . . . . . . . . . . . . . . . 695.5 A simple FSM interpreter in Python, interpreting demo.fsm . . . . . . . . . 705.6 The XMI representation of demo.fsm . . . . . . . . . . . . . . . . . . . . 705.7 A generative grammar, producing a C back-end. . . . . . . . . . . . . . . . 715.8 Example of generated code for TestDSL . . . . . . . . . . . . . . . . . . . 805.9 Example of the embedded Python test language . . . . . . . . . . . . . . . 815.10 Example of the new wait statment . . . . . . . . . . . . . . . . . . . . . . 815.11 Exerpt from the Python grammar metamodel to Frodo metamodel transfor-

mation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 825.12 Example of unmatchable rule with finite lookahead and a solution. . . . . . 84

x

Acknowledgments

I would like to thank Klaus Ries and Markus Hillebrand at the BMW Group, for manyinteressting discussion even for the philosophical ones. Inspiring and wild ideas were dis-cussed. But after all their guidance helped me to keep the right direction. Also Martin vonLöwis, my tutor at the HPI helped with additional ideas and many corrections. FurthermoreI would like to thank Hannah Ulferts for motivation, correcting this thesis and eating mychocolate. Additional corrections were done by Thomas Hille, Friederike Karlsch and JensUlferts, many thanks go to them, too, especially to Thomas because he shared my thesiswriting fate.

Last but not least I could not have done all of this without the never ending support ofmy family. Thank you.

1

The limits of my language determine the limits of my world.

Ludwig Wittgenstein

2

Part I

Preliminaries

3

Chapter 1

Introduction

1.1 MotivationToday the German automotive industry holds a high market share and has a good reputationall over the world [57]. However, competition with low cost manufacturers forces compa-nies like BMW Group, Audi or DaimlerCrysler to concentrate on innovative features [57],for example sophisticated control over processes like engine, brake or acceleration control,furthermore infotainment functionality like GPS navigation, head-up displays or advancedaudio/video functionality. Almost every new feature contains a combination of electronicsand software [35]. To reduce costs, devices are built out of standard hardware componentswhile the software is well customized, not least to avoid imitation.

This has led to an exponential growth of software inside a car [35]. However, thesoftware engineering capabilities within the automotive industry, suppliers and OEMs alikehave not grown as fast as the complexity. The cause for the increased complexity is not onlythe amount of software but more and more distributed, interconnected and interdependentfunctionality leading to a higher error rate.

A number of measures have been taken to manage it. One is to automate testing, es-pecially integration testing. Many different test automation solutions exist nowadays butnot all fulfill the requirements of automotive integration testing. Therefore PyTAF[62], apractical Python1 test automation framework, has been developed at the BMW Group. It isprogrammed in a domain specific test automation language, not in Python directly. Fromthis language Python code is generated.

Domain specific languages (DSLs) are computer languages tailored to a special field ofapplication. Compared to general purpose languages they offer an advantage in expressive-ness and ease of use in their domain. This is possible due to higher abstraction, a clear andconcise program specification and improved program checking possibilities.

For the current test automation language, test cases have to be written inside MicrosoftExcel. This is not satisfying because of the implied and inappropriate spreadsheet struc-ture and limited integration into the development environment. Furthermore the languageitself suffers from design problems such as an incomplete data model. As a case in pointthis can lead to ineffective test development or even worse defective tests and increased

1The programming language. http://www.python.org

4

maintenance costs. Later in this thesis the current issues will be elaborated in more detail.Most of the problems can be solved by a new textual domain specific language. This

language needs to be equally powerful but has to improve upon the current shortcoming.Nevertheless, the development of a new language is a difficult task to undertake, even if thelanguage is domain specific. The developer needs to be qualified for language design andimplementation and to possess a good understanding of the target domain. For tasks suchas compiler development several tools are available. Likewise tools explicitly supportingthe development of domain specific languages have been created. To utilize most of themgreat expertise is still required. Additionally reuse is difficult in most cases.

A vision which focuses on reuse is Model-Driven Engineering (MDE). Models moveinto the center of the development process. They allow a more domain specific descriptionof problems than modern third generation programming languages are able to offer, ex-ploiting advanced modeling techniques, code generation and model transformations. Thisapproach is very promising as first results show [17].

Recently first attempts have been made to combine technologies for DSL developmentwith the MDE paradigm, motivated by improved reuse properties and the need to specifydomain specific languages more easily [64, 94, 96, 146, 151].

In this thesis, beyond the improved test automation language, a model-driven frame-work is presented allowing to implement the former in a more easy and reusable way.Inside [106] Klint demands an “engineering discipline for grammarware” stating that theengineering aspect of grammar-depended software is insufficiently understood. Most DSLdevelopment tools are grammar based. Still questions like grammar transformation, main-tenance, verification and reuse are hard to answer. While the available DSL tools answersome of the question in a versatile way, they remain unconnected island solutions. Forexample grammar refactoring is available in nearly none of the current tools. Providinganswers will reduce needed development efforts and decrease the number of errors.

For that reason the proposed framework tries to combine DSL development and MDEbacked by the idea of explicitly enabling reuse. A metamodel for grammars is specifiedwhich is able to represent a large number of grammars as grammar models. These modelscan then be modified utilizing a large number of available MDE-enabled tools. For ex-ample it is possible to refactor through transformation of the grammar model or to applyaspects. Nevertheless, refactoring or aspect introduction is not the focus of this thesis. Toenable MDE in the first place, this thesis also discusses the implementation of a popularmetametamodel on a new platform.

Furthermore, not only formal aspects are important in DSL development but also thesurrounding toolset and its integration. Developers are used to capable editors with syntaxhighlighting, folding and code completing and moreover excellent support of debuggingin modern IDEs. These feature can greatly improve productivity though are seldom avail-able for domain specific languages as a high development effort is necessary to implementeditors and debuggers. The proposed framework shows a possible way to automaticallydeliver such an environment.

While implementing the new test automation language, for example the formal Pythongrammar is reused and extended. This allowed to save a large amount of development time,base the new language on an already existing formal specification and create a reusable

5

model of Python and the DSL.Additionally problems like error reporting, exception mapping from back-end to the

DSL and some debugging capabilities are enabled by using the presented framework. Thesefeatures were not included in the original test automation language.

1.2 Description of the remaining chaptersThis thesis is divided into three parts.

Part one gives an extensive overview of concepts and current technologies. It consistof three chapters. First, domain specific languages are described. What is a DSL and whatadvantages and disadvantages are associated with it? Then development phases and designpatterns for each phase are discussed including references to different technologies. Finallya review of some more concrete tools and frameworks allowing the implementation of DSLis given.

In the chapter Model-Driven Engineering the former term is introduced as a new soft-ware engineering paradigm. Definition for model, metamodel, metametamodel and tech-nology space are provided followed by a formal specification attempt. Moreover the con-cepts of domain specific modeling languages, generator and transformations are elucidated,in each case underpinned by a description of current technology. The last section explainsconcrete technologies in more detail such as the Meta Object Facility, Model-Driven Ar-chitecture, Eclipse Modeling Framework, and XML Metadata Interchange.

That last chapter of part one outlines research which is more closely related to thisthesis, namely examples of DSLs implemented using model-driven techniques and MDE-enabled DSL development frameworks.

Part two contains the main contributions of this thesis, split up into a framework pro-posal, the realization of that proposal and two examples. While the proposal is generic anddoes not discuss concrete technologies, the implementation shows what technologies areable and which of them were used to realize the framework. Furthermore different prob-lems encountered are depicted. At the end two examples are implemented with the helpof the framework: a simple state machine language and a more complex test automationlanguage. The later one is elaborated in more detail because it is major contribution ofthis thesis. At first the currently used system is described, followed by an enumeration ofits problems in design and implementation. Then, a new language and its development isshown.

Part three, the last part of this work consists of two chapters. The first chapter showspossibilities for future work in general for the proposed and implemented framework andin special for the test automation language. The second chapter draws a summary of thisthesis and names important contributions. Finally the appendix contains an overview aboutthe FMC2 notation often used in this work.

2Fundamental Modeling Concepts.

6

Chapter 2

Technological context and related work

Initially this chapter introduces domain specific languages, explains their advantages anddisadvantages, gives a summary about common patterns and categorizes the domain spe-cific language development process. Furthermore different approaches and tools, support-ing language development, are discussed. Secondly the approach of Model-Driven Engi-neering is presented, including an explanation of terms such as metamodel or technicalspace. Afterwards different Model-Driven Engineering incarnations are depicted togetherwith the meaning of generators and transformations in this context and what kinds of ap-proaches are available. A closer look on MOF/MDA, ECore/EMF and XMI follows. Fi-nally an insight into various frameworks which directly support model-driven languagedevelopment is given.

2.1 Domain specific languages“Works of imagination should be written in very plain language; the more

purely imaginative they are the more necessary it is to be plain.” 1

This section describes what a domain specific languages is, what kind of ad-vantages and disadvantages a DSL has and also what common DSL analysis,design and implementation patterns exist.

2.1.1 What is a domain specific language?To understand the meaning Of the term domain specific language or more precisely domainspecific programming language the term programming language is defined. One possibilityis given by [72]:

“A programming language or computer language is a standardized com-munication technique for expressing instructions to a computer. It is a setof syntactic and semantic rules used to define computer programs. A languageenables a programmer to precisely specify what data a computer will act upon,

1 Samuel Taylor Coleridge

7

how these data will be stored/transmitted, and precisely what actions to takeunder various circumstances.”

However there exists no definition which all authors agree upon. Watts therefore proposes[181] some criteria which have to be fulfilled by a programming language:

• Must be universal (every problem must have a solution that can be programmed inthe language, if that problem can be solved at all by computer).

• Must be implementable on a computer.

• Should also be reasonably natural for solving problems, at least problems within itsintended application area.

Programming languages in general can be grouped or classified by different criteria. Possi-ble criteria are the purpose (for example Fortran for scientific programming versus C [102]for system programming), the paradigm (LISP as a functional language or Smalltalk as aobject oriented language), the generation (1GL up to 5GL) , whether it is imperative ordeclarative and domain specific or general purpose. General purpose languages (GPLs) areless specialized and are suited for a wide area of applications from business processing upto scientific computing. Java2 is a prominent representative.

The term domain specific means that the language is explicitly tailored to a target do-main. Complex constructs and abstraction of the domain are offered within the languageincreasing its expressiveness in comparison to GPLs. It is possible to express solutionsfor domain problems with a lesser effort. The higher abstraction and the compactness andtherefore better readability and writability enables a larger group of people with less pro-gramming knowledge to be productive using the DSL. This leads to productivity gains ingeneral and also to decreased maintenance costs.

Often a DSL does not fulfill all criteria given by Watts. Nevertheless, many DSLs areregarded as special programming languages.

Today there are many well known DSLs like HTML, SQL, VHDL, make (softwarebuild process), Latex (document preparation), BNF (context free grammars) or even Excel.The use of DSLs is not new. These languages had been named special-purpose languages,end-user languages or as Bentley [23] called them “little languages” before the term do-main specific language was coined. Already in 1957 APT [34], a language for numericcontrolled machines was developed at the MIT, which can be considered as one of the firstavailable DSLs. The boarder between a DSL and a GPL is fuzzy, for example COBOLwas considered a GPL but also a DSL for business applications. Another example is Pro-log which can be understood as a DSL for applications specified by the predicate calculus.One attempt to classify a language has been done by Jones [92]. A higher level stands formore domain specific whereas a lower level means more generality (table 2.1). As statedby Mernik [126] the domain-specificity of a language is a matter of degree. In this thesis adefinition by the former will serve as a guidance:

2http://java.sun.com/

8

“DSLs are languages tailored to a specific application domain. They offersubstantial gains in expressiveness and ease of use compared with GPLs intheir domain of application”

However many similar definition can be found in the literature [99].

DSL domain levelJava GPL 5

VHDL hardware design 17HTML web pages markup 22SQL database queries 25Excel spreadsheets 57

Table 2.1: Well known DSLs [92]

2.1.2 AdvantagesAs stated in 2.1.1 a DSL offers different advantages. Productivity and maintainability [172]are increased due to an appropriated domain specific notation. DSLs are more suitablefor end-user programming. Domain experts are able to understand , validate, modify anddevelop within the language (better readability, writability and high abstraction). The gainscan be measured quantitatively and qualitatively. Most qualitative reasoning is backed upby practical observations. According to [126] the quantitative validation of DSL advantagesis an ongoing field of research, yet supporting results are reported. Figure 2.1 shows theadvantage of DSLs regarding to long term cost.

Because of the concise nature and the domain fitting notation DSLs are up to a certaindegree self-documenting. This also facilitates the embodying of domain knowledge whicheases reuse [63, 166] and conservation.

Another advantage is the possibility to validate at domain level [49]. While normal GPLcompilers do not know about any domain concept beyond the general language constructs,a DSL can be checked for any domain specific constraint. An example may be real timeproperties: as long as for every language construct a certain execution time is ensured, it ispossible to automatically proof the whole program. Just as verification, optimization canbe done more effectively at the domain level [18].

2.1.3 DisadvantagesA DSL has not only advantages, but also potential shortcomings. One drawback is the highdevelopment effort which is needed for a new language. The language developer needsat least experience in language design and knowledge about the target domain. He hasto find fitting abstractions, the right scope and balance between GPL and DSL constructs.Furthermore the language must be implemented and maintained.

9

Figure 2.1: Simplified cost prediction for DSL-based methodologies [59]

Other problems are tooling, user training costs and performance. While general pur-pose languages such as Java or C#3 have a strong tool support, corresponding tools for anew DSL have to be created. IDEs like Eclipse or Visual Studio offer deep integrationwith these languages like powerful editors with syntax highlighting and checking, inte-grated compilers and advanced debuggers. Creating a tool ecosystem for a DSL is a timeconsuming process which adds to the total costs caused by language design and implemen-tation. Without a development methodology and suitable tools the risk is high that the DSLdevelopment costs surpass the estimated saving by using a DSL.

The mentioned training costs originate from the fact that possible DSL users have bydefinition never used the language before, However this is mitigated as in most cases thenew language should match the domain expert’s expectations.

Often a DSL will suffer from a lower performance than a hand written software. Aslong as performance is not critical the other DSL benefits will make this a minor problem.Nevertheless is some cases performance can be equal or faster because optimization ispossible on a high abstraction level but in most cases the potential is limited.

2.1.4 Development phases and patternsThe development of a DSL can be divided into different phases. The design and the im-plementation phase were already mentioned. A more fine grained phase subdivision ispossible. Five stages can be distinguished: decision, analysis, design, implementation anddeployment. The development process of a DSL has not to follow these phases sequen-tially.

Different authors [161, 166] have identified numerous patterns which are reoccurring in

3http://www.ecma-international.org/publications/standards/Ecma-334.htm

10

DSL development and can serve as guidance for a developer without prior expertise in thisfield. Each pattern can be assigned to one of the five phases. The patterns are divided intodecision patterns, analysis patterns, design patterns and implementation patterns each cap-turing common approaches. In the following section phases and patterns will be describedaccording to the extensive analysis by Menrik et al. [126].

2.1.5 Decision phaseBefore the development of a new DSL can begin, a decision has to be made. Is it feasibleor not? Economic considerations have to be taken into account. Do the accumulated devel-opment, deployment and maintenance costs justify a new DSL in comparison with otherconventional approaches? Is there already a suited existing DSL? If so are documentationand maintenance good enough? If not, is the risk developing a new DSL acceptable?

The following decision patterns have been identified. Most of them based on the samegeneral concerns such as allowing domain experts with less programming experience [130,163] to develop software or improving software economics.

• Notation An improved new or existing domain specific notation can be a definitivefactor. Two common subpatterns are the transformation of a visual to a textual notionand the creation of a user friendly notation for an existing API. The first pattern forexample enables easier composition for large artifacts.

• AVOPT Domain-specific analysis, verification, optimization, parallelization and trans-formation for applications developed in a GPL are in general time consuming andhard to automate due to for example source code complexity. With a well definedDSL AVOPT is more feasible.

• Task automation In some cases GPL programming suffers from repetitive program-ming tasks. Automatic code generation driven by an appropriated DSL can ease this[160].

• Product line Some software products do not exist as a single standalone applicationbut are part of a product line or software family, sharing common parts. A DSL canfacilitate the specification and support automated assembly [182].

• Data structure representation Representing structured data in an easy to read, writeand maintainable form assists in making complex structures accessible. An appro-priated DSL can help achieving this goals. YAML [22] and JSON [52] are examples.

• Data structure traversal Like representation, traversal of data structures can often beexpressed more effective with a fitting DSL (for example SQL [84]).

• System front-end DSL based configuration and adaption for system front-ends

• Interaction Text, menu, dialog or voice based applications which interact with theuser can benefit from a DSL which specifies input and reaction in a high level repre-sentation.

11

• GUI construction Often GUI design is done by using a DSL. For example XUL andXAML are XML based DSL for GUI description [25].

2.1.6 Analysis phaseAfter the decision in favor for a (new) DSL is made, the specific domain has to be analyzedwith the goal of gathering as much domain knowledge as possible. It is important to ensurea high quality of the gathered material and to have access to domain experts. The term do-main analysis was introduced by Neighbors [132] and defined as identifying similar objectsand operations in a particular domain. Different sources of information can be examinedfor example already existing technical documents, APIs and GPL code or knowledge fromdomain experts.

After gathering the knowledge must be clustered to find meaningful abstractions andmust be consolidated. In most cases the results of the analysis are a domain definition,the domain specific terminology and concepts, a domain model, the domain scope anda description of the (operational) semantics. Figure 2.2 summarizes different sources andpossible results. Yet there is no widely adopted notation to capture the results of the analysisphase.

Three different domain analysis patterns can be identified: informal, formal and extrac-tion from code.

Figure 2.2: Domain analysis, taken from [147]

12

Informal pattern

The informal pattern means that the domain analysis is done informally and therefore noformal process is used. Most DSLs are developed without an analysis methodology [126].This often leads to incomplete requirements and can complicate the development process.While it is possible to get first results earlier the quality is not as high as with formalpatterns. For simple domains an informal process is often enough.

Formal pattern

Domain analysis can also be done using a defined process/methodology. Those which use amethodology can be counted to those that follow the formal pattern. Using a formal patternhelps to avoid missing important parts of the domain and can lead to more appropriaterequirements. A large number of methodologies used, come from another field of research:domain engineering. Domain engineering is derived from the area of software reuse andrefers to the systematic modeling of a target domain. This is strongly related to the notationof program families [171] and software product lines [113, 162].

While domain engineering and analysis techniques focus mainly on commonalities,family and product line analysis examine the variations inside a domain. Several method-ologies exist today: FAST (Family-Oriented Abstractions, Specification and Translation)[182] , Sherlock [168], DSSA (Domain-Specific Software Architectures) [165], DARE(Domain Analysis and Reuse Environment) [75], FODA (Feature-Oriented Domain Anal-ysis) [100], PROTEUS [89], ODE (Ontology-based Domain Engineering) [54] or ODM(Organization Domain Modeling) [158]. This list consists of the most well know methodsbut is by no means complete.

An example where FODA and FAST are applied can be found in [126]. While mostmethodologies have a graphical feature diagram or domain model as result, Deursen andKlint propose a formalized textual4 representation [58] which can be used to generate UML[133] diagrams or other types of documentation even code.

Semi formal

A specific semi formal approach (domain driven design) covering analysis is proposed in[66]. The creation of a fitting domain model is most important in domain driven design. Atfirst domain experts and software architects try to find a domain model which serves as abase for a common communication language (Ubiquitous Language). This language willbe used later on in all aspects of the development process. It is advised that the notation forthe domain model is UML. Not only one large diagram, but several small diagrams eachdescribing a certain aspect or part should be used. The reason behind this is avoiding clut-tering and reducing complexity. The UML artifacts should be accompanied by documentsthat contain information not captured by UML like the meaning of concepts or what certainobjects are supposed to do. In comparison to other methodologies Evans gives extensiveinformation how to continue after the domain model is established or the feature analysisis done.

4 The Feature Description Language (FDL), which is a separate DSL again.

13

Extraction from code pattern

The last identified pattern extraction from code derives a DSL directly from an existingimplementation. In most cases this implementation is done in a GPL though it is alsopossible to derive from another DSL.

2.1.7 Design phaseThe design of a DSL and therefore the development of the language itself is based on theresults of the earlier phases. Two questions have to be answered approaching the design:How is the DSL related to existing languages and what kind of formal description for thelanguage is chosen? With each question different possible design patterns are associatedhelping to find an appropriated answer.

Creating a language based on an existing one can have different advantages. Someusers may be familiar with the base language resulting in reduced training cost. Commonoperations such as arithmetic’s for the family of C languages are well known to manydevelopers. Furthermore an existing implementation and/or eco system can be leveraged.Three different approaches reusing existing language can be distinguished. The fourthapproach is the entirely new development of a language.

Piggyback

The new language can piggyback domain specifics feature on part of the existing language.Examples are Hancock [51], lava [159] or Facile [154]. Hancock is a DSL for high per-formance signature processing and it piggybacks on C by modifying language parts andadding processing related constructs. From this DSL, C code is generated again. Similarto that lava, a production grammar DSL to describe and generate test cases for a JVM, pig-gybacks on the textual Java byte code representation. The byte code is generated from theDSL. The Facile language helps developing high performance processor simulation, alsoby augmenting C.

Extension

A related pattern is extension. The base language is extended by features correspondingto domain concept. In comparison to piggybacking the base language is not modified orreplaced. A problem of this approach is the seamlessly integration of new features withexisting ones. A DSL which follows the extension pattern is SWUL [32]. SWUL supportsthe development of Java SWING GUIs and is embedded into Java.

Specialization

Developing a new DSL does not always mean to create something new. A more uncommonpattern is specialization (not to confuse with specialization in UML). An existing languageis reduced to fit the needs of a special domain. Examples are RPython [149] or OWL-Lite[174]. RPython is a subset of the Python language used inside the PyPy project [149]. Thecomplexity of Python is reduced in order to make C code generation from RPython easier.

14

OWL-Lite is a subset of the OWL Web Ontology Language with the goal to reason easierabout it than OWL.

Entirely new language

While building on another language can have several advantages as discussed above, cre-ating a completely new language offers great flexibility. However with great flexibilitycomes an increased difficulty designing the language. The design of most GPLs is directedby a number of desirable characteristics [72], namely simplicity, abstraction, expressive-ness, uniformity, efficiency, safety, modularity, clarity and orthogonality. More essential ordesirable characteristics and also language design advices are stated by Horowitz [90] inhis evaluation of programming languages. Also software economics may influence the de-sign, too. Costs can be generated by programmer training, software creating, compilation,execution and maintenance time which depends on the DSL.

Following the guidelines for GPL design while designing a new DSL is considered agood idea, many DSL researcher believe that the same rules apply for general and domainspecific languages. This needs caution though as real life DSL development has shown[186]. Some domain models or established domain notations can be in conflict with thebasic rules. The DSL users can be the end-users and do not need to be programmers. Wileformulates some learned lessons from real life DSL development:

“Lesson 3: You are almost never designing a programming language.

Lesson 3 Corollary: Design only what is necessary. Learn to recognize yourtendency to over-design.

Most DSL designers come from language design backgrounds. There the ad-mirable principles of orthogonality and economy of form are not necessarilywell-applied to DSL design. Especially in catering to the pre-existing jargonand notations of the domain, one must be careful not to embellish or over-generalize the language.” [186]

Informal or formal design

After the question is answered if and how the DSL might be related to other languages, thedesigner has to specify the language itself. This can be done formally or informally.

Using the informal design pattern is often easier. The specification is usually written insome sort of natural language. Sample DSL code snippets or short programs are sometimesused exemplary to show language constructs and what their meaning is. This approach suf-fers from certain restriction: it is not clear if the descriptions are precise enough - languagesyntax and semantic problems can only be detected in the implementation phase and ofteninformal artifacts are not directly useful for the implementation.

A formal language design can solve some of these problems. Syntax and semanticproblems can be checked automatically if an appropriated formalism is used. With a for-mal specification it is possible to derive parts of the implementation and therefore reducethe needed implementation efforts. Different formal methods may be applied including

15

grammars for syntax and abstract state machines for semantic definition (like BNF) , at-tributed grammars or rewrite systems.

2.1.8 Implementation phaseAfter the hurdles of analysis and design are taken, the DSL has to be implemented (in caseit is executable, editable or should be analyzed). A wide range of possible implementationstrategies exists and the best appropriated one should be chosen. This decision can stronglyinfluence the needed development efforts and should be considered carefully. As withdecision, analysis and design different possible implementation patterns can be identified.Fowler [74] distinguished between external and internal DSL. Spinellis [161] and Mernik[126] found similar patterns but did a deeper analysis. Some of them will be discussed inthe following sections.

Compiler5 / Interpreter pattern

The most obvious strategy is implementing a DSL in the way a large number of GPLs areimplemented: by using an interpreter or compiler/application generator approach.

An interpreter interprets DSL code in a recognize-fetch-decode-run cycle. A great num-ber of dynamic languages (such as Ruby6 or Python) is implemented following this pattern.An interpreter is much easier to implement and later to extend, compared to a compiler.Furthermore the runtime environment is often easier to control.

A compiler approach offers different advantages. Because the complete code has tobe analyzed by the compiler extensive static analysis including error checking and appro-priated error reporting can be done. The source is then transformed into library calls andlower level language constructs (For example when compiling C#, it is transformed intoMSIL and calls to .Net Libraries). This allows fine grained optimizations and often offersa performance advantaged due to native execution of the compilation results.

Preprocessors

Another classical approach to DSL implementation involves preprocessors. The prepro-cessing step happens before the code is interpreted or compiled. Different flavors can bedistinguished.

The macro preprocessor is one of the most used forms of preprocessing. Macros canbe simple substitutions on the lexical level before any parsing is done. One or more tokenscan be replaced by a sequence of characters or other tokens. These substitutions can oftenbe parametrized. The C language with the C preprocessor is an example of simple macros.However working only on the lexical level has many shortcomings. The preprocessor isindependent of the underlying language and therefore syntax or logical errors can be easilyintroduced while expanding the macros. These errors can only be detected at interpret orcompile time.

5In the context of DSL development, compilers are sometimes called application generators.6http://www.ruby-lang.org/

16

This problem is solved by syntactical macros that work on the syntactical level henceon the parse tree. Scheme or <bigwig> for example offer hygienic macros [109]. Thesemacros are checked and guarantee to prevent the production of collisions with existingsymbol definitions during expansion. The language C++ also offers syntactical macros,called templates or template metaprogramming7. An example DSL constructed by C++template metaprogramming techniques and operator overloading is Spirit (a C++ ParserFramework [55]).

Another form of preprocessing is the source-to-source transformation. Unlike macroswhere the scope is restricted to some tokens, the whole source is translated into anotherlanguage. An example is the in 2.1.7 mentioned language SWUL. Here the complete DSLwhich is embedded inside a Java source file is replace by Java code.

A more uncommon preprocessing pattern is the pipeline. The source is not change inone but in multiple steps whereas each processor is responsible for a subset of the DSL.The language CHEM is an example using a pipeline architecture.

Embedding

While preprocessors replace the DSL code the embedding approach8 directly embeds DSLconstructs9 inside a host language. The basic embedding, is the creation of a simple appli-cation library. To allow a more domain specific notation, new types, operators and otherconstructs depending on the base language are created. The combination of the new con-structs is then used to describe a domain specific problem. In C++ an often used feature toallow domain specific notation is operator overloading10.

Not all languages are equally well suited as a host for a DSEL. Hudak states that func-tional languages like Haskell11 or MetaOCaml12 are far more convenient than classicalstatic typed compiled languages such as Java (Lava is a Haskell DSEL example [27]).Mostly this is due to features like partial and lazy evaluation, high order functions orgeneric and polymorphic strong types. However also dynamic languages like Smalltalk[81] or lately Ruby [167] have proven to be equally suitable for embedding a DSL becauseof their very flexible syntax and advanced introspection, reflection and dynamic runtimemodification features. In contradiction to Hudak, Freeman and Pryce [77] show that it ispossible to implement a acceptable DSEL in Java. By separating syntax from interpretationthrough object call chains which create an object graph, a good compromise is reached. Inthe end they conclude, now in conformance with Hudak, that even though they reachedtheir goal other languages are better suited.

Some future languages are especially built with extensibility in mind like Fortress [9]or Scala[138].

7 The C++ template system is a Turing-complete almost functional compile time programminglanguage[176].

8 Often called domain specific embedded language (DSEL) or embedded domain specific languages(ESDL)

9 DSL constructs have to be valid constructs in the context of the host language.10 For example Liboctave a C++ math library allows matrix addition and multiplication using the normal

addition or multiplication operator.11http://www.haskell.org/12http://www.metaocaml.org/

17

Extension

A related approach to embedding is the extension of the language itself. The compileror interpreter is modified to work with domain specific constructs. This is more difficultthan other approaches since most compiler or interpreters are not designed for extension.Modular and safe techniques are still a matter of research. One possible solution are MetaObject Protocols (MOP) like the runtime MOP [103] for CLOS or the compiletime MOPfor C++ [48].

Metaobjects are objects modeling the object system itself and they allow introspectionand customization. A Metaobject protocol guarantees that the Object System will follow adocumented protocol for various parts of its operation. therefore a MOP defines the mean-ing and behavior of a program. Through the MOP an existing language can be modifiedand extended.

COTS

With the rise of XML another form of DSL implementation has evolved. DSL implemen-tation can also be approached by using commercial of the shelf (COTS) tools and libraryand restricting them to fit a special domain [101]. The grammar for a XML DSL can becustomized by using a DTD or a XML Schema. As a broad range of XML library andtools is available for parsing (DOM,SAX and STAX parsers), for analyzing (XQuery), andfor transforming (XSLT) the effort for a standalone parser and compiler can be reduced[139]. In addition to that tools for writing and displaying XML in a structured manner areavailable. However XML is not the only possibility as Wile showed [186].

Hybrid

The different strategies have on the one hand advantages but disadvantages on the other..While it is possible to have a syntax very close to the domain, domain specific verificationand optimization (AVOPT in general) and good error reporting using the compiler/inter-preter pattern often causes problems due to the complexity of the tools development andthe need to design a language from zero compared to the solution of leveraging a existingsolutions. In 2.1.9 some frameworks and tools will be discussed which try to solve someof these problems. Additionally the framework presented in this paper tries to solve someproblems.

The embedding approach has similar advantages and problems but the sides are flipped.The advantages: often existing languages and their tool chains can be reused and the im-plementation effort is reduced. On the other side it is hard to create a domain fitting syntaxbeing bound to a host language. Although the existing infrastructure is leveraged, the DSLconcepts are not known to the base language resulting in the problem that error reportingor debugging happens in terms of the hosting language not the DSL.

Therefore it is also possible that a hybrid approach is used. Examples are combin-ing macros and an extensible compiler [164], combining embedding and compiling [65],combining macros and embedding [71] and many others.

18

It has to be decided per case which kind of approach is appropriated. A non generalapplicable and simplified comparison of needed effort is presented in table 2.2. Mernikimplemented the Feature Description Language (FDL) [58] using several approaches andcompared the results.

Approach Lines of CodeCompiler 1100

Macro-processing 50Embedding (Prolog) 40

XML-based 310

Table 2.2: Lines of Code for different approaches to implement FDL

2.1.9 Approaches supporting DSL developmentMany different tools and frameworks are available to support the development of domainspecific languages. They differ in their approaches and their maturity. Some supportthe whole development life cycle and offer a solution for editor and debugger generationwhereas others are simple compiler generators. Most of them are based on various formsof language descriptions.

Compiler Compiler

The lowest common denominator are compiler compiler tools13, that can be used to developnew domain specific languages. They are able to construct a lexer/parser out of a givengrammar. This can be the base for an interpreter or compiler. The most prominent onesare Lex/Yacc14, Flex/Bison15, JavaCC16, SableCC17, CoCo/R18 and ANTLR [141] (a morecomprehensive list is given by [2, 185]). They often differ only slightly in the used grammaror the power of the generated lexers/parsers (GLR, LALR, SLR, LR or LL). A large numberof different DSLs has been constructed using one of these tools. However they only solvethe problem of syntax recognition, so a parser/compiler has not to be developed manually.It should not remain unmentioned that they often require a solid background in languagedevelopment theory, like to understand the difference in power between a GLR and LLgenerator.

JTS, Maya, JSE

In section 2.1.8 different approaches to DSL implementations are described. As statednormally it is hard to extend existing languages if no special arrangements were taken by

13Often also named lexer/parser generators.14http://dinosaur.compilertools.net/15http://www.gnu.org/software/flex/16https://javacc.dev.java.net/17http://sablecc.org/18http://www.ssw.uni-linz.ac.at/Research/Projects/Coco/

19

the original language implementers . Java is such a case. Nevertheless the Jakarta ToolSuite [19] supports the extension of the Java language with domain specific constructs.JTS consists of two components Bali and Jak. Bali is a Java Precompiler which takesan annotated EBNF grammar as input and Jak is a JTS generated superset of the JavaLanguage with meta programming capabilities . Together they allow an easier extension ofJava corresponding to a macro approach. Similar approaches are Maya [16] and the JavaSyntax Extender (JSE) [15].

JLE

While JTS provides facilities for error checking there is no support for more general staticanalysis. The Java Language Extension Framework (JLE) [188] is an alternative to theJTS. The primary idea behind JTS was macro processing, the JLE framework builds a newcustomized Java compiler out of the different selectable language extension. The languageextensions are formulated in an attributed grammar and are strictly modular. They can beused for the simple extension of the host language grammar productions or for the definitionof static analysis and optimizations. Finally the customized compiler generates pure Javafrom the input code.

EasyExtend

Another approach to language extension with domain specific constructs is EasyExtend.EasyExtend allows to extend the Python programming language. This is done by modularmodifications to the original Python grammar. The new grammar is used in combinationwith a mapping to valid Python constructs creating a new domain specific parser. One thatcan parse and run the DSL on top of Python. The original CPython Parser is not modifiedand has not to be recompiled19.

metafront

A framework which goes beyond the shortly before introduced tools is metafront [30].Metafront is language agnostic. It consists of two parts: grammar and syntactic transfor-mation specifications. An input stream according to the grammar is parsed by a new pars-ing algorithm (specificity parsing). The input grammar can be created in a modular waycombining multiple grammar input files (one grammar can extend another grammar). Theresulting parse tree can then be transformed by given declarative transformation rules. Forevery transformation an input and an output language (grammar) has to be defined. Thisallows metafront to statically check the transformations for type safety and to guaranteethe termination of the rules. The metafront approach can be used as a (macro) preprocessorfor domain specific language extension or for the development a completely new language.The language is then transformed into a base language like C.

19 A modified parser from the PyPy project is used (written in Python).

20

LISA

The previous approaches could be used for the extension of an existing language or for acomplete new DSL, they do not solve the DSL ecosystem problems. Nevertheless differentframeworks try to improve this situation.

The Language Implementation System on Attribute Grammars (LISA) [88] uses at-tribute grammars not only to generate a compiler or interpreter. A large number of differ-ent tools can be generated by the Java based LISA tool including a syntax aware editor orfinite state automate visualization editors. One reason for that is the possibility to separatesemantic rules from grammar production rules. This in addition to advanced templates andinheritance formalism support for grammars allows better modularization. Another part ofLISA is debugger generation, although this was not a target for LISA and is therefore onlyrudimentary.

MetaEnvironment - ASF+SDF, TIDE, AspectAsf

While LISA is based on attribute grammars the MetaEnvironment [169] is based on alge-braic specifications. It has been in development for several years and had several rewrites,but can be considered stable today. The most important subpart is ASF+SDF (algebraicspecification formalism and syntax definition formalism) allowing a integrated but stillmodularized definition of language syntax and semantics. ASF+SDF delivers executablespecifications based on conditional equations and term rewriting20. Other important partsare a SGLR parser, the ToolBus for coordinating different tools and ATerms, a format toexchange annotated trees between the several tools. Based on this foundation the MetaEn-vironment can generate interpreters, editors or pretty printers for DSLs.

With the ToolBus Integrated Debugging Environment (TIDE) [170] it is also possible toget debugging support for a DSL, but it still needs several manual steps. Another solutionto get debug support is AspectAsf [143]. AspectAsf annotates the grammar with all pos-sible debug actions at every potential place, This increased the complexity of the resultinggrammar.

The MetaEnvironment aims to reduce development effort for new languages, but thedeveloper has to learn the complex ASF+SDF formalism. Additionally the MetaEnviron-ment has grown over the years to a large collection of components making the frameworkflexible and generic but decreasing the ease of maintenance. Due the flexibility learningand mastering the environment is difficult. The MetaEnvironment is only available forLinux based systems.

Strongly related to the MetaEnvironment is Stratego/XT21 [177], which is based onSDF, too. It uses a different and more powerful language for term rewriting. With it differ-ent tools can be generated. Stratego is even more complex due to highly advanced concepts.The MetaEnvironment and LISA are both suited to implement DSLs and moreover GPLsor can be used for program transformations.

20An extended explanation can be found in [107]21Stratego is the language and XT is a tool collection.

21

Smarttools

As LISA SmartTools [13] is a development environment generator based on Java and itadditionally makes heavy use of XML. A DSL can be define as an AST22. This AST isin turn manipulated. From it SmartTools is capable of generating a structured editor, apretty-printer, a UML model and a parser specification. A debugger can not be generated,though.

Horn logic approach

An approach able to generate a compiler and even a profiler is presented in [180]. It is baseddenotational semantic and uses Horn logic where Horn logic code syntax and semantic areexecutable and yield an interpreter. This interpreter can be partially evaluated togetherwith a DSL program and resulting in compiled code. This approach is very powerful,though mathematical, and requires many theoretical skills from the DSL developer. Alsono surrounding toolset is generated.

DSL Debugging Framework

As manually building debugging tools for each new DSL is time consuming, Hu [187]proposes a DSL Debugging Framework (DDF) based on the Eclipse Debugger Platformand on DMS. A DSL grammar is defined with ANTLR. From this grammar a DSL parserand additional source mappings are generated. The mappings relate each DSL constructto the back-end code. A mapping component communicating with the Eclipse Debuggingperspective and the back-end debugger is derived of the mapping . The mapping instruc-tions are applied automatically to the grammar by aspects, by using DMS (a transformationsystem). They contain instructions which are inserted in the grammar actions. The aspectsare specified in AspectG, a language for modifying the ANTLR grammar.

DDF supports the generation of DSL debugger for imperative, declarative and hybridlanguages. Currently only Java as back-end and ANTLR as front-end are supported. More-over the actions are specified in Java. For this reasons the approach can be seen as ratherinflexible at the moment.

Other frameworks

Most of the presented frameworks and tools are based on previous research results. Forthe completeness a few should be mentioned: Draco [131]which allowed the creation ofa parser, transformer, optimizer, analyzer and pretty printer for a DSL in an integratedway, KHEPERA [67] which worked as a source-to-source translator, powered by a simpleAST constructing parser, a tree transformer and a pretty printer for the resulting trees andfurthermore Sprint [55] based on denotational semantics and partial evaluation of a DSLinterpreter. Other approaches will not be discussed but they are similar: APPLAB [26],DMS [20],smgn [104], Eli [97], SPARK [121] and TXL [50]. This list is by no meanscomplete and several other solutions exist.

22abstract syntax tree

22

Also some commercial solutions promise DSL development support by generating ed-itors,debuggers and other tool such as JetBrains MetaProgrammingSystem23 or Intention-alProgramming24. However non of these has reached production state or is available to thepublic.

2.2 Model-Driven EngineeringWhile section 2.1 focused on DSLs this section discusses Model-Driven Engi-neering. In the following the terms model, metamodel, metametamodel tech-nology space will be defined and several examples given. Afterwards a pos-sible formalization of the terms is presented. Then some key techniques aredescribed like domain specific modeling languages, transformations and gen-erators. Finally the Model-Driven Architecture will be described shortly in-cluding MOF, EMF/ECore and XMI.

Model-Driven Engineering25 (MDE) is a vision that moves the model into the center of thesoftware development process. Moreover any software artifact is considered a model ormodel element. While previous approaches used models for documentation or communi-cation of ideas, they are first class entities throughout the whole model-driven engineeringlife cycle [40]. MDE is an open and integrative approach not tied to a special standard,therefore different implementations exist.

The problem that should be solved is the growth of platform complexity beyond theability to mask it with current GPLs. MDE tries to capture what is often expressed in aninformal way (prose,diagrams) as formal model based specifications.

Key concepts to mitigate current software engineering problem are models, metamod-els, technology spaces, domain specific modeling languages and different kinds of modeltransformation like model to model or model-to-text26.

Model-Driven Engineering is currently only described informally but different formal-ization approaches are researched at the moment [68, 150].

2.2.1 Models - the foundation of MDEModel, Metamodel and Metametamodel

Models are the key artifact of MDE. For that reason the term model is defined first. Theword model has its etymological root in the Latin word modullus that is the diminutive ofmodus. Then again modus meant a special architectural constraint ratio between parts of abuilding. A general definition merely based on the etymological meaning is not easy. Todaythe interpretation of the word model strongly depends on the view point of the observer andhis domain.

23http://www.jetbrains.com/mps/24http://intentsoft.com/25 The often used term Model-Driven Development (MDD) is equivalent to MDE, but is a registered

trademark of OMG. Also used: model driven software development (MDSD) .26Often also called generators

23

As this thesis is a computer science thesis a definition from the computer scientistsGerbé and Bézivin [41] is used (a more general discussion of the model term can be foundin [24, 114, 156]).

“A model is a simplification of a system built with an intended goal in mind.The model should be able to answer questions in place of the actual system.”

While this serves as a starting point, Kleppe et al. [105] gives a definition even moredirected to MDE.

“A model is a description of a (part of) systems written in a well-definedlanguage. A well-defined language is a language with well-defined form (syn-tax), and meaning (semantics), which is suitable for automated interpretationby a computer.”

Kleppe speaks about a “well-defined language” which can be used to create a model. InMDE metamodels define how a model can look alike.

The word “meta” is Greek and means “above”, therefore the term metamodel can beinterpreted as a model describing another model27. To understand the term metamodel asimple analogy to languages is drawn. A language consists of words whose combinationis constraint by a grammar. If a sentence in a language is seen as one possible model, thedefinition of its structure, the grammar, can be seen as its metamodel. Earlier it was saidthat in MDE a metamodel defines how a model can lookalike, this can be more preciselyformulated as: a metamodel defines the constructs and rules usable to create a class ofmodels. This is consistent with the following definition :

“A meta-model is a model of a set of models.” [69]

“A meta-model is a model that defines the language for expressing a model.”[135]

Notice that a metamodel is itself a model. If this is true the metamodel has also to bedefined in a “language” (needs a metamodel). For that reason the metametamodel is in-troduced, allowing to specify metamodels. The question which can be raised, is how themetametamodel is defined. To avoid an infinite stacking of meta levels, metametamodelsare often specified self reflexive and therefore the metamodel of the metametamodel is themetametamodel itself.

Most approaches implementing MDE define a three level meta stack - model, meta-model, metametamodel. A metamodel can be used to clearly define a class of models andthe metametamodel should allow the specification of all possible metamodels includingitself. Therefore one metametamodel should be enough.

The one metametamodel needs still to be defined. Currently different models com-pete: the MetaObjectFacility (MOF [135]), the Kernel Metametamodel (KM3 [93]), EMF

27It is important to differentiate between a model about a model and a model of a model. While a paintingof a painting showing a house can be seen as a model of a model it does not describe for example of whatcolors can be used in a painting.

24

MDEimplementation

Main contributor Metametamodels Tools

Model-DrivenArchitec-

ture(MDA)

OMG MOF, ECore,KM3, SMD,

Kermeta

Eclipse EMF

SoftwareFactories

Microsoft unnamed Microsoft DSLTools

Model IntegratedComputing

(MIC)

University ofVanderbilt

MetaGME GME

Model CentricSoftware

engineering

Lockheed ? Lockheedinternal

Table 2.3: Different MDE implementations, different metametamodels

ECore [37], MetaGME [119], the Coral Simple Metamodel Description (SMD [8]), Ker-meta [146], the Microsoft DSL Tools Metametamodel [127] and many others. All servea certain MDE implementation as metametamodel but differ in expressiveness. Unifyingthese or enabling translation between them will mitigate fragmentation in the long term.Different approaches have already been made [42, 43, 79] to bridge metametamodels forinstance MDA to MIC or MDA to Microsoft DSL Tools and vice versa. Yet as Bézivinstates [45] simple translation does not solve all fragmentation problems and is an area ofongoing research.

On the end of this section it should be mentioned that the described terms are stillsubjects of philosophical debates. For slightly different views [24, 39, 69, 70, 148] aregood starting points.

Technological spaces

Different notations like BNF, XML Schema or Ontology’s description can be seen asmetametamodel, too (for grammars respective XML documents or ontologies). This de-pends on the technological space (TS) under consideration. Technological spaces wereintroduced in [116]. The idea is having an abstract base to reason about similarities, differ-ences and integrations possibilities for different technologies. The following definition isgiven by Kurtev et al. [117]:

“A technical space is a model management framework with a set of toolsthat operate on the models definable within the framework.”

Kurtev continues with the observation that each technology space is based on a three-levelmetamodeling stack (model, metamodel and metametamodel) as can be seen in figure 2.3.This has already been described for the model technological space (MDE or ModelWare in

25

general) but is also true for technological spaces such as DataWare, GrammarWare [106]or XMLWare.

Layer 3

Layer 2

Layer 1

MOF

UML

metamodel

UML model

EBNF

a C program

C Grammar

XML Schema

XML Schema

Definition

a XML

document

conformsToconformsTo

conformsToconformsTo

conformsTo conformsTo conformsTo

Technology space

OMG/MDA Grammar XML

Figure 2.3: Different technological space and the metamodeling stacks

As different metametamodels exist, various frameworks, languages and tools are avail-able for generation and transformation.

Formalization

Currently the terms model, metamodel and metametamodel have only been defined infor-mal. Kurtev et al. [117] propose a formal definition of these terms. This is done out ofan organizational point of view (as a set of graphs constrained by other graphs). If in theremainder of this thesis is referred to the mentioned terms the beneath definitions shouldbe used.

Definition 2.1: A directed multigraph G = (NG, EG, ΓG) consists of a set of nodes NG, aset of edges EG, and a mapping function ΓG : EG → NG ×NG.

Definition 2.2: A model M = (G, ω, µ) is a triple where: G = (NG, EG, ΓG) is a directedmultigraph, ω is itself a model (called the reference model of M ) associated to a graph

26

Gω = (Nω, Eω, Γv) and µ : NG ∪ EG → Nωis a function associating elements (nodes andedges) of G to nodes of Gω. The relation between a model and its reference model is calledconformance. We denote it as conformsTo28.

Definition 2.3: A metametamodel is a model that is its own reference model (i.e. it con-forms to itself).

Definition 2.4: A metamodel is a model such that its reference model is a metametamodel.

Definition 2.5: A terminal model is a model such that its reference model is a metamodel.

2.2.2 Domain specific modeling languagesThe ideas behind domain specific modeling languages (DSML) and domain specific mod-eling are similar to the DSL concepts presented in 2.1 but applied to the world of models.Whereas in DSLs the language, its textual representation, is domain specific, in DSM29 themodels are domain specific. In comparison with DSLs the representation is almost in everycase graphical. The gained benefits are similar, too.

UML according to its name a unified modeling languages tries to offer a set of differ-ent model types able to describe every imaginable domain. Yet often the UML or othertraditional modeling languages lack the facilities to precisely capture domain knowledgeleading to abuse and a large number of proposed extensions [124, 137]. The recent versionof UML allows the modification by profiles, enabling specialization. Of greater importanceis the fact that UML diagram types are now based on a single metamodel30 (MOF).

Using a metamodel for the definition of a DSML offers a number of advantages:

• Decreased development effort for visualization and editors because of a commonmetamodel

• Model verification and checking according to a metamodel with available tools [144]

• The DSML stays extensible (for example SysML based on the UML2 metamodel[137])

• Uniform exchange formats exist (like XMI) and a next generation model exchangeis proposed [111]

• Approaches for models comparison based on a metamodel exist [110, 123]

• The semantics of a DSML can be described by a metamodel [60]

28Alternatively instanceOf is also correct.29Domain Specific Modeling30In this case MOF is the metamodel for the definition of the definition of what elements can exist in a

diagram or simply the metamodel of the DSML. If the definition of what kind of elements can exist is treatedas a metamodel, MOF is its metametamodel. It depends on the point of view when MOF is treated as model,metamodel or metametamodel.

27

Name Metamodel informationEclipse EMF/GMF ECore/XML Schema XMI support, complex but most

complete and powerful compared withothers [11]

MetaEdit+ GOPRR customizable diagram editor includingelement constraints

Generic ModelingEnvironment

MetaGME OCL and XMI support, completegraphical customization possible

Generic EclipseModeling System

ECore based on Eclipse GMF, a large number ofDSML development steps is automated

in comparison to raw GMF.XMF-Mosaic MOF/XCore based on Eclipse, editors customizable,

OCL supportTau G2 MOF/UML DSML are created by defining UML 2.0

profiles through extending the UMLmetamodel. Modification of graphicalrepresentation is restricted to model

elements (for example link could not becustomized).

Rational SoftwareArchitect

MOF/UML DSML are created by defining UML 2.0profiles but only stereotypes are possible.

Graphical representation is even morerestricted then Tau G2.

MagicDraw 12.0 MOF/UML extension by UML 2.0 profiles, API fordefining custom diagram elements

Microsoft DSL Tools unnamed plugin for Visual Studio.Net,representation completely customizable

Table 2.4: Different tools for creating DSML

Current tools

A large number of tools usable to specify and then use a DSML are available. They allowto define allowed elements and how their graphical representation look like. Most of themare based either on the ECore or the MOF. A detailed view goes beyond this thesis but afew are listed in table 2.4.

Earlier approaches

The described approach to modeling a specific domain is not new. Already CASE toolsimplemented many of the ideas. In contradiction to the described DSML tools however theywere based on proprietary modeling languages, metamodels and ineffective code generatorand failed for this reasons [82].

“Most of these tools did not take advantage of platform-specific features,

28

and produced naive, inefficient, least common denominator code. The upfrontcosts of adopting the modeling techniques they required were prohibitivelylarge. Added to this was the risk inherent in spending a substantial portionof the projects budget building models with the promise of code appearingonly in later stages. This required enormous confidence in the tools and in thelongevity of their vendors. Also, concepts like round-trip engineering, where amodel could be synchronized with changes made independently to the code ithad generated from them, were overwhelmingly complex. Another criticismwas that many CASE tools imposed a methodical top-down process. Thiswas the ultimate kiss of death, since rapid iteration of partial solutions hasproven to be critically important to the success of application development, asso clearly demonstrated by agile development methods.” [21]

2.2.3 Generators and transformationsTransformations and generators allow to synthesize different artifacts such as source codeor alternative model representations and also transform traceable between different mod-els with the possibility to ensure consistency. Furthermore it opens the possibility to domodel refactoring, specialization, annotation or model aspect weaving. Transformationsand generators are enabled by metamodels.

Generators

In general most available generators can be categorized as either template or visitor based.Often generators are referred to as model-to-text transformations. Template based genera-tors replace certain parts inside a template document with information from the model. Oneinstance of a template based generator is JET which is part of the EMF. Additional to JETthere are a large number of different template based generators like MOFScript, XPand orAcceleo which are focused on model-to-text or more general ones such as Smarty, Con-template, Cheetah, Jinja, Savant, or Liquid to name only a few.

The visitor approach works as described by the visitor pattern [78], though the visiteeis the model. Each model element is visited and an according action is triggered. In thecontext of the current visited model element specific text is generated.

Another approach, falling under the category of template generators but less frequentlyused are generative grammars. The main idea is to use grammars as in compiler generatortools, but reverse the direction. While in compiler tools a lexer and a parser are generatedbeing able to consume arbitrary text conforming to the grammar, reverse grammar toolsgenerate text conforming to the grammar, according to given model (input data). Suchtools are ST [140] or Anti-Yacc [87].

29

Approach ToolsTemplate AndroMDA[128], FUUT-je[173],

OptimalJ31, Xpand32, ArcStyler33,MOFScript34, Acceleo35

Generative ST [140], Anti-Yacc [87]

Table 2.5: Different model-to-text approaches

Tool DescriptionAndroMDA, FUUT-je, OptimalJ template engines based on UML

MOFScript, XPand, Acceleotemplate engines based on MOF,more flexible then UML based

engines

Smarty36, Contemplate37,Cheetah38, Jinja39, Savant40, or

Liquid41

general applicable templateengines, no special MDE support

ST, Anti-Yacc generative grammar engines, nospecial MDE support

Table 2.6: Different generator tools

Transformations

Transformations and the executing systems can be grouped by different criteria, for ex-ample whether they are imperative or declarative, how many input and output models areinvolve, are they horizontal42 or vertical43, whether they directly manipulate44 a model, are

31http://www.compuware.com/products/optimalj/32http://www.openarchitectureware.org/33http://www.interactive-objects.com/34http://www.eclipse.org/gmt/mofscript/35http://www.acceleo.org/36http://smarty.php.net/37http://www.typea.net/software/contemplate/assembled/home.html38http://www.cheetahtemplate.org/39http://wsgiarea.pocoo.org/jinja/http://smarty.php.net/40http://phpsavant.com/yawiki/http://smarty.php.net/41http://home.leetsoft.com/liquid42The source and the target model share the abstraction level, for example when a refactoring is performed.43Source and target model exist on a different abstraction level, for example a refinement.44The user has to implement transformation rules and sequence trough API calls in a GPL like Java, which

directly modify the model.

30

Technology space Metametamodel Standard / ToolsMDA/EMF MOF/ECore QVT [136], ATL [95], Tefkat [118],

YATL [142], MTF45, UMT[83], BOTL[31], MOLA [98], SmartQVT46, BorlandTogetherQVT47, MiA48, MTRANS[145]

XML Schema XSLT49

Grammar Grammar in (E)BNF ANTLR AST Transform50, TXL [50],ASF+SDF [169]

Data - SQLGraph different AGG51, GReaT [6], Viatra, PROGRES

[155], Groove, FUJABA [179]

Table 2.7: Transformation engines from different technology spaces

described via algebraic relations, are graph based or using a hybrid approach. Which ofthe techniques is most appropriated? That has to be decided depending on the require-ments. Mens and Gorp proposed a taxonomy [125] that can help with this decision. Againthe technology space has to be considered. Is the transformation intra or inter technol-ogy space? An intra-TS transformation for example would be a transformation XML toXML performed with XSLT and XQuery. An intra-TS transformation could be UML toXML[178].

A large number of model-to-model transformation frameworks have been developedlately, caused by a growing interest in MDA/MOF/EMF and MDE in general. The OMGproposed the Query View and Transform (QVT) standard based on MOF. There are severalimplementations claiming to be compliant with QVT up to a certain level. Nonetheless,there exists no complete implementation of the standard version 1.0 today. The most ad-vanced freely available implementation is the Atlas Transformation Language(ATL).

Note that transformations themselves can be expressed as models [44]. These mod-els are called transformations models and behave like regular models. They conform toa transformation metamodel and can be transformed themselves (metatransformations orhigh order transformations).

While there are several attempts to classify [53] or benchmark [175] different modeltransformation approaches, an exhaustive comparison of the various transformation tech-nologies is still pending but would be of great use.

45http://www.alphaworks.ibm.com/tech/mtf46http://sourceforge.net/projects/smartqvt47http://www.borland.com/de/products/together/index.html48http://www.mia-software.com/miaStudio/indexOfMiaStudio.php?lang=

en&theme=prod-miagen49http://www.w3.org/TR/xslt50http://www.antlr.org/doc/sor.html51http://tfs.cs.tu-berlin.de/agg

31

Tool DescriptionYATL part of the Kent Modeling Framework, textual, MOF

based, declarative/imperative hybridMOLA visual language, simple and loop patternsBOTL bijective, visual language, declarative, object oriented

mathematical foundationTefkat textual, declarative/imperative hybrid, based on theory of

stratified logic programsATL ATLAS Transformation Language, based on ECore EMF

metametamodel, very actively developed,declarative/imperative hybrid

MTRANS textual, MOF based, translated into XSLT which modifiesXMI

UMLX graph bases, visual language, only for UML models,translated into XSLT which modifies XMI

BOTL graph based, bidirectional, only for UML modelsViatra2 graph based and abstract state machine based hybrid,

pre/post conditions for a transformation, recursive andnegative pattern support

VMT graph based, visual language, declarativeMISTRAL [115] MOF based, textual, declarative/imperative hybrid

Table 2.8: Some model-to-model transformers

2.2.4 Different MDE technologies in detailMOF

As described in Section 2.2.2 different metametamodels exist. A well-known one is de-scribed in the OMG Meta Object Facility (MOF) standard. The idea behind MOF is afour-layered architecture as depicted in figure 2.4. Sometimes it is referred to as a closedmetamodeling architecture because the defined metametamodel conforms to itself. Cur-rently with version 2.0 different flavors of the MOF exist: the Complete MOF (CMOF),the Essential MOF (EMOF) and the Semantic MOF. CMOF is the whole MOF whereasEMOF is only a subset of the most important elements.

The widespread use of the Universal Modeling Language (UML) is one of the reasonsfor the recent popularity of MOF. The current version is the base for UML2. All differentdiagram types are defined conforming to the metamodel. The MOF is the foundation forOMG Model Driven Architecture52 (MDA), too.

52The term Model Driven Architecture is misleading. While the part “Model Driven” has its explicitmeaning in the systematic use of models, the part “Architecture” was chosen by accident [70]. In contrast towhat could be assumed to be “Architecture” it does not mean software architecture in this case. The OMGhas been criticized more than once for the misleading naming. In fact the etymology of MDA derives fromthe renaming of the earlier Object Management Architecture (OMA) to MDA. However the OMG sometimesrefers by architecture to their “four layer architecture”.

32

M3: metametamodel

(MOF)

M2: metamodel

(UML metamodel)

M1: model

(UML Class)

M0: object

describesconformsTo

instanceOf

conformsTo

instanceOf

conformsTo

instanceOf

describes

describes

conformsTo

instanceOf

describes

Figure 2.4: Example of MOF layers

MDA

The original idea behind MDA is to separate design from architecture with the help ofmodels on different abstraction levels. MDA proposes Platform Independent (PIM) andPlatform Specific Models (PSM). Where PIMs express a higher abstraction level, leavingout implementation details and PSMs describe lower levels including platform specifics.The PSM should be almost generated automatically by transforming a PIM.

In practice this approach causes problems. The standards that MDA is based upon(UML, MOF, OCL53, QVT, ...) are complex and incomplete at the moment. For examplethe transformation standard QVT has no fully compliant implementation right now andthere exists no standard for action semantics. Another problem is that interoperabilitybetween MDA tools is often problematic. Not every vendor implements all OMG standardscorrectly, moreover sometimes the specifications are not precise enough. Furthermore nopractical tool environment is available for the MOF leading to the abuse of UML tools (todefine class diagrams (terminal models) which would be then translated or interpreted asmetamodels).

53Object Constraint Language

33

PIM

PIM to PSM Transformation

Engine

PIM PSM CodeCode

PSM to Code Transformation

Engine

Figure 2.5: MDA PIM to PSM (FMC)

Eclipse / EMF

There are several tools and framework following the MDA approach and leveraging stan-dards from the OMG. A prominent example is the Eclipse Modeling Project (EMF), aframework for modeling and code generation. EMF is one of the most successful ap-proaches to MDE. Since 2002 it has been developed [37] and integrated into the EclipsePlatform (now version 2.2). In contrast to the MDA proposal the metametamodel usedis ECore. EMF is split into three large components: core, edit and codegen. While corecontains the ECore metametamodel, persistence, serialization, a model tracer (change no-tification and recording) and a validation framework, edit includes a default model viewerand helps in building rich user interfaces (view, editor) for models and codegen supplies acode generator for ECore based models and several importers (for example from RationalRose).

On top of EMF a number of other frameworks are build, like GEF (Graphical EditorFramework) allowing to create graphical editor and GMF (Graphical Modeling Frame-work) for creating a domain specific modeling language editor.

ECore - EMF metametamodel

ECore is the metametamodel of EMF. In the initial development of EMF, MOF should havebeen used as the metametamodel but was dismissed in favor for ECore. It was developed asMOF 1.x was to complex and did not fit to the needs of EMF developers. Therefore ECoreis much simpler than MOF 1.4. MOF evolved, tough. And with version 2.0 differentmetametamodel flavors were developed. Interestingly the EMOF was developed in parallelto the ECore/EMF development with a steady exchange of ideas. So EMOF is stronglyaligned to ECore, and has only minor differences. EMF can read, use, manipulate andwrite EMOF based models equally well as native ECore Models.

ECore is described in ECore itself. Figure 2.6 shows the complete model (version 2.2).

MOF / ECore Model exchange formats - XMI, HUTN, emfantic and KM3

For the exchange of metadata information like models or metamodel the OMG has definedthe XML Metadata Interchange Standard (XMI). The current version is 2.1. This standarddescribes how any model (MOF compliant) can be mapped to XML. Additionally it alsoshows how a schema can be automatically generated of the MOF model to represent anyMOF compliant model. That allows the validation of model data which is stored as XML.

34

Figu

re2.

6:E

Cor

em

etam

etam

odel

35

At first the primary goal of XMI was UML model exchange. Today it is used to ex-change all kinds of models. In figure 2.7 different applications in need to exchange modelsand the advantages of a standard for exchange (in this case XMI) are shown.

Application

Application

Application

Application

Application

Application

Application

Application

Application

Application

Application

Application

Application

Application

Application

Application

XMI

Figure 2.7: XMI used for exchange.

XMI suffers from some practical problems. Again there are incompatibilities betweendifferent XMI implementations of different vendors that need to be resolved. Another prob-lem is that a great number of models being exchanged (most UML drawings for example)are concrete models. Most of the times these models have a visual representation. In thisrepresentation layout information, colors and shapes are often important to the user. Butthese information are not part of the model (itself). For example UML2 defines class di-agrams but the visual representation or a way how to exchange it is nowhere specified.To solve this problem the OMG defined the Diagram Interchange (DI, XMI-DI) standard,which captures visual information. At the moment DI is not widely implemented by toolsvendors. Nevertheless there are several efforts to optimize the support. In the meantimemodel exchange including visual representation is not working seamlessly between differ-ent vendor tools.

XMI suffers not only of slow implementation. It is difficulty to read and write manuallywithout tools support. The OMG therefore proposed the Human-Usable Textual Notation(HUTN) [134]. This language allows description and exchange of MOF models in a waywhich is more comfortable to read and to write than XMI. It was primarily targeted forwriting textual UML. It failed because of UMLs complex metamodel. The author of thisthesis only knows two implementations of HUTN: TokTok (out-dated54) [4] and HUTNKermeta (prototype) [129].

With Emfatic55 a similar human friendly notation for ECore exists. The current versionis 0.0.2 and no development occurred since 2004. It can still be considered as usable (withEclipse 3.0).

As stated before ECore is closely aligned to EMOF. The EMF offers XMI support forECore as its main exchange format. This benefits the interchangeability of ECore Models.

54It is based on an old dMOF specification.55http://www.alphaworks.ibm.com/tech/emfatic

36

Yet the ECore XMI implementation has some minor anomalies, as described in section4.4.6.

Another possibility to exchange metamodels is KM3. The Kernel MetaMetaModel isa textual language for specifying metamodels. KM3 as metametamodel resembles ECore,only stripping out Java related entities. It can be converted to and from ECore/Emfatic/XMIautomatically and serve as a persistence format for metamodels. In contraction to XMI itis not possible to store a instance of a metamodel with KM3.

2.3 Model-driven DSL developmentThis section will show two DSLs implemented with an Model-Driven En-

gineering approach. After the concrete DSLs various model-driven DSL frame-works will be presented, which allow the definition of a textual language.

2.3.1 Model-driven DSLs by exampleTwo DSL implemented using an MDE approach are WebML [46] and SPL [151].

WebML

WebML is a language for expressing the structure of web applications with a high-leveldescription. It offers different models, together forming a website: structure, derivation,composition, navigation and presentation model. Earlier versions of WebML were basedon implicit metamodels contained inside the WebRation tool in form of a DTD. This ap-proach suffers from the of verbosity and limitation of DTD. Moreover because no explicitmetamodel exist, the profits gained by MDE, like a common exchange format or powerfulmodel transformations are not available. Recently a ECore based metamodel was pro-posed and implemented [152] to overcome these constraint. The metamodel was derivedsemi-automatically of the DTD. Based on that metamodel WebML was further evolved forexample the addition of aspect oriented concepts.

SPL

One step further goes Ruscio et al. [151] with the Session Processing Language (SPL) [38].This language is designed for implementing telephony services over the Session InitiationProtocol (SIP). The Atlas Model Management Architecture (AMMA) is used to implementSPL. AMMA is based on Eclipse and has a strong connection to EMF. The earlier describedKM3 and the ATL are part of AMMA. While KM3 is needed to define the metamodels andATL for different transformation, two more parts play an important role. The concretesyntax to domain model mapping is done by TCS which will be described in 2.3.2.

Most other MDE implemented DSLs end here. For SPL also the (dynamic) semanticis described by model-based abstract state machines (defined by a metamodel based onXASM [12]). This is a novel strategy because even for languages such as UML or MOF

37

the semantic is only defined by prose56. Only a small number of other approaches areknown to the author: Kermeta which extends MOF with operations to define operationalsemantic and the denotational metamodeling approaches by Hausmann [86] and Alvarez[10].

2.3.2 Model-based domain specific language toolsMDE based approaches to DSL development are still a field of ongoing research. Frame-works or toolset already being usable are XText/oAW, Kermeta TCS/AMMA and TCSSL.

Atlas Model Management Architecture

AMMA was discussed as framework used for the implementation of SPL. To rephrase, itconsists of the parts KM3, ATL, AM3 (model management) and TCS (Textual ConcreteSyntax) [94] and is based on the Eclipse Modeling Framework. As KM3 and ATL werediscussed before and AM3 is not of importance, TCS will be discussed more in detail.

TCS allows definition of textual syntax for models and was introduced [96] in October2006. It is a submission for the Eclipse Textual Modeling Framework (TMF) call forproposals. At the time of writing of this thesis TCS was not publicly available. It worksby associating syntactical elements with elements of the domain metamodel. From thisinformation an ANTLR grammar is generated. The parser derived from this grammar isable to consume a DSL program and deliver its representation as a model conforming tothe metamodel. This component is also called injector. The second component of TCSis the extractor. It implements model-to-text generation. No additional specification isneeded. A model, its metamodel and the TCS syntax mapping are used to generate atextual representation. This is novel as most other approaches separate this into two distinctsteps: a model conforming to a meta model is create manually by using grammarwarelike yacc. Then the grammar is annotated with special actions creating model elements.Finally another tool like JET is used for model-to-text transformation. With TCS onlythe metamodel and the syntactic mapping are required for text-to-model and additionallya valid model for mode-to-text transformation. The syntax mapping consists of a templatefile defining the mapping for each metamodel element. Different mappings are available:

• PrimitiveTemplates describe lexer tokens for a KM3 DataType inside the metamodel

• ClassTemplates describes syntactical elements that are used for KM3 Classes insidethe metamodel. This could be keywords, special symbols and properties. Whereproperties correspond to structural feature inside the KM3 Class.

• Abstract ClassTemplates enabling navigation inside the inheritance hierarchy

• Conditionals constraining the existence of a sequence by a condition

• Operators with priority, associativity and a symbol

56One exception is the semantic model verification with constraints formulated within OCL.

38

Metamodel elements are identified by name inside the TCS. For a better understanding thelistings 2.1 and 2.2 show an excerpt from the metamodel in KM3 and the mapping in TCSfor the SPL language, taken from [96].

1 d a t a t y p e S t r i n g ;

3 c l a s s Program ex tends Loca t edE lemen t {r e f e r e n c e s e r v i c e c o n t a i n e r : S e r v i c e ;

5 }

7 c l a s s S e r v i c e ex tends Loca t edE lemen t {a t t r i b u t e name : S t r i n g ;

9 r e f e r e n c e d e c l a r a t i o n s [∗ ] o r d e r e d c o n t a i n e r : D e c l a r a t i o n ;r e f e r e n c e s e s s i o n s [∗ ] o r d e r e d c o n t a i n e r : S e s s i o n ;

11 }

Listing 2.1: SPL metamodel

1 p r i m i t i v e T e m p l a t e i d e n t i f i e r f o r S t r i n g d e f a l u t u s i n g NAME;

3 t e m p l a t e Program main: s e r v i c e

5 ;

7 t e m p l a t e S e r v i c e: " s e r v i c e " name " { "

9 " p r o c e s s i n g " " { "d e c l a r a t i o n s

11 s e s s i o n s" } "

13 " } ";

Listing 2.2: SPL TCS template specification

TCS also has some limitations. The possible languages are restricted by the parsergenerator and therefore the supported grammar class. The used ANTLR version has thepower of LL(k). Furthermore error reporting is currently insufficient. It is possible to createambiguous grammars. ANTLR recognizes this problem, but the error is not propagated upto the corresponding rule inside TCS or the KM3 metamodel. If the metamodel differsstrongly from the desired syntax, the mapping gets difficult and is sometimes not possibledue to limitations of TCS. For example it is currently impossible to create blank delimited57

or case insensitive languages.The AMMA platform itself does not offer a way to describe the dynamic semantics

and no debugger can be generated. However an editor TGE (Textual Generic Editor)parametrizable by a TCS file, offers outlining, syntax highlighting and hyperlinking forany in TCS defined DSL is available.

Notably the approach chosen in TCS is similar to the framework described in this thesis.As both were developed independently this supports some of the later described designdecisions.

open ArchitectureWare

Open ArchitectureWare (oAW) is another Eclipse based platform suited to develop DSLcorresponding to the MDE approach. The current version is 4.1, it is based on the ECore

57An example for a blank delimited GPL is Python. A blank delimited DSL is YAML.

39

metamodel58 and consists of a set of tools which can interact with each other:

• Xpand a statically typed template language for model-to-text transformation withsupport for template polymorphism and template aspects. It is comparable to anymodern template engine for instance Velocity or Smarty.

• Xtend a DSL for extending metamodels, for example with custom properties for ametaclass. It is use for template modularization and also enables aspect-orientedtemplates59. As of version 4.1 Xtend can also be used for functional style model-to-model transformations. However only simple and limited transformations are possi-ble in comparison to ATL.

• Check for defining declarative constraints over a model and checking them. (Similarto OCL).

• XText enables text-to-model transformations and was also submitted as a proposalfor TMF. In contrast to TCS the metamodel is derived from a XText grammar file.The grammar describes the syntax of the DSL and is then transformed to a ANTLRgrammar and a ECore metamodel. The parser generated of the ANTLR grammarcreates model elements conforming to the metamodel. The generated metamodelcorresponds to an AST specification for the DSL. This approach suffers of the in-ability to create a custom metamodel. The authors propose [64] to transform fromthe generated metamodel into a “real” metamodel. This helps separating concerns(parsing, linking60) but additional effort is needed compared to TCS. Furthermorethe XText language itself is limited, so only simple DSLs are possible. The XTextgrammar which is similar to BNF consists of a set of rules. Each rule can be com-posed out of a combination of three token types(keyword, identifier or string) andreferences to other rules. Modifiers such as multiplicity, optionality or alternationare available. How a string token or a identifier token is build, is not customizable,nevertheless it is possible to define a simple custom token type for strings. XTextgenerates an Eclipse based editor including an outline view, syntax highlighting andchecking for a DSL.

• A workflow engine which can be used to coordinate the different parts.

The oAW framework offers integration with Eclipse GMF. Xpand and Xtend are alreadyused successfully in MDE environments, however not many DSL based on XText expect ofa abstract state machine example and an overly simple example of describing an ADT61 areknown to the author. Moreover the use of XText is limited because only simple grammarscan be formulated and the according metamodel is build automatically and can not becustomized.

58oAW comes also with its own metametamodel.59Extensions can be applied to the metamodel in an aspect like fashion.60The proposed term for AST metamodel to domain metamodel transformation.61Abstract Data Type

40

Kermeta

Kermeta [76] is also based on the Eclipse platform and allows the definition of a domainspecific language. However only a graphical representation is possible. The metameta-model used is derived from EMOF and extended by a behavior package. Therefore inKermeta it is possible to specify the semantic behind a model, using the Kermeta language,a DSL which directly maps to the behavior model. Moreover it is possible to transform aKermeta model which contains semantic information into an ECore model. The semanticis preserved within ECore annotation. This approach is interesting because it contains amodel-based representation of semantic information similar to the SPL example. Yet itis not possible to create a customizable textual representation for the model itself and thereason why Kermeta is included in this discussion is because in comparison to the otherframeworks it is possible to describe the language semantics in a model-driven way.

TCSSL

The Textual Concrete Syntax Specification Language (TCSSL) [73] is a metamodel-awarespecification language for grammars. It promises a bidirectional mapping text-to-modelmapping. A new grammar language consisting of three different types of rules is proposed:

• Simple rules are EBNF rules instantiating a model element.

• Seek rules are used to resolve references by looking for existing model elementsmatching a given condition.

• Singleton rules work like simple rules but do not instantiate a new model element ifan instance already exists.

In addition several elements a rule can contain like alternatives, actions with guards, modelexpression (inside a language such as Kermeta or MTF), model queries (side effect freeexpressions), sub rule calls or multiplicities are defined.

At the moment only a prototype implementation of TCSSL exists in Java, based onANTLR and EMF Jet. ANTLR rules are mapped to TCSSL rules one to one and their ac-tions contain TCSSL specific code. Complex queries and expressions are not implemented.The model-to-text transformation is handled by simple EMF templates, where each tem-plate must be associated with a rule, this makes indention handling tricky because JET isnot completely controllable.

Moreover the authors make no statements about the used lexer and use a standard im-plementation in all cases. This problem and the JET generator will cause the same problemsas already seen with TCS such as no support of blank delimited languages or no standardtoken types. The implementation is not available to the public.

Other approaches

Currently a number of different frameworks for model-driven DSL implementation aredeveloped. While documentation for XText, TCS and TCSSL is available to some extend

41

1 s y n t a x UMLSta techa r t sw i th d e f a u l t L a n g u a g e KerMeta ;

3e n t r y r u l e f o r S t a t e M a c h i n e : : =

5 " S t a t e M a c h i n e " s e l f . name

7 s e l f . t o p ;

9 r u l e f o r S i m p l e S t a t e : : = < i n i t a l >" S t a t e " s e l f . name;

11r u l e f o r C o m p o s i t S t a t e : : =

13 < i n i t i a l >" C o m p o s i t e S t a t e " s e l f . name " { "mixed ( s e l f . s t a t e | | s e l f . t r a n s i t i o n )

15 " } ";

17m a c r o r u l e i n i t a l : : =

19 (<< { s e l f } . i s I n i t a l : : = { t rue } >>" i n i t i a l "| _

21 ) ;

23 r u l e f o r T r a n s i t i o n : : =" T r a n s i t i o n " s e l f . name " from " s e l f . sou rce <name>

25 " t o " s e l f . t a r g e t <name> ( s e l f . e v e n t o pe n e r " on " );

27s e e k r u l e name f o r S t a t e wi th c r i t e r i u m { s e l f . name} : : =

29 [ 1 ] ( s e l f . name ) ;

31 s i n g l e t o n r u l e f o r Event wi th c r i t e r i u m { s e l f . name} : : =[ 1 ] ( s e l f . name ) ;

Listing 2.3: A TCSSL grammar example

this is not the case for some newer frameworks like IBM SAFARI[47] or TEF62.The initial presentation of SAFARI was at the EclispeCon 200663 / GPCE’0664 but no

documentation and no public binary/source code access is available. SAFARI allows thegeneration of Eclipse based DSL environments offering a rich user experience such as syn-tax highlighting, source-text folding, hyperlink detection, content outlining, content assist,hover annotations, hover help, parsing, and project building. The DSL has to be specifiedusing the LPG65 parser generator. Furthermore parsing support includes incremental scan-ning and parsing, and grammar-directed error recovery. SAFARI also provides support fordebugging breakpoints (via JSR 04566) and a framework of components for multi-languagestatic analysis. If all of the named feature work as promised, SAFARI is a powerful alter-native to the other presented frameworks, however the author of this thesis could not proveany of these statements as only a short introduction paper is accessible.

The Textual Editing Framework (TEF) is announced by the Humbolt-University ofBerlin and offers similar feature as SAFARI. Yet only a website and the source code ofa unusable alpha version is available at the moment. TEF is also based on Eclipse andallows the generation of convenient DSL editor.

62http://www2.informatik.hu-berlin.de/sam/meta-tools/tef/tool.html63http://www.eclipsecon.org/2006/64http://www.program-transformation.org/GPCE06/WebHome65http://sourceforge.net/projects/lpg66http://jcp.org/aboutJava/communityprocess/review/jsr045/index.html

42

2.4 SummaryA large number of solutions for DSL development are available. Most of them do notsupport a model-driven approach. Those of them which do lack some important features.Non of the model-driven frameworks is able to generate a debugger. In XText the domainmodel is generated automatically and it is not possible to use a custom domain model. TCSallows the usage of a custom model and includes implicit mapping from text-to-model andvice versa. Yet it is restricted to languages not differing so much from the model and hassome other arbitrary limitations such as no support for blank delimited languages. Theapproach TCSSL has taken is also interesting but premature Java based implementationdoes not make it an ideal solution. Moreover JET is an insufficient template engine andthe proposed language needs improvements (like a way to define influence lexer). Theframeworks SAFARI and TEF are interesting alternatives if they reach a matured statusand are made available to the public.

None of the discussed model-driven tools allows the reuse of existing grammars. In theremainder of this thesis some solutions for these problems are proposed.

43

Chapter 3

Domains in the automotive industry

After the concepts of domain specific languages and Model-Driven Engineer-ing have been discussed above, this section introduces specific domains insidethe automotive industry. This serves as a general background for a later de-scribed and implemented automotive domain specific language,

The key innovation areas in today’s automotive industry are software and electronics. Amodern car contains a multiplicity of connected controllers running under different kinds ofoperating systems. While the first software solutions inside a car were local and unrelated,today up to 70 bus interconnected ECUs1 can be found. Many different development toolsand frameworks are orchestrated. However the principles and methods of modern/efficientsoftware engineering are not sufficiently known and applied in this industry. Proprietarysolutions are used [29] and software reuse from one car generation to the next lies oftenbelow 10% [85].

The controllers used range from very limited low level sensors up to high level pro-cessors empowering multimedia functionality. They are interconnected by different bussystems such as CAN, MOST or FlexRay and have to be coordinated. Most of the con-trollers and their software are also constrained by real time , safety and always by costrequirements.

Additionally this complexity has not only to be managed for one car, but for variousmodels, product lines and equipment combinations. Furthermore the different stages ofdevelopment have to be coordinated from requirement analysis, architectural design to im-plementation and testing. A wide range of software development and management tools istherefore in use, each fitting a special domain. These tools are not always well integrated.

Currently in a number of different domains the supporting software is not sufficient withregard to not allowing the domain expert to express his intentions optimally. As depictedin 2.1.2 domain specific languages are often able to solve this problem. Despite that a largepart of the software development is still utilizes in C. Requirements engineering is still donein prose with tools like DOORs without any formal foundation2 and testing is realized by awide variety of tools, not inherently developed for testing. At least in some domains DSLshave emerged, for example ASCET-SD suited for the development of embedded controller

1Electronic Control Unit2For the MMI specification modeling guidelines exist, resulting in a semi formal description.

44

software. Compared to C it offers hierarchical state machines, block diagrams and pseudocode similar to Java to define control logic. Another example is Matlab/Simulink. Matlabis a DSL for numerical computing especially vector and matrix numerics. Simulink is anextension of Matlab. It allows modeling, simulation and analysis of multidomain dynamicsystems which are described by block diagrams. Message State Charts3 (MSC) an ITUstandard for modeling the communication behavior between distributed instances similarto UML sequence diagrams are used too. test cases are generated from these specifications.

One domain which can be found at the BMW Group Information and CommunicationSystems division is automation of multimedia oriented system testing. Currently a DSLexists but could be improved. This is explained in detail in 5.2.

3A textual and graphical representation is available.

45

Part II

Frodo

46

Chapter 4

One framework to bind them all?

“To achieve great things, two things are needed: a plan, and not quiteenough time.”1

One framework to bind them all? The answer to this question is the same as to the ques-tion after the silver bullet in software development. Since no silver bullet exists [33], noframework can satisfy all needs. Therefore the framework presented in this section tries toanswer a set of special questions. A large number of the them have aroused during analyz-ing available tools for DSL development and the current implementation of the TestDSL.

In general the framework should allow the implementation of domain specific lan-guages with a reduced effort and better reuse properties compared to other solutions.

4.1 Requirements and solutionsReusability As discussed in 2.1.8 the classic compiler/interpreter approaches to DSL de-

velopment often only utilizes a compiler generator. This raises the question of reusabil-ity. Almost all grammar definitions are tool specific. They depend on the chosensyntax and capabilities of the generator such as the the parser class. In some casesthe specification of syntax and semantic has to be done inside one grammar file (forexample Yacc/Lex). Possibilities for reuse are heavily limited. A modular approachto grammar definition improves this and is proposed and implemented by differentframeworks (see 2.1.9). These modularized artifacts are not interchangeable betweentools due to the already listed reasons. So the proposed framework therefore uses aModel-Driven Engineering solution to mitigate this problem. A grammar metamodelis suggested. If a model conforms to this metamodel a tool specific grammar can begenerated and the grammar can be modularized by separating concerns in differentmodels. As meta- and model are easily exchangeable in MDE they come with reusebuilt in. Other MDE tools can handle the models, offering visualization and edit ca-pabilities, applying transformations or deriving other artifacts. Many of the availabletools for DSL development tie the developer to a platform like LISA or ASF+SDF.Only a small number of them are MDE-enabled. Even the MDE-enabled tools have

1Leonard Bernstein

47

some problems for example XText suffers from the inability to define own domainmeta models. Only TCS which was published after the development of the proposedframework has equal properties.

Decrease development effort Another critical point is the needed skills of the DSL de-veloper. Developing a new DSL from scratch needs serious effort and knowledgein language design. On the other side, embedding a DSL inside another languagelike Ruby, needs less effort but has some disadvantages such as the syntax constraintof the host language and the missing deep of integration of domain concepts. Onepossible answer given by the framework which is also enabled through MDE is reuseagain. It allows the conversion of an existing grammar into a model of that grammar.A less experienced developer can extend or modify this model for example by addingnew constructs to the Java language. It is possible to develop a complete new DSL.Ideally this should work for syntax and semantics.

Usability Not only reuse, modularization and interchangeability with other tools can bequestioned. Today the users of modern IDEs are accustomed to syntax highlighting,code completion, refactoring and deeply integrated debugging capabilities. Theseare standards in IDEs like Microsoft Visual Studio.net or Eclipse. Just a small num-ber of DSL tools have a solution for this demand. Most compiler compiler onlyallow specification of the language itself and include nothing else. Exceptions aredescribed in 2.1.9.Some offer the generation of an editor and to a less extend a de-bugger. These are important feature for increasing the efficiency of a developer.Therefore the framework described afterwards is able to generate an editor and adebugger of a given metamodel. Often the used models do not provide enough infor-mation for this task, so additional work has to be done be the developer in specifyingneeded in formations.

Language evolution A DSL may evolve over time. If changes were made to the language,rendering artifacts written in older versions incompatible, all artifacts will need to beupdated manually. This is a time consuming and error prone task as non of thecurrent tools support can automate this easily. The presented framework will supportautomatic conversion between language versions if a transformation on the metalevelis defined.

4.2 User rolesSeveral user roles can be distinguished.

• A domain expert who is simply reading the DSL to understand what is expressed.Only a simple editor is needed.

• A domain expert developing in a new DSL. He only needs to know how to use theDSL editor and how to execute or debug the DSL. Often he is a source for languageimprovement proposals.

48

• The DSL developer: He has to understand the basic principles of the proposed frame-work and the target domain to define a new language. This is important because histask is the definition of the syntax and of the semantic of the DSL. Furthermore hehas to test and debug the newly developed language. Finally to accomplish his tasklanguage design and domain modeling expertise is needed.

• The DSL back-end developer: His role is to implement the back-end for the newlanguage. A large number of different possibilities such as an interpreter or vir-tual machine approach exists. A good understanding of the domain and the neededfunctionality is a prerequisite but expertise in language development is not required.Often the role of the DSL and the back-end developer coincide in one person.

• The last role is the framework developer. No explicit domain knowledge is requireexpect for a deep understanding of the framework: How the different parts are relatedand how they work together. He has to extend, maintain and port the framework.

4.3 Framework ArchitectureThe proposed architecture consists of three parts:

• The framework itself, which contains modules for model handling, transformationand exchange and also different parsers/generators,

• Language specification artifacts like grammars or transformations,

• An interchangeable back-end.

In 4.4 a subset of the features of the in the following described architecutre are imple-mented.

49

DSL Artifacts

IDE

Concrete DSL

DSL Framework

Textual representation

Model

DSL Parser /

Generator

Backend

Backend Plattform (Runtime,

Language & Tools)

Backend APIs / Frameworks

Model Transformation

Engine

(Model2Text,Model2Model)

Model Manager

Tool TemplateTool Templates /

Debugging Aspects

Plugin Generator

Debugger

EditorEditor

(Plugin)

Debugger

(Plugin)

Misc Frameworks, APIs, Runtimes

Parser/Generator

Generator

DSL Specification

Metamodel / domain model

Transformations

Model Bus

Framework

Developer

R

Edit, Debug

...

R

R

Model consumable by backend

(source,bytecode,dbg symbols,...)

R

R

Configuration

R

Grammar model

Syntax View

Semantic Mappings

Syntax View

RGet syntax model

R

Metametamodel

Grammar metamodel

Figure 4.1: Proposed architecture for an model-driven DSL framework (FMC)

4.3.1 Components of the frameworkThe framework consists of a number of interacting components.

Metametamodel

Because the framework follows a Model-Driven Engineering approach, one unique metameta-model is defined. Ideally this is one of the widely used metametamodels As already statedsuch a model enables reuse with other tools and frameworks.

Model Manager

The Model Manager (MM) plays a central role inside the framework. It manages the avail-able models and metamodels, allows to create new models conforming to a metamodel,loads and stores models and keeps track of inter-model referencing. The metamodels haveto conform to the unique metametamodel, which serves as the base for the Model Man-ager to understand every other conforming model. The ModelManager offers access to this

50

metametamodel. In most cases the models will be handled in memory by the MM. Throughthe model import and export capabilities other tools and frameworks which understand thesame metametamodel are able to reuse any model created or loaded and modified and thenexported by the MM.

The MM can also be seen as a model repository like the Netbeans Metadata Repository2

or the repository implementation of EMF.

Model Bus

The Model Bus is not part of the framework but is used by the MM. The MM itself onlysupports exporting models which at some point conform to the unique metametamodelin a special persistence format whereas the Model Bus enables a broader reuse. Sometools may not support the MMs export format but are connected to the Model Bus andcan therefore work with the models managed by the MM. Sometimes a transformationinto different metamodels can be automatically handled by the Model Bus by metamodelsimilarity matching. Moreover the Model Bus allows connecting model operations fromdifferent tools. This is an advantage as no single tool offers all operations like edition, stor-age, manipulation, transformation, validation, checking or code generation and a manualconnection needs additional developer efforts.

A concrete Model Bus is implemented by [28], still the framework is completely func-tional without a Model Bus connection.

Model Transformation Engine

To allow complex programmatic model modification a Model Transformation Engine (MTE)is included into the framework. The MTE offers to different high level operations: model-to-model and model-to-text transformations.

Model-to-model transformations are needed at several places. For instance existinggrammar models can be modified, or a concrete DSL model can be transformed into aback-end model.

Model-to-text transformations are used to create textual representations of grammarmodels that could after that be process by the parser generator or the generator generator.Furthermore not all back-ends understand models, so a textual representation which theyare able to understand (like C) can be created from an concrete DSL model.

It is possible to use an external transformation engine, too.

Grammar metamodel, parser- and generator

Not only the domain information should be described by a model but also the grammarof their textual representation; therefore a grammar metamodel is proposed within thisframework. Accompanying a grammar parser and a grammar generator are included in theframework. The parser creates a grammar model conforming to the grammar metamodelfrom a textual grammar and the generator transforms the grammar model into a textualgrammar. The textual grammars are used to generate the DSL parser. Different parser

2http://mdr.netbeans.org/

51

generators can be utilized. For each generator a separate grammar parser and grammargenerator is needed because their textual grammar representation is dissimilar, however thegrammar metamodel is tool independent.

Parser Generator

A textual representation for a domain is of no value if it can not be processed. A parseris needed making the DSL understandable to a machine. This parser is constructed from agrammar by a parser generator. As described in 4.3.1 several parser generators can be used,as long as a grammar parser/generator is available for the format inside the frameworkused by the parser generator. As parser generators differ in the employed paradigm andin power, it is not possible to utilize any generator. The mapping to the generic grammarmetamodel can be difficult up to impossible. Nevertheless creating a parser/generator forparser generators like CoCo/R, JavaCC, ANTLR, Sprint (Parser Framework), or Parsec andcross targeting them through the common metamodel is possible due to their equal LL(k)power.

Notice that one domain can have multiple textual representations and different gram-mars. In the context of this framework these grammars are syntax views of the domain.

The created parser is not only able to recognize a DSL. It creates a model from thetextual representation that conforms to the domain metamodel. This model can then beused for any further operations. To be able to instantiate the right metamodel elements onrecognition of a certain DSL construct, a mapping from the grammar rules to the domainelements has to be done. Two ways are possible: implicit and explicit mapping. If themapping is explicit the developer has to specify the actions instantiating model elementson its own for every grammar rule. An implicit approach is able to create model elementsautomatically by convention. For example grammar rule names are mapped to metamodelelement names.

While explicit mapping offers greater flexibility a larger effort is needed. For this frame-work an implicit approach is favored. This can reduce development work by clever map-ping conventions.

The usable parser generator are restricted by the target programming languages3. Notfor every language exists a metametamodel implementation. This is essential as the parserhas to understand the domain metamodel in order to instantiate a model. One possibilityif that is not the case is to directly write XMI XML. File output is supported by a vastmajority of available languages.

Generator Generator

Sometimes it is of value to have the possibility to generate the textual representation fora domain metamodel instance. A model-to-text transformation engine can create such arepresentation. However a developer has to write the transformation specification manu-ally. The idea of the Generator Generator or more precisely of the generative grammar4

3The parser generator creates code in a specific programming language. The code represents the parser.4Sometimes also called unparser. The first theoretical foundation goes back to Axel Thue in 1914 [184].

Later Chomsky based his work on the by Thue defined Thue system.

52

generator is the creation of a generative grammar from the existing grammar model. Thisis feasible because the grammar model contains the complete syntax representation. Theidea to derive an unparser grammar from a parser grammar is long known [91] and wasrecently demonstrated in the context of model driven DSL development [94]. This reducesthe needed effort a as no model-to-text transformation like a model visiting generator hasto be developed.

Plugin Generator

As previously discussed besides the domain specific language itself the surrounding ecosystem is important. Users of modern GPL environments are accustomed to features assyntax highlighting and code completion. Furthermore a debugger is essential for mostGPLs. To further enhance the advantages of a DSL the framework proposes the generationof the according tools. The goal is not to generate a complete environment, but to extendexisting environments and reuse already built-in functionality. Some IDEs like Eclipse5 orMicrosoft Visual Studio.Net6 offer interfaces that explicitly support the extension of theenvironment with new components.

Two components are proposed an editor plugin and a debugger plugin. Both shouldbe produced by the Plugin Generator module of the framework. For every IDE a set ofparticular templates is needed. In combination with the grammar model it is possible togenerate the components.

The way to derive a standalone editor from a grammar is shown by [88, 169] and thegeneration of an Eclipse editor plugin is explained by [64, 96]. A similar approach is usedby the presented framework. Basically the templates provide a tool specific frame. Theycontain grammar independent code and placeholders for grammar specific parts. The partsare filled with information from the grammar model. The derived editor can also serve as abase for custom modifications.

A debugger plugin which allows DSL debugging requires greater effort. Only a verysmall number of DSLs, independently of the way they are developed come with debuggingtools. While an editor can be generated only from a grammar model this is not the casefor a debugger. For executable DSL the back-end has to support debugging first of all.Secondly the mapping from DSL to back-end has to be traceable. If it is not possible torelate back-end instructions back to the DSL parts they are generated from, debugging isimpossible. Letting the DSL user debug directly inside the back-end is no option becausehe has to understand the back-end technology and therefore often deals with non domainspecific concepts. Finally it is not feasible to implement the debugger manually as this is atime consuming and error prone task and would increase DSL tool development duration.However as discussed in 2.1.9 some frameworks allow the generation of a debugger. Anapproach which concentrates on imperative and declarative DSL debugging serves as guid-ance for idea how a debugger can be generated. Wu et al. [187] propose the weaving ofdebugging control instructions into the grammar. In the context of this DSL framework theweaving of debugging aspects by simple model transformations on the grammar model is

5http://www.eclipse.org6http://msdn2.microsoft.com/en-us/vstudio/default.aspx

53

proposed. The available debugging aspects are back-end dependent and have to exist forevery back-end a debugger should be generated for.

4.3.2 Language specification artifactsSeveral artifacts are needed to define a new DSL. They are described in the now.

Domain Metamodel

The domain metamodel is a central part in the definition of a new DSL. It describes whatkind of elements can exist inside the domain. Every domain metamodel instance7 has toconform to the metamodel, which itself has to conform to the metametamodel on that theframework is built. Designing a new DSL the domain metamodel should be establishedin the first place. In some cases a domain metamodel already exists for instance as a basefor a domain specific modeling language and only needs to be translate into the correctmetametamodel. Without the metamodel a domain model can not be precisely defined.

How the domain metamodel looks alike depends merely on the developer. It can beclose to the textual representation or far away from it, however the former makes andimplicit mapping from the textual representation to a domain model and vice versa difficult.Special caution8 should be taken, because the domain metamodel is an important artifact.A model which does not fit the domain, can increase the needed development effort.

A similar approach is taken by TCS. XText in comparison derives the domain meta-model from a grammar.

Syntax View

A Syntax View describes the textual representation for a domain metamodel and is thegrammar for the domain under consideration. This view can be a grammar model itselfconforming to the grammar metamodel included in the framework or a textual grammarsupported by the framework. A textual grammar can then automatically be converted into amodel. Again using a grammar model makes manipulation through transformation easier,especially global modifications. As transformations are applied manually, they are less er-ror prone than a manually modified textual grammar. Allowing the import of any grammarwritten for the supported parser generators enables the reuse of existing grammars (as forprominent GPLs or previously developed DSLs).

The syntax view consists of a set of parsing rules and additionally of the constructionactions for model elements. As mentioned in 4.3.1 an implicit and an explicit mappingis possible. To facilitate an implicit mapping, different conventions are proposed for in-stance naming production rules equal to model elements. The grammar model can thenautomatically be augmented with matching actions derived from rule naming and type,

7The terms domain metamodel instance and domain model are synonymous in this context. A domainmodels is in this case a terminal model.

8The development of a precise world map, which can be seen as a model took hundreds of years. It wasrefined multiple times. The domain modeler should not be satisfied with his first design but try to refine it.However this should take considerably less time than the development of the world map.

54

cardinality and connection of domain metamodel elements. In some cases more informa-tion is needed, like such as how to map primitive types for example to lexer rules or todefine special symbols like delimiters or operators. So a special grammar DSL which ismodel and convention aware is proposed. Furthermore it contains additional constructs forthe description of special cases and mappings.

Additionally for debugging and error handling purpose the line and column numbersinside the textual representation are stored for every created model entity .

Semantic Mapping

Describing the syntax and its mapping to a model can be done with Syntax Views. Thequestion what a model exactly means and its (operative) semantic is defined by SemanticMappings. They are the connection to the back-end. DSLs which are not executable do notneed this mapping.

The goal is to map the domain model to an representation understandable by the back-end. Different possibilities are available.

• The back-end understands the domain metamodel. It can directly execute any givenmodel by either interpreting it or compiling it to another executable representation.In this case no mapping at all is required.

• The back-end uses a special back-end model. If the back-end’s metamodel uses thesame metametamodel as the framework the semantic mapping is a transformationfrom domain metamodel to back-end metamodel. The meaning of a domain modelelement is then directly related to one or more back-end model elements.

• The back-end is a general purpose language such as Java or Python eventually com-bined with a domain specific library. A number of approaches are possible. A textualrepresentation can be created from the domain model using a model-to-text trans-formation. After that the generated code can be compiled/interpreted. Furthermorethe domain model can be transformed into an abstract syntax representation of theback-end/hosting language. Some platforms allow the direct execution of ASTs. De-pending on the domain it is even imaginable to target lower level abstraction like JavaByte code or MSIL.

• The back-end is unclear. One option is to use an established format for the specifica-tion of semantics such as abstract state machines. Ruscio et al. [151] uses XASM todescribe the semantics of a DSL (see 2.3.1). This could be integrated into the modelflow if the representation supports the MDE approach. The chosen representation canafterwards be transformed into an executable format, an example is Kermeta whichspecifies a new language for semantics deeply integrating semantics into the modelflow.

This is not a complete list of potential semantic mappings, as the mapping strongly dependson the back-end.

55

To allow error propagation from the back-end up to the DSL this mapping is of impor-tance. As a mapping from the domain model to line and column information inside thetextual representation is preserved, a mapping from a model element to back-end permitsto derive a mapping from back-end to textual DSL representation. If an error occurs in theback-end it can be propagated to the related DSL fragment.

Currently no help or instructions for semantic mapping beyond the model managementand transformation tools are proposed.

Transformations

Additional transformations can be included in the description of a DSL. This can be model-to-model or model-to-text transformations. Some example could be the generation of a doc-umentation skeleton for the grammar model in HTML or custom modifications to any of theinvolved models. A use case with more importance is the transformation between differentDSL versions. Ideally it is sufficient to define a transformation between distinct versionsof the domain metamodel. All domain models can then be converted automatically. Thisleads to the importance of keeping the old domain metamodels between different revisions.Admittedly no special arrangements for versions are included in this framework.

Another use case is the transformation of multi variant models into simple models byresolving constraints or replacing generic with concrete elements.

Configuration

The configuration controls the parts of the framework. It can be used to parametrize toolsand to define workflows steering the different components like parser generator or transfor-mation engine. This approach is similar to the oAW workflow engine.

4.3.3 Back-endThe back-end allows the execution of the DSL. As shown in 4.3.2 several back-end typesare imaginable as long as a semantic mapping exists. In general the framework enforces norestrictions on the back-end, but to allow certain functionality the back-end needs to offerseveral interfaces.

Control interface

To integrate the back-end with the rest of the framework and generated editors, the back-end needs to be externally controllable. It should be possible to trigger the execution ofback-end consumable artifacts and to query state information. If an error has happenedinside the back-end it should be possible to get an error trace to allow the mapping back tothe DSL.

Debugging interface

If debugging a DSL should be possible control over the executing back-end is needed.The back-end has to offer interfaces which allow different operations. What operations

56

are required depends on the DSL. For an imperative DSL the back-end should supportbreakpoints, and step by step execution. Furthermore to inspect DSL datatypes the back-end has to offer introspection capabilities. This makes the retrievement of variables/datainformation from the back-end and map them to the DSL possible.

4.4 Implementation“Python code is easy to throw away”9.

Frodo - a Framwork for domain specific languages is an implementation of the in 4.3proposed architecture. It is developed in Python for practical reasons. The use case whichmotivated the development of the framework is a large Python application. However aswill be shown, that does not have an influence on the generality of the framework.

In the next sections the implementation is presented. Frodo implements a large numberof the described components. It will be mentioned if an implemented feature differs fromthe proposal.

4.4.1 OverviewFrodo consists of several components. The core is built around the EMF ECore metameta-model, enabling MDE. The transformation engine is a mixture of ATL and Python codefor model-to-model transformations and a modified ST10 engine for model-to-text. Forparser generation ANTLR is chosen as it comes with Python support. The target of the plu-gin generators is the Eclipse development environment, because of its good extensibilityfeatures.

Most of the framework is implemented directly in Python version 2.4, Python 2.5 whichwas released after the initial development can run Frodo equally well.

9 Tim Peters, long time Python contributor10The orginal name was StringTemplate but ST is a name one its own by now, see table 2.6.

57

DSL Artifacts

Eclipse IDE

Concrete DSL

DSL Framework

Textual representation

Model

DSL Parser /

Generator

Backend

Backend Plattform (Runtime,

Language & Tools)

Backend APIs / Frameworks

ATL

Python

ST

Model Manager

Tool TemplateTool Templates /

Debugging Aspects

Plugin Generator

Debugger

EditorEditor

(Plugin)

Debugger

(Plugin)

Misc Frameworks, APIs, Runtimes

ANTLR Parser

Generator /

ST Generator

DSL Specification

ECore domain model

ATL/Python Transformations

ECore/XMI

Framework

Developer

R

Edit, Debug

...

R

R

Model consumable by backend

(source,bytecode,dbg symbols,...)

R

R

Configuration

R

Grammar model

Syntax View

Semantic Mappings

Syntax View

RGet syntax model

R

ECore

Grammar metamodel

Figure 4.2: Frodo’s architecture (FMC)

4.4.2 ECore - Metametamodel ImplementationThe core of Frodo is the functionality built around the ECore metametamodel. ECore isdescribed in 2.2.4 and is chosen because it has proven its practical usability, as a widerange of tools and libraries is based on or able to work with ECore (Eclipse GEF/GMF,Omondo11, Topcased12, MagicDraw13). Major MDE implementers like GME announced tosupport EMF/ECore[3]. Yet because of its strong connection with the Eclipse/EMF project,only a Java implementation is available. Frodo implements the ECore metametamodel inPython. In comparison with Java a cleaner integration into Python is possible due to itsdynamic nature. The implementation consists of various components.

11http://www.omondo.de/12http://www.topcased.org/13http://www.magicdraw.com/

58

Metametamodel

ECore is implemented as a set of Python classes. In the first version of the frameworka skeleton of these classes was developed manually. In the current version the metameta-model classes are bootstrapped by generating the Python classes from the ECore metameta-model description defined in ECore itself14. As there is no specification for the semantic ofthe operations defined in the metametamodel, the Java implementation is consulted on.

A metamodel which conforms to the ECore metametamodel is expressed as an in-memory-object-tree of Python ECore class instances. Other models use ECore as metameta-model. They can link to it as metamodel and use the defined classes, too.

Model Management

The Model Management keeps track of all in-memory models (models, metamodels andthe ECore metametamodel). It manages the mapping of URIs to metamodel files and allowsto query for a specific metamodel by URI or filename. Moreover different paths are config-ured by the Manager such as the default model storage location. Currently only filesystemlocations are supported. Finally it offers a wrapper-function to allow the loading of ECoremetamodels, creating instances of metametamodel classes. Often these classes containmethods defined in the metamodel but without an implementation. Through mixins theModelManager can automatically inject implementations defined by the by the developer.

XMI Handling

To support the exchange of models Frodo implements the XMI 2.0 standard. This allowsstoring and loading of ECore models in the XMI format, that is also used by EMF. As XMIis a XML format it is implemented inside Frodo on top of the lxml library for Python. Thelibrary implements ElementTree a container for accessing hierarchical data structures likeXML from Python and supports XPath and XML Schema validation.

When a model is loaded the corresponding Python classes are instantiated accordingto their metamodel and they are filled with the stored information. In most cases an XMLelement is mapped to a Python class and its attributes to class attributes. Stored intra-modelreferences are resolved and replaced by real object reference in memory. Frodo supportsboth referencing types used by ECore XMI: by ID and by location references. Furthermorethe framework is able to resolve external references and load models and their metamodelon demand.

Storing an in-memory model as XMI/XML is equally implemented as loading. Insidethe XMI document object references are replaced by positional or ID references. Theresulting object graph is then written to an output stream.

Python integration

Making the use of models as easy as possible, Frodo is well integrated with Python. There-fore model elements are represented by in memory objects. The framework generates ap-

14 org.eclipse.emf.ecore_2.2.0.jar/model/ecore.ecore

59

from e c o r e . modelmanagment . c o r e import ∗2 from e c o r e . s t o r a g e . dumper import dump

4 c o l o r = E A t t r i b u t e ( name=" c o l o r " , e A t t r i b u t e T y p e =" E S t r i n g " )c a r = EClass ( name=" Car " , e S t r u c t u r a l F e a t u r e s =[ c o l o r ] )

6 r r = EClass ( name=" Rol l sRoyce " , eSuperTypes =[ c a r ] )min i = EClass ( name=" Mini " , eSuperTypes =[ c a r ] )

8package = EPackage ( e C l a s s i f i e r s =[ r r , min i ] )

10 dump ( package , " c a r s . e c o r e " )

Listing 4.1: Creating an ECore metamodel for a carpool in Python

1 < e c o r e : E P a c k a g e x m l n s : e c o r e =" h t t p : / /www. e c l i p s e . o rg / emf / 2 0 0 2 / Ecore "x m l n s : x s i =" h t t p : / /www. w3 . org / 2 0 0 1 / XMLSchema−i n s t a n c e "

3 xmlns :xmi =" h t t p : / /www. omg . org /XMI" x m i : v e r s i o n =" 2 . 0 "name=" Cars ">

5 < e C l a s s i f i e r s x s i : t y p e =" e c o r e : E C l a s s " name=" Rol l sRoyce " eSuperTypes =" / / Car " / >< e C l a s s i f i e r s x s i : t y p e =" e c o r e : E C l a s s " name=" Mini " eSuperTypes =" / / Car " / >

7 < e C l a s s i f i e r s x s i : t y p e =" e c o r e : E C l a s s " name=" Car ">< e S t r u c t u r a l F e a t u r e s x s i : t y p e =" e c o r e : E A t t r i b u t e " name=" c o l o r " upperBound=" 1 "

9 eType=" eco r e :EDa ta Type h t t p : / /www. e c l i p s e . o rg / emf / 2 0 0 2 / Ecore # / / E S t r i n g " / >< / e C l a s s i f i e r s >

11 < e C l a s s i f i e r s x s i : t y p e =" e c o r e : E C l a s s " name=" CarPool ">< e S t r u c t u r a l F e a t u r e s x s i : t y p e =" e c o r e : E R e f e r e n c e " name=" c a r s " upperBound="−1" eType=" / / Car " / >

13 < / e C l a s s i f i e r s >< / e c o r e : E P a c k a g e >

Listing 4.2: Carpool metamodel as XMI

propriated Python classes for each metamodel. These classes can then be instantiated tocreate a model, can be loaded from an ECore XMI file or saved to it. A modified STtemplate engine is used for generation of the Python classes.

To ameliorate the integration, Frodo hooks on the standard Python module import fa-cilities and allows the direct import of ECore metamodels. During the process of importingthe corresponding classes are generated and loaded. Its use is optional.

Example

The following paragraph illustrates the Frodo ECore components using a simple example.At first an ECore metamodel for a car pool that can contain cars and some car types iscreated (listing 4.1). This is done in Python but can be produced with any other toolssupporting ECore, too. The metamodel is serialized into XMI shown in listing 4.2. Theway the autoimport works and creates a model conforming the metamodel is demonstratedin listing 4.3.

In this oversimplified example only a subset of the features is shown. For exampleloading or inter-metamodel referencing are possible, but not demonstrated. Finally listing4.4 show the XMI representation of the model created before.

import e c o r e . a u t o i m p o r t2 from c a r s import ∗

4 myCarPool = CarPool ( name=" M a r t i n s Cars ! " )myCarPool . c a r s = [ Ro l l sRoyce ( c o l o r =" b l a c k " ) , Mini ( c o l o r =" g r e e n " ) ]

6from e c o r e . s t o r a g e . dumper import dump

8 dump ( " myCars . c a r p o o l " , myCarPool )

Listing 4.3: Auto importing the carpool metamodel and creating a model

60

1 <? xml v e r s i o n =" 1 . 0 " e n c o d i n g ="UTF−8" ?>< c a r p o o l : C a r P o o l x m l n s : c a r p o o l =" h t t p : / / k a r l s c h . com / CarPool "

3 xmlns :xmi =" h t t p : / /www. omg . org /XMI"x m l n s : x s i =" h t t p : / /www. w3 . org / 2 0 0 1 / XMLSchema−i n s t a n c e "

5 x m i : v e r s i o n =" 2 . 0 "name=" M a r t i n s Cars ! ">

7 < c a r s x s i : t y p e =" C a r s : R o l l s R o y c e " c o l o r =" b l a c k " / >< c a r s x s i : t y p e =" C a r s : M i n i " c o l o r =" g r e e n " / >

9 < / c a r p o o l : C a r P o o l >

Listing 4.4: XMI representation of a carpool model

4.4.3 Grammar / Syntax View HandlingFrodo is employs the ANTLR v2 parser generator (LL(k)) which is able to generate parsersin Python. The grammars used by the generator can be transformed into a grammar modeland a grammar model into an ANTLR grammar.

Grammar Metamodel

The grammar metamodel can be used to describe grammars. It has been developed man-ually in an ECore aware modeling tool. Contrary to the proposed one the grammar meta-model is not completely tool independent but contains some ANTLR specific elements atthe moment. The reason is the incremental development of the framework.. Neverthelesssome model refactoring can improved that.

Figure 4.3 shows an excerpt of the metamodel. Important is the definition of rules andof what elements a rule can consist of. The picture does not contain the set of operationseach element owns because they are currently mixed in at runtime . A number of methodsfor manipulating a grammar are available: finding and modifying rules, annotating ruleelements with actions or labels and replacing/deleting elements.

Grammar Parser

Creating a model from an existing parser grammar enables reuse. So Frodo contains aparser built with ANTLR which can convert an ANTLR grammar into a grammar model.The attributed parser grammar contains actions to instantiate elements from the grammarmetamodel. These actions are written in Python and use the Frodo ECore implementation.After reading the grammar ANTLR generates a parser in Python. This parser is used forevery ANTLR compatible grammar.

Currently a various grammars are available for reuse, ranging from C, Java, C# overSDL, SQL and Eiffel up to Verilog and HTML [1]. The mentioned grammars have beentested with Frodo and all of them can be successfully transferred into a grammar model.

Grammar Generator

To create an ANTLR grammar from a grammar model, a modified ST engine is used.Currently the generative template is written manually and consists of a set of rules. Eachrule is a production for a certain model element. The rules are invoked top-down and the

61

Figu

re4.

3:E

xcer

ptfr

omFr

odo

gram

mar

met

amod

el

62

top rule is parametrized by the top-level grammar model element and generates a completegrammar. Listing 4.5 gives an example of the grammar generation template used .

A generative rule has a name and one or multiple parameters. The template associatedwith the rule is delimited by double angle brackets. In this case, the rule parameter corre-sponds directly to a model element. Inside the template the placeholders inside single anglebrackets are replaced by the values they refer to for simple placeholders, or by the resultsof the calculation for complex placeholders such as conditionals or subrule calls. Subrulecalls can take parameters or can be appended to a collection and are then called for everyelement in the collection (this happens in block.alternatives handling).1 Block ( b l o c k ) : : = <<

< b l o c k . a l t e r n a t i v e s : A l t e r n a t i v ( ) ; s e p a r a t o r =" | ">3 >>

5Rule ( r u l e ) : : = <<

7 < r u l e . a c c e s s >< r u l e . i d > < i f ( r u l e . r e t u r n A c t i o n ) > r e t u r n s [ < r u l e . r e t u r n A c t i o n > ] < e n d i f >

9 < i f ( r u l e . o p t i o n s ) >< O p t i o n s ( r u l e ) >< e n d i f >< i f ( r u l e . i n i t A c t i o n ) >{< r u l e . i n i t A c t i o n >}< e n d i f >

11 :<Block ( r u l e . b l o c k ) >

13 ;>>

Listing 4.5: Excerpt from the generative grammar for ANTLR grammars

Parser and Generator generation

A DSL parser is generated with ANTLR from an ANTLR grammar file. The grammarfile is produced with the grammar generator for a grammar model. Currently ANTLR isthe only supported parser generator. After the generation process the parser can be usedimmediately to recognize the DSL. A grammar model without actions does not constructthe model elements described in the domain metamodel.

Two possibilities described earlier in this thesis solve this problem. The current versionof Frodo supports the explicit definition of creational actions inside the grammar meta-model. Similar to the grammar parser these actions are by default written in Python, as thegenerated Parser is Python, leveraging the ECore implementation. It is possible to retargetANTLR to generate a Java, C++ or C# parser. Afterwards the actions have to be defined inthe matching target language. The only precondition is the ability to import ECore models.This explicit approach allows a very flexible mapping of the language elements to modelelements, but comes along with some drawbacks. Firstly, if the parser is retargetted, theactions have to be converted manually to the new target language. Secondly, an additionaldevelopment effort and a good understanding of the grammar model is need. Moreoverthe grammar model is not target independent anymore. Finally, the goal described in 4.3.2of generating a textual syntax generator or a fitting generative grammar is impossible, asFrodo would have to analyze the custom action and interpret their meaning.

To solve this problem, the implicit approach is needed. Frodo has only experimentalsupport for an implicit mapping by conventions and some additional information have tobe defined manually. The actions to create model elements and populate them are thengenerated automatically. At the moment only automatic generation of Python actions issupported. A description of the conventions can be found inside the framework documen-tation.

63

Automatic generation of the textual representation from a domain metamodel instanceis currently not implemented. As already mentioned it is impossible for grammar modelswith explicit actions. Nevertheless a generative grammar can be defined in ST. To enablethe automatic generative grammar generation for implicit grammar models a preliminarymetamodel to describe ST generative grammars was developed accompanied by a trans-formation for the grammar metamodel to the ST metamodel. This step corresponds to theproposed inversion of a grammar.

To simplify the whole process a separate DSL which is able to serve as a foundation forthe generation of a parser and a generative grammar was suggested in 4.3.1. Initial workwas done, but deferred for later research due to reasons of complexity.

4.4.4 Transformation EngineATL is elected as transformation engine because transformation is an important function-ality in Frodo. With ATL it gets possible to perform model-to-model transformation ofECore models. ATL is similar to the QVT proposal, is opensource and compared to othertransformation tools superior in functionality. It is written in Java, so a JVM is needed toexecute the ATL transformations included in Frodo.

Additionally it is possible to transform models with Python by directly manipulatingobjects in memory. At the moment no special API is included in Frodo for this task.Practical experience showed, that it is sometimes easier to modify models in Python thanwith ATL. Nevertheless for complex transformations from one metamodel to another, ATLis recommended.

An example how transformations can look alike is found in 5.1.2 and 5.2.3. A largenumber of reusable transformations is available for the Atlantic transformation zoo [5] .

4.4.5 Plugin GenerationThe plugin generator creates an editor and a debugging plugin for the Eclipse platformbased on a ST template that is filled with information from the grammar metamodel. Whilethe editor is usable, the debugger is unfinished.

The editor derives from the AbstractUI class provided by Eclipse and implements asimple keyword highlighting. Therefore a listener listens to changes made inside the docu-ment and reparses it on every change in a separate thread. After parsing the resulting tokensare colored according to the grammar model and additional color information specified inanother template.

The debugger takes ideas from the Eclipse DDF but also from general available Eclipsedocumentation and is suited for imperative languages. A plugin is generated which com-municates with the debug target via TCP. Out of this reason the back-end has to implementa debug server understanding at least the following commands: set and clear breakpoints,start, stop, resume and step. On the side of the plugin several Eclipse Debugging Platforminterfaces are implemented: ILauch, IDebugTarget, IProcess, IDebugElement, IVariable,IValue, IBreakpoint and several others. The IDebugTarget implementation is the central

64

place where communication with the back-end takes place. Currently only breakpoints byline can be set. The work on the debugger generation was not finished.

4.4.6 Implementation problems and issuesModelBus

A ModelBus connection is not implemented, and all exchange with external tools is donevia XMI. This is due to the fact that no matured bus implementation is available by now.The Model Bus Integrated Environment for Eclipse [28] is only available as a prototype.The same is true for ModelCVS [112] which applies similarity matching to automaticallyderive transformation between metamodels.

ECore

The current ECore implementation inside Frodo suffers shows some problems. Some aredirectly related to the implementation, others to the ECore XMI format.

• When loading a model from an ECore XMI file, the top-level model element has tobe defined manually. This is only a minor issue and can be resolved by implementinga function which checks the root XMI element, loads the metamodel automaticallyand instantiates the top level model element.

• Not all ECore operations are implemented. Particularly methods allowing to queryinformation redundantly stored in queryable attributes are missing, for example thegetFeatureCount method of EClass that returns the number of features. Another wayfor retrieving this information is getting the number of items inside the collectioneAllStructuralFeatures, an attribute of EClass.

• The ECore XMI file does not conform to the XMI standard. That requires the usageof xmi:type for type definition. Instead xsi:type is utilized. This can be followed backto the usage of XML Schema inside ECore XMI serialized files. Frodo solves thisproblem by using xsi:type.

• Inter-model referencing of elements inside ECore XMI uses a proprietary format.The Python reimplementation was done by studying the Java source code. Somesources suggest [7] that part of the link is valid XPath, however this is wrong and caneasily be seen examining some links carefully. This was stated by Ed Merk15. If theEMF implementation changes, Frodo has to aligned with it.

15Ed Merk is one of the EMF ECore API maintainers and states that these links are not XPath, and thatECore will not support XPath in the near future.

“XPath is no doubt far more complex than ECore itself, so it seems likekind of a big boat anchor for our little speedboat.” - It will not be used.(http://dev.eclipse.org/newslists/news.eclipse.tools.emf/msg10055.html)

65

• Using the EMF ECore classes and tools sometime an invalid ECore metametamodelis referenced (../../org.eclipse.emf.ecore/model/Ecore.ecore). Usually the model isidentified by http://www.eclipse.org/emf/2002/Ecore. This problem ia solved by al-lowing to map arbitrary URI to the correct model inside the ModelManager.

ANTLR

ANTLR proved to by very stable during the development of Frodo, nevertheless some flawslike possible deadlocks were discovered in the ANTLR Python runtime, which is used bygenerated Python parsers. In consequence Frodo includes a fixed ANTLR runtime.

ATL

It is of great impact that model transformations are done correctly. Some problems wereencountered while using ATL . The latest available binary release targets Eclipse 3.1. Thisallows the correct execution of transformations used inside Frodo. Using this version of theATL plugin with Eclipse 3.2 (current stable version) leads to wrong transformation resultsdue to changes in EMF used by ATL. As ATL can currently not be used without Eclipsethe usage of Eclipse 3.2 is not advised in combination with the official ATL release. Asolution for this problem is the utilization of ATL 2006, to day only available from theEclipse GMT CVS16 source repository. It has to be compiled and installed manually, butexecutes all transformations correctly.

16http://dev.eclipse.org/viewcvs/index.cgi/org.eclipse.gmt/ATL/?root=Technology_Project

66

Chapter 5

Examples

“Example is not the main thing in influencing others. It is the only thing.”1

To illustrate the practical usage of Frodo two examples are given. A sim-ple state machine language and a complex test automation language based onprevious work inside the automotive industry.

To give a guideline how Frodo can be used some examples are helpful. From a merelytheoretical viewpoint, it may not be possible to derive the steps needed to create work-ing solutions with the framework. One simple example demonstrates the basic usages andimplements a state machine language with two back-ends. To show that more sophisti-cated solutions are realizable with Frodo, a test automation language based on Python isdeveloped in multiple steps.

5.1 A simple state machine languageThe design and implementation of a new DSL using Frodo, should be done in several steps. At first the domain metamodel should be defined, followed by one or more syntax views.Finally the back-end can be plugged in. A minimal finite state machine (FSM) DSL willbe developed in the next paragraphs.

5.1.1 DesignAt first it is important to define a suitable domain model. It consists of states and transitionsbetween these states. Each state has a name and a number of possible transitions. Atransition can fire if a certain input value is given. If it fires, an output associated with thetransition is displayed. As the state machine should be finite, it needs a start and a stopstate. Finally the machine itself is named. Figure 5.1 shows one possible domain model forthese requirements, modeled in ECore.

1Albert Schweizer

67

Figure 5.1: Finite state machine domain model

After the domain model is finished, a adequate syntax is developed. The languageshould work with blocks, known from C or Java. Each state is represented by an ownblock, delimited by curly brackets. The state block contains the transitions associated witha target state, an input condition and some output. Furthermore the start and the stop stateshould be marked. Listing 5.1 shows an example of a possible language, defining threestate including transitions. This example represents the state machine depicted in figure5.2.

s t a t e m a c h i n e Demo {2 s t a r t s t a t e A {

go to B on " b " p r i n t " u " ;4 go to C on " c " p r i n t " v " ;

}6 s t a t e B {

go to C on " c " p r i n t " x " ;8 go to A on " a " p r i n t " y " ;

}10 s t o p s t a t e C {

}12 }

Listing 5.1: Example of FSM DSL (demo.fsm).

A B C

c / xb / u

c / v

a / y

Figure 5.2: Example of a finite state machine

68

From this listing and the previous considerations a grammar can be derived as proposedin listing 5.2.

To complete the design it is decided to target two back-ends: first an interpreter for themodel developed in Python and second a C code generator. The C should be compilableafterwards.

Now after these steps realizing the implementation with the help of Frodo is presented.It should be mentioned that a FSM can be more effectively represented visually but thisexample serves merely for the demonstration of Frodo.

S t a t e M a c h i n e : = ’ s t a t e m a c h i n e ’ I d e n t i f i e r ’ { ’ S t a t e∗ ’ } ’ ;2 S t a t e : = ( ’ s t a r t ’ | ’ s t o p ’ ) ? ’ s t a t e ’ I d e n t i f i e r ’ { ’ T r a n s i t i o n∗ ’ } ’ ;

T r a n s i t i o n : = ’ go to ’ I d e n t i f i e r ’ on ’ S t r i n g ’ p r i n t ’ S t r i n g ’ ; ’ ;4 I d e n t i f i e r : = ( ’ a ’ . . ’ z ’ | ’A’ . . ’Z ’ | ’ _ ’ | ’ 0 ’ . . ’ 9 ’ )∗

S t r i n g : = ’ " ’ ( ~ ( ’ " ’ | ’ \ r ’ | ’ \ n ’ ) )∗ ’ " ’ ;

Listing 5.2: Grammar of the FSM DSL as EBNF

5.1.2 ImplementationFor the implementation of the proposed DSL different steps are necessary. The first is al-ready done, as the FSM metamodel has already been created in the design phase. Also apossible grammar for the DSL has been proposed and serves as a base for the followingFrodo syntax view specification. As Frodo derives a parser from a grammar model, cur-rently two ways to create the FSM parser are feasible. At first the grammar model can becreated directly in any modeling tool supporting ECore. The second approach is definingan ANTLR grammar which is in turn converted to a grammar model. In listing 5.3 theresult of using the second possibility is shown. For the resulting grammar model, the map-ping to the FSM domain model is done implicitly. It is sufficient to specify the domainmodel, a starting rule inside the grammar and attribute mapping hints.

1 s t a t e M a c h i n e : " s t a t e m a c h i n e " name:IDENTIFIER LCURLY s t a t e s RCURLY ;s t a t e s : ( s t a t e )∗ ;

3 s t a t e : ( s t a r t S t a t e : " s t a r t " | s t o p S t a t e : " s t o p " ) ? " s t a t e " name:IDENTIFIER LCURLY t r a n s i t i o n s RCURLY;t r a n s i t i o n s : ( t r a n s i t i o n )∗ ;

5 t r a n s i t i o n : " go to " to:IDENTIFIER " on " input:STRING " p r i n t " output:STRING COLON;

Listing 5.3: The FSM parser grammar

The tokens IDENTIFIER, STRING, LCURLY, RCURLY and COLON are provided bya standard lexer grammar model. Though the lexer can easily be exchanged or definedwithin the FSM grammar model. Additional rules for skipping whitespaces and commentsare found there. For the FSM DSL the lexer rules are slightly modified as shown in listing5.4.

The mapping rules are always looked up inside the context of the current rule and modelelement. For example the model element StateMachine owns an attribute name and nameis looked up in the stateMachine rule. If no mapping could be found this way (for exampleas with startState and stopState of the StateMachine) the rule associated with the modelelement type under consideration is examined (in this case the state rule).

To allow referencing of other model elements (such as the to property of Transition)from within the grammar model an additional hint, currently in the form of a model anno-tation, is given. For the FSM example the name of a State owns an annotation declaring

69

the name as unique to identify a certain State. In figure 5.1 the collapsed Frodo annotationcontains this hint (TCSSL solves this by extra seek rules inside the grammar).

The implicit mapping happens after the grammar (in listing 5.3) is transformed into agrammar model. A transformation that has knowledge about the domain model and thegrammar model creates the actions inside the grammar model needed to create the correctdomain model elements. From this final grammar model the parser and a simple editor aregenerated (figure 5.3). Invoking the parser returns a FSM model for further use.

As required in the design a Python interpreter should be able to interpret the givenmodel. Listing 5.5 shows a very rudimentary interpreter (error handling is left out forsimplicity). The C back-end is more complicated because in C no facilities for runtimeECore model access are available. The machine should be directly compiled. A generativegrammar is therefore defined (listing 5.7), creating a C language compatible representationof the model.

Beyond the developed back-ends the model created from a DSL code fragment canbe used in any other tools supporting XMI (listing 5.6 shows the XMI representation ofdemo.fsm).

It should be mentioned that in a real life DSL more aspects have to be considered.Model checking is unavoidable. In this example it is possible to create a FSM without astart state or generate C code containing deadlocks. However this is beyond the scope ofthis example. Also no debugging support is generated using a simple generative grammar.The back-end needs to explicitly offer a debugging interface.

1 LCURLY : ’ { ’ ;RCURLY : ’ } ’ ;

3 COLON : " ; " ;# $ s k i p p r e v e n t s t h e l e x e r from g e n e r a t i n g a token , $ n e w l i n e i n c r e a s e s t h e l i n e number

5 COMMENT : ’ # ’ (~ ’ \ n ’ )∗ {$ s k i p } ;WHITESPACE : ( ( ’ \ 003 ’ . . ’ \ 010 ’ | ’ \ t ’ | ’ \ 013 ’ | ’ \ f ’ | ’ \ 016 ’ . . ’ \ 037 ’ | ’ \ 177 ’ . . ’ \ 377 ’ | ’ ’ )

7 | " \ r \ n " {$ n e w l i n e }| ( ’ \ n ’ | ’ \ r ’ ) {$ n e w l i n e }

9 ) {$ s k i p } ;# t h e e x c l a m a t i o n mark p r e v e n t s t h e i n c l u s i o n of a c h a r a c t e r i n t o t h e t o k e n t e x t

11 STRING : ’ " ’ ! ( ~ ( ’ " ’ | ’ \ r ’ | ’ \ n ’ ) )∗ ’ " ’ ! ;IDENTIFIER : ( ’ a ’ . . ’ z ’ | ’A’ . . ’Z ’ | ’ _ ’ | ’ 0 ’ . . ’ 9 ’ )∗ ;

Listing 5.4: The FSM lexer grammar

70

i m p o r t fsm . grammar . p a r s e r # i m p o r t t h e g e n e r a t e d p a r s e r2 from u t i l i m p o r t f i n d

4 d e f run ( s t a t e m a c h i n e ) :p r i n t " Running s t a t e m a c h i n e : " , s t a t e m a c h i n e . name

6 c u r r e n t S t a t e = s t a t e m a c h i n e . s t a r t S t a t ep r i n t s t a t e m a c h i n e . s t o p S t a t e

8 w h i l e n o t c u r r e n t S t a t e == s t a t e m a c h i n e . s t o p S t a t e :p r i n t " In s t a t e " , c u r r e n t S t a t e . name

10 i n p u t = r a w _ i n p u t ( ) . s t r i p ( ) # r e a d i n p u t and c l e a n i tt r a n s i t i o n = f i n d ( lambda t : t . i n p u t == i n p u t , c u r r e n t S t a t e . t r a n s i t i o n s )

12 i f t r a n s i t i o n :# found a t r a n s i t i o n

14 p r i n t t r a n s i t i o n . o u t p u tc u r r e n t S t a t e = t r a n s i t i o n . t o

16 e l s e : :p r i n t " I n p u t was i n v a l i d . "

18run ( fsm . p a r s e r . p a r s e ( " demo . fsm " ) )

Listing 5.5: A simple FSM interpreter in Python, interpreting demo.fsm

1 <? xml v e r s i o n =" 1 . 0 " e n c o d i n g ="UTF−8" ?>< f s m : S t a t e M a c h i n e x m l n s : x s i =" h t t p : / /www. w3 . org / 2 0 0 1 / XMLSchema−i n s t a n c e "

3 xmlns : f sm =" h t t p : / / k a r l s c h . com / fsm " xmlns :xmi =" h t t p : / /www. omg . org /XMI"x m i : v e r s i o n =" 2 . 0 "

5 name="Demo"s t a r t S t a t e =" / / @ s t a t e s . 0 "

7 s t o p S t a t e =" / / @ s t a t e s . 2 ">< s t a t e s name="A">

9 < t r a n s i t i o n s i n p u t =" b " o u t p u t =" u " t o =" / / @ s t a t e s . 1 " / >< t r a n s i t i o n s i n p u t =" c " o u t p u t =" v " t o =" / / @ s t a t e s . 2 " / >

11 < / s t a t e s >< s t a t e s name="B">

13 < t r a n s i t i o n s i n p u t =" c " o u t p u t =" x " t o =" / / @ s t a t e s . 2 " / >< t r a n s i t i o n s i n p u t =" a " o u t p u t =" y " t o =" / / @ s t a t e s . 0 " / >

15 < / s t a t e s >< s t a t e s name="C" / >

17 < / f s m : S t a t e M a c h i n e >

Listing 5.6: The XMI representation of demo.fsm

Figure 5.3: Screenshot of the FSM editor

71

1 group fsm ;

3 T r a n s i t i o n ( t r a n s i t i o n ) : : = <<i f ( ! s t r c mp ( i n p u t , "< t r a n s i t i o n . i n p u t >" ) )

5 {p r i n t f ( " Going t o s t a t e < t r a n s i t i o n . t o . name > , o u t p u t : < t r a n s i t i o n . o u t p u t > \ \ n " ) ;

7 r e t u r n &S t a t e _ < t r a n s i t i o n . t o . name> ;}

9 >>S t a t e ( s t a t e ) : : = <<

11 p S t a t e S t a t e _ < s t a t e . name> ( ) {vo id∗ s e l f = &S t a t e _ < s t a t e . name> ;

13 p r i n t f ( " In s t a t e < s t a t e . name > \ \ n I n p u t : " ) ;s c a n f ( "%20s " , i n p u t , 2 1 ) ;

15 < s t a t e . t r a n s i t i o n s : T r a n s i t i o n ( ) ; s e p a r a t o r =" \ n ">p r i n t f ( " I n v a l i d i n p u t ! \ \ n " ) ;

17 r e t u r n &S t a t e _ < s t a t e . name> ;}

19 >>S t a t e F o r w a r d ( s t a t e ) : : = <<

21 p S t a t e S t a t e _ < s t a t e . name> ( ) ;>>

23Main ( s t a t e m a c h i n e ) : : = <<

25 # i n c l u d e \ < s t d i o . h \ >

27 t y p e d e f vo id∗ (∗ p S t a t e ) ( ) ;c h a r i n p u t [ 2 1 ] ;

29< s t a t e m a c h i n e . s t a t e s : S t a t e F o r w a r d ( ) ; s e p a r a t o r =" \ n ">

31< s t a t e m a c h i n e . s t a t e s : S t a t e ( ) ; s e p a r a t o r =" \ n ">

33vo id main ( ) {

35 p S t a t e n e x t S t a t e = &S t a t e _ < s t a t e m a c h i n e . s t a r t S t a t e . name> ;p S t a t e s t o p S t a t e = &S t a t e _ < s t a t e m a c h i n e . s t o p S t a t e . name> ;

37 p r i n t f ( " Running S t a t e m a c h i n e Demo \ \ n " ) ;w h i l e ( 1 ) {

39 i f ( n e x t S t a t e && ( n e x t S t a t e != s t o p S t a t e ) )n e x t S t a t e = ( p S t a t e ) n e x t S t a t e ( ) ;

41 e l s eb r e a k ;

43 }}

Listing 5.7: A generative grammar, producing a C back-end.

5.2 Test automation language“Testing can only reveal the presence of errors, never their absence.”2

This section starts with presenting the existing test automation frameworkand its Microsoft Excel language. Then the problems caused by the currentapproach are highlighted. After that an improved design based on languageembedding and extension is depicted. This design is afterwards implementedwith the help of Frodo.

5.2.1 IntroductionWith growing complexity, the testing needed is going to increase exponentially. Differentsystem parts have to be tested on their own but also while integrated into one complete

2E.W. Dijkstra [61]

72

system. In reality this is complicated. Product lines often share a large number of com-mon parts but differ subtly. Furthermore the soft and the hardware version of componentschanges steadily, sometimes causing new incompatibilities. All these components have tobe tested to ensure their quality. For example infotainment and telematic systems inside amodern car require the cooperation and interchange among systems like CD charger, mo-bile phone, navigation system, video assistants, speech recognition and combi-instruments3

by different buses.The manual testing of such systems is not feasible anymore. Single component4 tests

and even integration tests have to be automated. The automotive industry does not fulfillthis requirement in all of the cases [36]. Still, a large number of automation solutions existstoday (like AutomationDesk5 or ECU-Test6), even at the BMW Group multiple solutionsare in use depending on the concrete domain. To unify some of them, at least inside theBMW Group Hardware/Software Platforms, Methods and Tools division, the Python TestAutomation Framework (PyTAF) was developed. It contains a DSL reimplemented withthe help of Frodo.

5.2.2 The current systemA test automation framework

For PyTAF an extensive domain analysis was performed and all test automation require-ments for automotive infotainment and telematic related systems were gathered. This anal-ysis led to a domain model serving as foundation for the framework.

The framework itself was developed in Python. This had multiple reasons. First, thelanguage is easy to learn and to read compared to C for example. That eases maintenance.In addition the effort needed to change parts of a system is lower than for an equal sys-tem developed in C. Second, Python offers are large and stable standard library and canaccess existing C libraries with minimal effort. This is important because a large num-ber of used libraries for accessing hardware components are written in C. Finally severalother approaches [80, 122, 157] have shown that Python is suited to develop automationsolutions.

The framework allows the execution of a test sequence, which is specified in a TestDSL.At first the TestDSL is translated into a Python program that uses PyTAF. The resultingsequence is run on a test host (a Python interpreter on a computer with a Windows operatingsystem). In most cases special hardware is attached to the computer. This is the target ofthe test7 or contains functionality needed by the test.

PyTAF is built upon three parts: the Central Controlling Unit (CCU), Services andTestDSL infrastructure.

3Displays speed, gear, revolution ...4In the automotive domain often the term ECU (embedded control unit) is used for such hardware com-

ponents.5http://www.dspace.de/ww/de/gmb/home/products/sw/expsoft/automdesk.cfm6http://www.tracetronic.de/produkte/ecutest.html7Sometimes called SUT, System-Under-Test

73

Central Controlling Unit The CCU is the core of the framework. It contains the runtimefacilities to execute a test sequence. This includes logging and reporting, an errormanager and a service manager which manages the orchestration of the availableservices. The service manager starts each service in a separate thread and providesa proxy to all the service users (the test sequence or another service). This proxyasychronizes every service call. Decoupling the service execution from the sequenceand other services allows a robust event processing and solves the problem of longrunning service tasks stalling the complete system. Synchronization is done by syn-chronized queues used for communication in general and event notification. Thisapproach follows roughly the active object pattern[153].

Services A service offers functionality to a test sequence. This functionality could below level library calls for controlling an attached device. An example is sendinga message over the CAN bus, being attached to the host executing the sequence.The second option is a software-only service, for example an OCR module. Finallya meta service implementing functionality on top of one or more other services isimaginable, like the MMI8 service leveraging the ZBE9 that uses the CAN servicefor communication10. At the moment a growing number of services are available(approximately 50) from CAN or MOST bus control up to image and text recogni-tion. The service can consist of a driver wrapping low level functionality (for exam-ple C libraries), basic functions, main service functions and exposed events. Basicfunctions and service functions differ in, that basic functions are always executedsynchronously.

DSL infrastructure The DSL infrastructure consists of three parts. A domain model11,a front- and a back-end. The domain model serves as an input language agnosticrepresentation of a test sequence. The front-end is used to create a model instancefrom an input language. Finally the back-end generates a test sequence (Pythoncode) orchestrating the framework and its services. Only one front-end is currentlyavailable. It parses a test specification done in Microsoft Excel and creates a domainmodel instance.

Excel test automation language

The Excel language offers different language constructs and options. It is possible to startthe test out of Excel via a custom macro that invokes Python/PyTAF. Furthermore a test

8Multi Media Interface9“Zentrale Bedien-Einheit” - central control unit,

10The MMI service for example offers a function for detecting weather the MMI is currently inside thenavigation menu. This is not done by relying on a MMI internal data structure but by capturing an imageof the screen. This image is analyzed, with the help of the OCR service. If the current screen is not thenavigation menu, the MMI service can navigate to it automatically by instructing the ZBE service with anavigation sequence. The ZBE then uses the CAN service to turn this sequence into actual messages sendover the bus.

11sometimes also information or data model.

74

PyTAF

Testsequence in Excel SheetExcel

Data

model

Generated Python

Frontend

Central Control Unit Excel Parser

Services

Libraries

R

Backend

Datamodel to

Python Transformer

Testcase(generated Python)

Rexecute test

R

R

Figure 5.4: Current PyTAF architecture (FMC)

can span multiple sheets and workbooks and can be parametrized by internal or externalparameters (an INI or YAML file). The most important constructs are:

• a comment cell row, B12

• a comments command, commenting out an entire row if set inside the cell row, A

• an Errorhandler inside cell row, S which is executed if a command like ASSERT-TRUE fails. The type is given in row, S. A subsequence can be called by specifyingits type inside row, U (SHEET, FILE, FILESHEET) and parametrized by row, V .Also the number of repetition for the handler can be set in row, T . Different Er-rorhandlers are available:

◦ CONTINUE - continues execution of the test

◦ LOG_AND_IGNORE - logs the error but continues the execution

◦ HALT_AND_WAIT - stops the execution and put all services on hold

◦ SHUTDOWN_AND_RESTART - restarts the test

◦ SHUTDOWN - terminates the test12row is the current row inside Excel, A − Z stands for the column and value(row, column) the value

inside the cell at row and column

75

• An explicit log entry specified in row, Y if the row is executed Commands inside thecolumn C

◦ SETCONFIG - sets global configuration variables to certain values. The nam-ing follows a hierarchical schema like toplevel.sublevel.variable : value wherethe separating dot stands for the next column starting from column G and theactual variable and its value are represented in the last column, separated by acolon.

◦ FILE - includes another workbook at the current row

◦ SHEET - calls another sheet, the call can be parametrized (like a method call)

◦ FILESHEET - calls another sheet of another workbook

◦ SET - setting a variable with its name inside cell row, G to a value inside cellrow, H

◦ QUEUEVARIABLE creates a new queue with the name taken from cell row, G

◦ FOR - a loop from i to j using a step size of s with a loop variable name ofn where n = value(row, G), i = value(row, H), j = value(row, I), s =value(row, J) and executing the loop body. The loop body starts in the rowfollowing the FOR command beginning with a open bracket and is terminatedby the next matching closing bracket at the same bracket depth.

◦ WHILE - similar to FOR, but executes its body until a condition inside cellrow, G is false

◦ BREAK - terminates a loop

◦ CONTINUE - continues a loop from the start, not executing anything after thatstatement

◦ WAIT - waits until a event has happened inside the “wait-body”. This can be atimeout event created with the TIMEOUT keyword which cancels the wait oran event from a service enqueued in a queue variable13. In the later case thewait is canceled by an IF statement whose condition evaluates to true. A waitcan not be nested.

◦ TIMEOUT - creates a timeout event which is raised after row, G seconds, onlyvalid inside a WAIT block.

◦ IF/ELSE - creates a conditional block, whose execution depends on the evalua-tion of the cell row, G

◦ ASSERTTRUE - tests the condition in cell row, G and asserts if the conditionis violated. Control is passed to a Errorhandler if defined.

◦ LOGGER - makes a log entry, type is given inside row, G and the content insiderow, H . The type can be either info, debug, error, warning or critical.

◦ END - the test case has to end with this command13Also called a trigger.

76

◦ ServiceName.ServiceFunction - calling a function from a service, where Servi-ceName is the name of the service and ServiceFunction the name of the func-tion. The parameters are read from cell row, G to cell row, R. This can also bethe enabling or disabling of a trigger/event.

An important fact about the DSL beyond the discussed commands is, that there is no formaldefinition how a condition for an IF or ASSERTTRUE command has to look alike. Thesame is true for the name/value for SET and in other places. These parts taken as uninter-preted strings from Excel are stored inside the data model uninterpreted, too. The currentimplementation simply puts these strings inside the generated Python code.

Figure 5.5: Excel TestDSL example

5.2.3 A better test automation languageIn this section a new test automation language will be presented. At first problems ofthe earlier described language are identified. Afterwards a solution is discussed. A newdomain specific language will be designed and implemented with the help of Frodo. Thisis described in the remaining section.

Problems of the Excel language

The current implementation of the test automation language and its framework suffers fromsome drawbacks:

Test representation Excel is not ideally suited for the formulation of a structured testcase as it forces the spreading of semantically coherent information across multiple

77

cells. (For example the definition of FOR, WHILE, and WAIT blocks, or methodparameters). It is easy to introduce misunderstandings or, even worse, bugs due toformatting or layout changing.

Test specification format Test cases are currently developed within Microsoft Excel. Ex-cel was primarily developed as a spreadsheet application but is used in many otherdifferent domains. However Excel and its storage format are proprietary, therefore tobe able to modify a test case Excel is needed. Format and application are a subjectsof change. Moreover the format is binary which makes versioning and comparisoncomplicated.

Data model The current data model is incomplete and tightly coupled to Python. Eachdata model element class directly contains the Python source code that is used forgeneration. Furthermore as already mentioned inside the description of the DSL thedata model stores statements like condition, value assignments or parameter as sim-ple string. No validation is performed and they are simply inserted in the generatedPython code. Therefore they must be valid Python. That may not be obvious to thetest developer who can easily produce errors.

Error reporting and validation If the test case contains a syntactical error, the user hasto interpret the error message of the Python interpreter which interprets the generatedPython code. For a user without experience in Python it may be difficult to backtrackthe error to a specific statement inside the Excel test case. This is due to the factthat there is a change in the abstraction level from Excel to Python but this is notreversed for error reporting. Furthermore by now no satisfying validation of the testspecification is performed. Part of the reason lies in the next elaborated point.

Generated code From the Excel specification Python code is generated. As there is nospecial debugging facility sometimes this code has to be debugged manually. How-ever it is not as easy readable as a normal Python code because each service callis wrapped inside the step function which ensures correct error handling and largerepetitive blocks for WAIT instruction processing.

Framework It is not possible to stop or restart a service. Moreover only one serviceinstance can exist. Starting the same service with different parameters is impossible.Services are tightly coupled to the service manager.

Tools As Excel is the main language editor no supporting features like code completion,syntax highlighting or error checking before the execution is available. Also no de-bugger is available. So a tester has no support for debugging his tests.

Language constructs Different language constructs have drawbacks. The QUEUEVARI-ABLE command creates a special variable. To query this variable (a queue) imple-mentation and Python knowledge is needed. Another example is the WAIT command.It is not possible to explicitly wait for more then one event (trigger). Additionally ifan event occurs, the wait is always terminated.

78

Flexibility Deployment and practical use of the DSL and the framework showed that of-ten a complex Python code is embedded inside commands like setting a variable.Some service calls take or return complex structures like lists or hash tables. Thiscode is not captured by the data model and moreover is not checked. Nonethelessthere seems to be a need for more complex statements and functionality like lists ormathematical functions.

This can be summarized in the following statements:

• The TestDSL language is practically just powerful enough with embedded Python.

• The current specification of the data model is lacking of important properties.

• Error checking and reporting capabilities are improvable.

• There is no good reason to use Excel as test specification environment despite aneasier parser implementation. A better editor and a debugger would be useful.

Solution approach

A number of solutions are possible to solve the discussed problem. It was decided todevelop a new domain specific language which orchestrates the existing framework butdoes not suffer from the described problems. Not all facts are known to the author butother possibilities like using TTCN3 were discarded for reasons such as its only commercialavailability, vendor lock-in, invested effort into the existing framework which is difficult toplug into TTCN3 easily or bad read,write and maintainability of TTCN3 [17].

Design

The first step is to drop Excel and replace it by a plain textual notation. This solves prob-lems with versioning, comparability and vendor lock-in.

The design of the language and the implementation strategy evolved in different itera-tions. An earlier approach considered the development of a completely new DSL includingelements of the current language. The idea was overthrown because the language elementswere far away from being complete for defining a usable language. A replacement syntaxfor parts which are by now defined in Python would have to be specified. This would havelead to a reinvention of expression and condition syntax.

The second idea was based on the principle of embedding discussed in 2.1.8. Someexamples of successfully embedding a language in Python exist [14, 56]. Using availablePython constructs the special test functionality should be represented. This approach wasmore successful as a large number of test language constructs could be represented with aclever usage of the Python language. Different changes were applied to the framework tosupport an embedded test language.

• The Step function was removed and its functionality like error handling and eventqueue checking is implemented in an service call proxy. A service call looks like asimple method call.

79

• The use of the Service Manager is now optional and a service does not depend on itanymore. It can be utilized without the complete framework. Moreover it is possibleto import services directly with a Python import statement.

• Services are made easily start- and stoppable by a single method call. Currentlyenabled triggers are frozen while a service is stopped and resumed on restart. Fur-thermore different instances of a service can exist while it is parametrized at startup.

• Explicit instantiation of queuevariables was removed as queuevariables are alwaysbound to a trigger. Creating a trigger now always return a queuevariable. It is stillpossible to attach a queuevariable to an existing trigger.

• An often used construct was the wait statement14 accompanied by a single timeoutevent. The intended behavior was like a simple system sleep parametrized by theamount of time. Thus a new sleep command is introduced capturing the semantic ina more compact notation.

• The wait construct was extended. Now it is possible to have a wait not terminated bythe first occurring event. It can be exactly stated which events have to occur beforea wait terminates. They can be connected by logic statements. Also guarding eventswith conditions can be accomplished easily.

In listing 5.8 an excerpt from generated Python code is shown followed by listing 5.9showing the embedded approach. Moreover the second listing has more functionality thanthe former. For demonstration a simple string is printed and a trigger which can recognizea crack on the audio line-in of a sound card is started.

However this approach suffers from some of the typical problems encountered usingembedding. Not all of the constructs can be mapped in s satisfying way to Python con-structs, especially those whose concepts are very different from concepts offered in Python(wait). Also it is difficult to modify the error handling and to process exceptions invisiblyto the DSL user. Finally the Python environment does not know about the test constructsand treats them like ordinary Python code, which is not always the intended behavior (inthe editor for example),

The final solution is developed with the help of Frodo. As the goal was not to reinventeverything, the new language is based on the results of the embedding step. To supportdomain specific constructs directly inside Python, Python has to be modified. The idea isreusing the Python grammar and transforming it into a grammar model. Subsequently thegrammar model is modified by injecting test specific constructs. These test specific con-structs are mapped to an extended domain model. But the back-end is still the modifiedPyTAF framework. It does not understand the extended domain model. So a semanticmapping from test specific constructs to Python constructs and to PyTAF calls is defined.To execute a test case, its textual representation is parsed and the domain model is cre-ated, which in turn id transformed into a Python model. The Python model could then beexecuted on top of Python and the PyTAF framework.

14An event loop with a timeout.

80

import sys , os , t h r e a d i n g2 s y s . p a t h . append ( r ’ . . ’ )

import random4 from ccu import ∗

from ccu . Check import ∗6 from ccu . E x p r e s s i o n s import ∗

from t h i r d p a r t y e x t e n s i o n s import ∗8 from u t i l import ∗

10 c l a s s T e s t S e q u e n c e ( Tes tSequenceBase . Tes tSequenceBase ) :def _ _ i n i t _ _ ( s e l f , oSe rv iceManage r ) :

12 s e l f . A u d i o S e r v i c e = oServ i ceManage r . g e t S e r v i c e ( ’ A u d i o S e r v i c e ’ )s e l f . c r a c k = B a s e F u n c t i o n a l i t y . QueueVar i ab l e ( )

14 Tes tSequenceBase . Tes tSequenceBase . _ _ i n i t _ _ ( s e l f , oSe rv i ceManage r )

16 def r u n T e s t S e q u e n c e ( s e l f ) :s e l f . s t e p ( funcAny= s e l f . A u d i o S e r v i c e . say , iLogLine =None , o E r r o r H a n d l e r C l a s s =None ) ( ( " h e l l o wor ld " , ) )

18s e l f . bWai t ing = True

20 s e l f . bTimeOut = F a l s et i m e r = t h r e a d i n g . Timer ( 5 , s e l f . t i m e o u t )

22 t i m e r . s t a r t ( )

24 whi le s e l f . bWai t ing :i f s e l f . bTimeOut :

26 s e l f . bWai t ing = F a l s ei f s e l f . bWai t ing :

28 s e l f . _ w a i t ( )s e l f . checkQueue ( )

30s e l f . s t e p ( funcAny= s e l f . A u d i o S e r v i c e . say , iLogLine =None , o E r r o r H a n d l e r C l a s s =None ) ( ( " a f t e r 5 s e c o n d s " , ) )

32 s e l f . s t e p ( funcAny= s e l f . Audio . E n a b l e T r i g g e r , iLogLine =None , o E r r o r H a n d l e r C l a s s =None )( ( s e l f . c r ack , " 2000 h z T r i g g e r " , " C r a c k T r i g g e r " , "ONCE" , 2000 , ) )

34s e l f . bWai t ing = True

36 s e l f . bTimeOut = F a l s et i m e r = t h r e a d i n g . Timer ( 2 0 0 , s e l f . t i m e o u t )

38 t i m e r . s t a r t ( )

40 whi le s e l f . bWai t ing :i f s e l f . bTimeOut :

42 s e l f . bWai t ing = F a l s ee l s e :

44 o C o n d i t i o n = C o n d i t i o n ( ’ s e l f . hz . l a s t V a l u e ( )==0 ’ )i f o C o n d i t i o n . Eva l ( g l o b a l s ( ) , l o c a l s ( ) ) :

46 s e l f . _oLogger . i n f o ( " Crack d e t e c t e d " )s e l f . bWai t ing = F a l s e

48 t i m e r . c a n c e l ( )i f s e l f . bWai t ing :

50 s e l f . _ w a i t ( )s e l f . checkQueue ( )

52i f __name__== ’ __main__ ’ :

54 oMain = TAF . TAF ( [ ] , { } )oMain . Run ( T e s t S e q u e n c e )

Listing 5.8: Example of generated code for TestDSL

These steps allow to define constructs and behavior that could not be easily realizedwith the embedded approach.

• A wait construct is integrated into Python. It can wait for the arrival of events whichare enqueued in queuevariables. Logical operations like AND and OR are supported.Also a guard condition can be formulated. In general the design is similar to the altstatement in OCCAM or in TTCN3. Listing 5.10 contains an example of this newstatement.

• An easier logging and sleep statement.

• Direct embedding of a subset of YAML as configuration language.

• The user does not need to manually import services anymore. The used services arederived from the service call syntax.

81

1 from s e r v i c e s . A u d i o S e r v i c e import ∗

3 # s t a r t s t h e a u d i o s e r v i c e w i t h a s c a n n i n g r a t e o f 100 , and c a l l s a d e m o n s t r a t i o n methodA u d i o S e r v i c e ( 1 0 0 ) . say ( " h e l l o wor ld " )

5 S l e e p ( 5 )A u d i o S e r v i c e ( 1 0 0 ) . say ( " a f t e r 5 s e c o n d s " )

7 A u d i o S e r v i c e ( 1 0 0 ) . shutdown ( )

9 # s t a r t s t h e A u d i o s S e r v i c e w i t h o u t parame ter s , c a l l s t h e say mehtod a s y n c r o u n o u sa y n c r e s u l t = A u d i o S e r v i c e . say . a sync ( " h e l l o wor ld a s y n c r o n " )

11# w a i t s f o r t h e aync c a l l t o be f i n i s h e d , a t l e a s t one second a t most f i v e s e c o n d s

13 Wait ( Or ( Timeout ( 5 ) , And ( a s y n c r e s u l t , Timeout ( 1 ) ) ) . w a i t ( )

15 A u d i o S e r v i c e . shutdown ( )

17 # r e s t a r t s t h e s e r v i c e , c r e a t e a t r i g g e r and a s s i g n i t t o t h e hz queue v a r i a b l ehz = A u d i o S e r v i c e . e n a b l e C y c l i c H z T r i g g e r ( " 200 hz d e t e c t o r " , 2 0 0 )

19# l o g t h e f r e q u e n c e d e t e c t i o n

21 hz . a c t i o n = lambda hz : l o g ( s t r ( hz )+ " 200 hz f r e q u e n z e d e t e c t e d : "+hz )

23 # c r e a t e s a t r i g g e r which t e r m i n a t e s t h e w a i tc r a c k = A u d i o S e r v i c e . e n a b l e C r a c k T r i g g e r ( " Crack d e t e c t o r " , t e r m i n a t e s W a i t = True )

25# l o g a d e t e c t e d c r a c k

27 c r a c k . a c t i o n = lambda msg : l o g ( " Crack d e t e c t e d ! " )

29 # w a i t s f o r 200 s e c o n d s or u n t i l a c r a c k i s d e t e c t e dWait ( Or ( hz , c rack , Timeout ( 2 0 0 ) ) ) . w a i t ( )

Listing 5.9: Example of the embedded Python test language

• No explicit global exception handler is needed anymore. Start over functionality isnow implicitly generated in comparison to the embedding approach.

To get a better understanding of the extensions, the domain metamodel and the grammarmodel should be examined.

a y n c r e s u l t = A u d i o S e r v i c e . say . a sync ( " h e l l o wor ld a s y n c r o n " )2 w a i t :

on t i m e o u t 5 :4 l o g " Async c a l l d i d n o t r e t u r n i n t ime "

break6 on a s y n c r e s u l t and t i m e o u t 1 :

l o g " e v e r y t h i n g ok "8 break

10# c r e a t e t r i g g e r s

12hz200 = A u d i o S e r v i c e . e n a b l e C y c l i c H z T r i g g e r ( " 200 hz d e t e c t o r " , 2 0 0 )

14 hz300 = A u d i o S e r v i c e . e n a b l e C y c l i c H z T r i g g e r ( " 300 hz d e t e c t o r " , 3 0 0 )c r a c k = A u d i o S e r v i c e . e n a b l e C r a c k T r i g g e r ( " Crack d e t e c t o r " )

16s t a r t t i m e = t ime . t ime ( )

18w a i t :

20 on c r a c k :l o g " Crack d e t e c t e d "

22 breakon t i m e o u t 200 :

24 l o g "No c r a c k i n 200 s e c o n d s "break

26 on hz200 and hz300 :gua rd t ime . t ime ( ) > s t a r t t i m e + 10

28 l o g " 200 hz and 300 hz were d e t e c t e d "

Listing 5.10: Example of the new wait statment

Implementation

To implement the extended Python language (TestDSL), a number of steps are taken. Atfirst a formal description of its grammar understandable by Frodo is needed. Luckily for

82

Python 2.4 such a formal description exists inside the official source repository15. Frodocurrently only supports the reading of ANTLR grammars but the provided grammar has acustom format similar to the EBNF (PyEBNF from now).

module p y g 2 a n t l r ;2 c r e a t e OUT: AntlrMM from IN : PythonGrammar ;

# AntlrMM = Frodo Grammar Metamodel4

r u l e GrammarToParse rClass6 {

from s o u r c e : PythonGrammar ! Grammar8 t o t a r g e t : AntlrMM ! Grammar ( c l a s s D e f i n i t i o n s <− Sequence { p a r s e r } ) ,

p a r s e r : AntlrMM ! P a r s e r S p e c ( i d <− ’ P y t h o n 2 5 P a r s e r ’ , r u l e s <− s o u r c e . r u l e s )10 }

12 r u l e T r a n s l a t e R u l e s{

14 from s o u r c e : PythonGrammar ! Rulet o t a r g e t : AntlrMM ! Rule ( i d <− s o u r c e . name , b l o c k <− aBlock ) ,

16 aBlock : AntlrMM ! Block ( a l t e r n a t i v e s <− Sequence { a A l t } ) ,a A l t : AntlrMM ! A l t e r n a t i v e ( e l e m e n t s <− s o u r c e . e x p r s )

18 }

20 r u l e A l t e r n a t i v e T r a n s f o r m{

22 from s o u r c e : PythonGrammar ! A l t e r n a t i v e E x p rt o e l e m e n t : AntlrMM ! Element ,

24 ebn f : AntlrMM !EBNF( b l o c k <− s u b b l o c k ) ,s u b b l o c k : AntlrMM ! Block −−( a l t e r n a t i v e s <− s o u r c e . a l t e r n a t i v e s −>c o l l e c t ( e | t h i s M o d u l e . newAlt ( e ) ) )

26 do{

28 s u b b l o c k . a l t e r n a t i v e s <− s o u r c e . a l t e r n a t i v e s −>c o l l e c t ( e | t h i s M o d u l e . e l e m e n t T o A l t e r n a t i v e ( e ) ) ;t h i s M o d u l e . c r e a t e C h i l d ( e lement , sou rce , ebn f ) ;

30 }}

32r u l e RuleRef

34 {from s o u r c e : PythonGrammar ! RuleRefExpr

36 t o e l e m e n t : AntlrMM ! Element ,r e f e r e n c e : AntlrMM ! RuleRef ( r e f e r e n c e d R u l e <− s o u r c e . r e f )

38 do{

40 t h i s M o d u l e . c r e a t e C h i l d ( e lement , sou rce , r e f e r e n c e ) ;}

42 }

Listing 5.11: Exerpt from the Python grammar metamodel to Frodo metamodel transfor-mation

Two solution are possible: introducing support for PyEBNF into Frodo or creatinga Python grammar metamodel, parsing the grammar, creating elements conforming thismetamodel and then transforming it into the Frodo grammar metamodel. The second solu-tion is chosen because at the development time of the DSL the Frodo grammar metamodelwas still not finished. Meanwhile creating a ECore metamodel for PyEBNF grammars wasfeasible in a short amount of time. The PyEBNF is then parsed with a custom writtenANTLR parser creating the according model elements16. This parser can parse the spec-ification for the Python 2.4 language and also Python 2.5 because they are defined withthe same PyEBNF grammar. If the grammar format does not change, switching to a newPython version can be done automatically, at least for the grammar.

To be able to work with the grammar model it needs to be transformed from the PythonPyEBNF grammar metamodel to Frodo’s grammar metamodel. This transformation is done

15Similar to EBNF. http://svn.python.org/view/python/trunk/Grammar/16The PyEBNF grammar can be implemented as a Frodo DSL. However as Frodo and the TestDSL were

developed in parallel, Frodo was not matured enough to pursue this approach from the beginning. Yet this isfuture work and could be part of a major refactoring.

83

with ATL (listing 5.11).Certain problems arise in and after this step. First, the Python grammar does not contain

a formal token description but to be able to use the grammar, a lexer which constructs thetokens referenced in the grammar is needed. The solution is reuse again: a Python lexergrammar is available17 for ANTLR and can therefore be used as a grammar model withinFrodo. Another transformation, this time defined in Python instead of ATL because onlysmall changes are introduced, combines the lexer grammar model and the parser grammarmodel.

The second problem lies in the unified grammar model and arises if a parser is directlygenerated from it. In contradiction to an official statement18 the original Python grammar isnot LL(1). A generated ANTLR parser can not decide on three productions employing fi-nite look ahead (listing 5.12). Increasing the look ahead does not solve the problem becauseit is impossible to match the rules using a top-down19 approach. Inside the CPython20 im-plementation custom code deals with this case. To allow the generation of a working parseranother transformation is introduced. It transforms the three ambiguous rules so they canbe matched with a finite look ahead. All other rules can be matched by a maximum lookahead of two.

After these corrective transformations the parser which is generated from the grammarmodel is able to parse every available Python program21: it successfully parses the Pythonlanguage test suite. However no actions are associated with the recognition of rules at themoment.

From successful parsing a Python AST should be created. The AST elements shouldalso be represented by model elements conforming to an AST metamodel. Again the avail-able AST metamodel elements are automatically derived from an available specification22.In the next step the existing Python grammar model is annotated using a top-down visitorwith actions to instantiate the matching AST metamodel elements starting at the root rule.An implicit derivation of the model elements to create was impossible in this case, as theAST differs to much from the grammar.

The parser which is generated from the grammar model is now able to construct aAST model. Finally a last transformation from this model to a real AST is applied. Thereal AST is then execute on top of the Python runtime after successful parsing. To verifythe implementation the parser was tested against the standard test suite and successfully

17Small modifications are made to the lexer grammar because it only supported Python 2.3.18http://www.python.org/dev/peps/pep-3099/19ANTLR generates a top-down parser.20The first and major Python implementation is written in C and often referred to as CPython, because in

the meantime a .Net and a Java Python implementation exist (IronPython and Jython).21With one restriction. The only supported charset is UTF.22http://svn.python.org/projects/python/trunk/Tools/compiler/ast.txt

Python 2.4 contains this specification and also implements classes to create, modify and execute a PythonAST. However inside the C implementation a concrete syntax tree is used not an AST nor the defined ASTclasses. This changed in Python 2.5. The compiler is now built upon a AST. Yet the classes used to representthis AST are not the classes available in the Python 2.4 standard library rather than a new development. Tomake this case even more difficult, the AST classes inside the standard library of Python 2.4 were updated toPython 2.5 and are still included. However they are not used in the compiler. The classes used in the compilercan currently only be instantiated from C. A unification in the future would be useful and remove redundancy.

84

executed all tests.

1 a r g l i s t _ o r g i n a l : ( a rgument ’ , ’ )∗ ( a rgument [ ’ , ’ ] | ’∗ ’ t e s t [ ’ , ’ ’∗∗ ’ t e s t ] | ’∗∗ ’ t e s t )

3 a r g l i s t _ r e w r i t e n : a rgument ( ’ , ’ a rgument )∗ [ ’ , ’ [ ’∗ ’ t e s t [ ’ , ’ ’∗∗ ’ t e s t ] | ’∗∗ ’ t e s t ] ]| ’∗ ’ t e s t [ ’ , ’ ’∗∗ ’ t e s t ] | ’∗∗ ’ t e s t

5# F i r s t r u l e i s n o t ma tchab le w i t h f i n i t l ookahead

7 # R e w r i t t e n r u l e i s ma tchab le w i t h f i n i t l ookahead# E l e m e n t s i n sq uar e b r a c k e t s are o p t i o n a l

Listing 5.12: Example of unmatchable rule with finite lookahead and a solution.

Now as the Python parser is in place, the domain model for the TestDSL is speci-fied. This domain model includes the new concepts which should be introduced to Pythonsuch as the wait construct and extends the Python AST metamodel. Moreover transfor-mations from domain specific elements to a set of Python AST elements are defined (asimple example is the transformation of the model element representing log “something”to the AST call element Logger.log with the sub AST for parameters (currentLogging-Mode,timestamp,”something”) attached). These transformations can also modify the cur-rent AST model. The Python AST elements represent the semantic of a domain modelelement and can be simple transformations into a call or complex instructions orchestratingthe PyTAF framework.

Having specified the TestDSL domain model and therefore the specific model elementsthe current Python grammar model is modified. The modification introduces new rules tothe grammar programmatically. These rules contain the productions used to recognize thetextual representation of domain model elements and also the actions to create those andattach them to the Python AST model resulting in a mixed model. The drawback of thisapproach is, that the developer has to know which Python rule has to be extended.

A parser generated from this grammar model is able to parse the TestDSL which isPython including the domain specific constructs though the instantiated model is not exe-cutable in this form.

Finally to allow execution, the transformations resulting from the domain model toPython AST metamodel mapping is applied, turning the mixed model into a pure PythonAST model. This model and therefore the DSL can be executed.

To allow error reporting and later debugging every Python AST and TestDSL modelelement stores its corresponding line and column number in the textual representation.Also a simple Eclipse based editor is generated from the TestDSL grammar model.

Results

It could be argued that the new language is a GPL like Python, however it provides clearlydomain specific constructs. It is advised not to use all available Python features (for exam-ple leaving out classes or decorators is advisable). Moreover they could be easily removedfrom the language. The reason for avoiding this is of practical nature. In most cases the ba-sic Python expression syntax, lists and functions and the additional test specific constructsare sufficient to specify a test case, yet in rare cases advanced features may be needed.

Compared to the original Excel DSL the new TestDSL offers many advantages. Mostof the named problems are solved such as the ability to associate a Python exception with

85

a DSL element. Furthermore it is easy to introduce23 semantic checks because everythingis a model, for example with OCL. Also early prototypical debugging is available. Withmore precise error messages the TestDSL can be considered as usable.

Frodo allowed the reuse of many existing artifacts and reduced the development timefor the TestDSL. Also the artifact forming the TestDSL can be further reused, for imple-menting new language features, for analysis or model based test generation. The TestDSLproves that Frodo fulfills some of the initially formulated requirements like reusability anda decreased development effort. Ease of use and language evolution support can be im-proved further.

Language evolution support was a requirement for Frodo but is currently not directlysupported inside the framework and for that reason neither for the TestDSL. It could beimplemented by defining transformations between different versions of the domain meta-model and preserving the grammar models for each version. So even an automatic transla-tion from an older TestDSL version to a newer one is possible provided that they still havecommonalities.

23Using an external tool.

86

Part III

Conclusions

87

Chapter 6

Future work

“The best way to predict the future is to invent it.”1

In the following and short overview about possible future work is pre-sented, first for Frodo and then for the test automation language.

The combination of DSL development with an Model-Driven Engineering approach is stillan ongoing field of research. Many gaps still exist and Frodo fills some of them. Neverthe-less the framework is far from being a complete solution and improvements on both sidestheoretical foundations and practical implementation are possible.

Furthermore the model-driven TestDSL can be enhanced in different directions whichmaybe a better domain model or a totally different syntax front-end like TTCN3 or a de-fined subset of it.

6.1 DSL Framework

6.1.1 Theoretical outlookThe framework proposes different improvements to the model-driven development of do-main specific languages. For example the derivation of an generative grammar from thegrammar metamodel. This derivation was not completed in this thesis and no explicit the-oretical foundation was developed. Yet such a foundation in the context of model-drivengrammars could be useful, not only for the proposed framework.

Another aspect is the grammar metamodel. The metamodel is currently polluted byANTLR specific elements. Refactoring this model can improve its reusability and makeit more independent of Frodo. Moreover the model does not include generally applicableelements usable to describe parser error handling, recovery or domain specific error report-ing. The error handling implementation differs from parser generator to parser generator,finding an expressive abstraction can result in comparable domain specific error reportingfor the generated parsers. One more possible improvement could be an algorithm for au-tomatically determining the power of the needed parser (i.e. LL(0), LL(1)) and selecting a

1Theodore Hook

88

certain generator automatically. This can be accomplished by a configuration of the targetplatform / language so an exactly matching generator is selected.

To save development effort an implicit by name mapping from domain model to gram-mar rules was specified. Using this approach the flexibility of the grammar is constraint.Finding better conventions for the mapping can mitigate some of the constraints and wouldbe an interesting further work.

An idea worth to examine is an special metamodel aware grammar with advancedimplicit mapping by convention abilities and the possibility to execute transformation ormodel modifications directly from the grammar.

If an explicit mapping is used the actions are defined in the target language. Findinga way to specify explicit actions target language independent could improve reuse evenmore. A starting point is the Kermeta language.

Finally it can be very useful to examine model checking for grammar models. Differ-ent Model-Driven Engineering tools can be used therefore but at first it must be stated whatshould be checked. Interesting properties are validity and consistency after a modifica-tion or transformation, whether a grammar model is ambiguous given a specific class (likeLL(1)) or if problem occur in the implicit mapping between grammar model and domainmodel.

6.1.2 Practical outlookFrodo is a prototype implementation of the proposed framework and therefore not fullycomplete. Different directions for further improvements can be taken.

First, the only supported parser generator is ANTLR at the moment. To get some ofthe described benefits of a tool agnostic grammar metamodel support for other parser back-ends can be added. To allow this step the grammar metamodel should be freed of anyANTLR related construct like exception handling.

Another idea is the implementation of the grammar parser with the help of Frodo as ev-ery grammar is itself a DSL. This would unify the parser generator grammar parser creationand allows the model-driven modification for example adopting to a new parser generatorversion.

Furthermore Frodo showed preliminary generation of different language tools. Gener-ating a working debugger is especially intriguing and was not accomplished in this thesis.Also the integration with the environments can be smoothed. Currently many scripts needto be called manually for example the execution of ATL transformations.

As a demonstration implementation Frodo showed already some of the potential lyingin a MDE approach to DSL development, yet numerous other features could be integrated.

6.2 TestDSLThe test language can also be subject of further improvements. The domain metamodelis at the moment a mixture of the Python AST model and domain specific constructs. Itcould be useful to express more language elements directly in the domain model. Forexample service calls are at the moment ordinary Python calls and therefore only a Python

89

AST element in the model. This would allow even easier model-based generation of testcase for input data because Python AST elements are merely needed for the expressionlanguage.

One use case for the model-based generation is the transformation of existing Excel testcases. A temporary ECore metamodel including an Excel parser which creates conformingmodel elements already exists for the old test automation language. A working transforma-tion would allow the reuse of already written test cases. As such a transformation is rathertrivial, it was not included.

Another direction which can be explored is offering another new front end to the test au-tomation framework. While the new TestDSL was driven by practical considerations usinga more formalized language like TTCN3 could offer a new class of benefits. Test engineersalready used to TTCN3 could easily create test cases still using the existing framework.Furthermore TTCN3 is the only language test specification and implementation languagewhich is standardized at the moment and also different research project try to integrate newideas like TPT2 for continuous stream testing. Because of Frodos reuse capabilities existingTTCN3 grammars could be used like the ANTLR grammar from the TRex3 project.

Because the TestDSL is now based on a model, examining model-based test generationis also interesting and could reduce manual testing efforts greatly as first experiments withmodel-based generation of MMI tests showed at the BMW Group.

Finally also the usage of the language itself in practice will guide its further develop-ment and should therefore be monitored. Concepts which fit the needs of the test developershould be improved, unnecessary constructs dropped and new useful constructs added.

2Time Partion Testing[120]3A TTCN3 language refactoring tool.

90

Chapter 7

Summary

“Even for the physicist the description in plain language will be a criterionof the degree of understanding that has been reached.”1

The final chapter gives a survey of what has been done, what has been learned and drawsconclusions. Furthermore some of the major contributions are discussed.

7.1 SurveyThis thesis discusses the model-driven development of domain specific languages, pro-posed a model-driven DSL framework -Frodo- and showes some of the possible benefitswith the help of two examples. At the start, a broad overview about the two major technicalresearch areas is given.

Domain specific languages were explained, including a discussion about their advan-tages, different development patterns and a description of supporting tools and frameworks.The second major topic was Model-Driven Engineering, a new software engineering ap-proach based on models. To understand MDE, important terms (metamodel, technologi-cal space), key concepts (transformations, DSMLs) and technologies were elaborated. Anew approach tries to combine DSL development and MDE technology resulting in model-driven DSL frameworks like TCS/AMMA and XText/oAW which are directly related workto this thesis and were explained, too.

The main part of this thesis proposed a framework following a model-driven approachlike the previous named frameworks. It should fulfill requirements such as reusability,a decreased development effort for DSL, usability of the generated DSL and support forlanguage evolution. Frodo, the implementation of the proposal showed what kind ofDSL/MDE tools could be used for model-driven DSL development (like ANTLR or ATL)and how to combine them. Moreover the architecture leads to a model based separation ofconcerns and makes language artifact exchangeable with other MDE tools and frameworks.

With the help of Frodo and language specification artifacts a DSLs could be created.The current framework implementation supports the reuse of existing ANTLR grammarsand can create a grammar model out of them. Frodo allows nearly every imaginable textual

1Werner Karl Heisenberg

91

representation2 for a domain model through explicit or implicit mapping from grammarelements to model elements. The implicit mapping helps to reduce the DSL developmenteffort but is restricted to domain models similar to the texutal representation. Frodo alsoincreases the DSL usability by the automatic generation of an Eclipse based editor. Themore interesting goal of generating a debugger was not reached in a general applicableway. Yet some prototypical experiments show the possibility of debugger generation usingmodel and grammar aspects.

A complex language implemented with Frodo is the TestDSL, a replacement for thecurrently used test automation language specified in Excel sheets which was analyzed inthis thesis, The Excel language has some design flaws. It misses a profound languagefoundation and it offers no error reporting or exception mapping between DSL and testexecution language. The new TestDSL solves most of these problems and mitigates therest.

While developing the TestDSL, different approaches for DSL implementation were ap-plied. At first embedding, resulting in a cleaner language directly embedded into the Pythonhost language. Moreover useful modifications to the test automation framework which iscontrolled by the language were a result. This approach improved upon the existing lan-guage but not all feature could be embedded natively in Python.

With Frodo the missing features were implemented as a superset of Python. In thisprocess heavy reuse of existing artifacts like the Python grammar or the Python AST spec-ification was made. A large number of practical experience was put into the TestDSLwhich is not only applicable in the automotive domain. Also in comparison to TTCN3,the language itself is better readable and writable. Admittedly, TTCN3 is more than justa language. Beyond the language, features like error reporting and exception mapping be-tween DSL and the back-end were implemented in a model-driven way with Frodo. Thegenerated TestDSL editor completes the new DSL.

This more complex example showed that it is possible to develop a sophisticated do-main specific language with Frodo. Also through reuse of Python and its artifacts thedevelopment time was decreased. Nevertheless the framework user still needs expertise inlanguage development and understanding of the modeling concepts and the target domain.Creating reusable and easily extendable artifacts is possible with Frodo, the goal of easedDSL development still needs improvements.

Choosing a model-driven approach proved very useful, as it leaded to improved reuseand a large number of leverageable tools. Yet at the moment no broad understanding ofcomplicated terms like metametamodel is available which slows the adaption of a model-driven process.

7.2 ContributionsAs final words, some of the main contributions of this thesis should be enumerated.

At first a comprehensive overview about the topic model-driven DSL development andits realization with other topics such as DSLs in general and MDE was given. Secondly

2Must be recognizable by a context free grammar.

92

a framework which eases the development of such languages was presented including aproposed architecture and explanation why certain parts are needed. This was done basedon a list of specific requirements.

On the practical side, Frodo, a prototype implementing some of the proposed function-ality, was developed, and can serve as guidance for further implementations. This proto-type also contains reusable artifacts like an ECore implementation for the Python languagewhich is, at least as known to the author, the only other implementation then the Java/EMFone. Furthermore a usable grammar metamodel and an ANTLR parser for transformingANTLR grammars into the metamodel and back to their textual representation was devel-oped, For example a refactoring tool for grammar could easily reuse these components. Atleast as known to the author non of the other framework allows the direct reuse of existinggrammars.

Besides the ANTLR grammar metamodel a complete Python grammar metamodel isavailable and can be a starting point for further modifications or extensions to the Pythonlanguage as a base for DSLs. Without modifications Python 2.4 can be parsed and executedon a Python 2.4 or 2.5 back-end.

Finally the TestDSL language and its generated editor can be considered a contribu-tion allowing easier formulation of tests including a domain specific error handling andlanguage checking.

To some extent a number of jigsaw pieces were added to the ongoing quest for an“engineering discipline for grammarware” [106].

93

Appendix A

Fundamental Modeling Concepts

The notation of FMC was used at several places in this thesis. As it is not as widelyknown as UML, it is introduced by a short citation and a reference sheet for the used blockdiagrams. [108, 183]

“The Fundamental Modeling Concepts (FMC) primarily provide a frame-work for the comprehensive description of software-intensive systems. It isbased on a precise terminology and supported by a precise graphical notationoptimized for human comprehension. Modeling we call the intellectual activ-ity of creating a model of some system with the goal to capture its essentialstructures necessary to understand its (existing or planned) behaviour (inter-nal and to its environment) and to describe these structures in a comprehensiveway. Against that background, didactics take an important position in that ap-proach.”

94

Figure A.1: FMC block diagram example

95

Figure A.2: FMC block diagram reference sheet

96

Appendix B

Statement of Academic Honesty

Hiermit erkläre ich an Eides statt, dass ich die vorliegende Arbeit selbständig nur unterBenutzung der in der Arbeit angegebenen Literatur angefertigt habe.

Martin Karlsch, Berlin den 12. Januar 2007

97

Bibliography

[1] ANTLR Grammar Repository. URL http://www.antlr.org/grammar/list. [Online; accessed 19-January-2007].

[2] The Catalog of Compiler Construction Tools. URL http://catalog.compilertools.net. [Online; accessed 10-December-2006].

[3] The Generic Eclipse Modeling System, 2006. URL http://www.dre.vanderbilt.edu/~jules/gems.htm. [Online; accessed 19-January-2007].

[4] TokTok, the DSTC’s implementation of the OMG’s HUTN standard. URL http://www.dstc.edu.au/Research/Projects/Pegamento/TokTok/.

[5] ATL Transformations. URL http://www.eclipse.org/m2m/atl/atlTransformations/. [Online; accessed 19-January-2007].

[6] Aditya Agrawal. Graph Rewriting And Transformation (GReAT): A Solution ForThe Model Integrated Computing (MIC) Bottleneck. In 18th IEEE InternationalConference on Automated Software Engineering, 2003.

[7] Marcus Alanen. EMF/ECORE Integration in the Coral Modeling Framework. InProceedings of the NWUML’06: The 4th Nordic Workshop on UML and SoftwareModelling, 2006.

[8] Marcus Alanen and Ivan Porres. Coral: A Metamodel Kernel for TransformationEngines. In Proceedings of the Second Europena Workshop on Model Driven Ar-chitecture (MDA), number 17, pages 165–170, Canterbury, Kent CT2 7NF, UnitedKingdom, Sep 2004. University of Kent.

[9] E. Allen, D. Chase, V. Luchangco, J.-W. Maessen, S. Ryu, G. Steele, and S. Tobin-Hochstadt. The Fortress language specification version 0.707. Technical report, SunMicrosystems, 2005.

[10] José M. Alvarez, Andy Evans, and Paul Sammut. Mapping between Levels in theMetamodel Architecture. In UML ’01: Proceedings of the 4th International Con-ference on The Unified Modeling Language, Modeling Languages, Concepts, andTools, pages 34–46, London, UK, 2001. Springer-Verlag. ISBN 3-540-42667-1.

[11] Daniel Amyot, Hanna Farah, and Jean-Francois Roy. Evaluation of DevelopmentTools for Domain-Specific Modeling Languages. In SAM, pages 183–197, 2006.

98

[12] Matthias Anlauff. XASM - An Extensible, Component-Based ASM Language. InASM ’00: Proceedings of the International Workshop on Abstract State Machines,Theory and Applications, pages 69–90, London, UK, 2000. Springer-Verlag. ISBN3-540-67959-6.

[13] I. Attali, C. Courbis, P. Degenne, A. Fau, J. Fillon, C. Held, D. Parigot, andC. Pasquier. Aspect and XML-oriented Semantic Framework Generator SmartTools,2001.

[14] J. Aycock. Compiling little languages in Python. In Proc. 7th Int. Python Conf.,Houston, TX, 1998.

[15] Jonthan Bachrach and Keith Playford. The Java syntactic extender (JSE). In OOP-SLA ’01: Proceedings of the 16th ACM SIGPLAN conference on Object orientedprogramming, systems, languages, and applications, pages 31–42, New York, NY,USA, 2001. ACM Press. ISBN 1-58113-335-9.

[16] Jason Baker and Wilson C. Hsieh. Maya: multiple-dispatch syntax extension in Java.In PLDI ’02: Proceedings of the ACM SIGPLAN 2002 Conference on Programminglanguage design and implementation, pages 270–281, New York, NY, USA, 2002.ACM Press. ISBN 1-58113-463-0.

[17] Paul Baker, Shiou Loh, and Frank Weil. Model-Driven Engineering in a Large In-dustrial Context - Motorola Case Study. In MoDELS, pages 476–491, 2005.

[18] A. Basu, M. Hayden, G. Morrisett, and T. von Eicken. A Language-Based Approachto Protocol Construction. In Proc. ACM SIGPLAN Workshop on Domain SpecificLanguages, January 1997.

[19] Don Batory, Bernie Lofaso, and Yannis Smaragdakis. JTS: tools for implement-ing domain-specific languages. In Proceedings Fifth International Conference onSoftware Reuse, pages 143–153, Victoria, BC, Canada, 2–5 1998. IEEE.

[20] Ira D. Baxter, Christopher Pidgeon, and Michael Mehlich. DMS: Program Transfor-mations for Practical Scalable Software Evolution. In ICSE ’04: Proceedings of the26th International Conference on Software Engineering, pages 625–634, Washing-ton, DC, USA, 2004. IEEE Computer Society. ISBN 0-7695-2163-0.

[21] Kent Beck and Cynthia Andres. Extreme Programming Explained: EmbraceChange (2nd Edition). Addison-Wesley Professional, 2004. ISBN 0321278658.

[22] Oren Ben-Kiki, Clark Evans, and Brian Ingerson. YAML Ain’t Markup Language,Version 1.1. 2004.

[23] J. L. Bentley. Programming Pearls. Addison-Wesley, 1989.

[24] L. Bichler. Codegeneratoren für MOF-basierte Modellierungssprachen. PhD thesis,Universität der Bundeswehr München, Neubiberg, 11 2004.

99

[25] Judith Bishop. Multi-platform user interface construction: a challenge for softwareengineering-in-the-small. In ICSE ’06: Proceeding of the 28th international con-ference on Software engineering, pages 751–760, New York, NY, USA, 2006. ACMPress. ISBN 1-59593-375-1.

[26] E. Bjarnason. APPLAB – A Laboratory for Application Languages. Technicalreport, Lund Institute of Technology, 19961996.

[27] Per Bjesse, Koen Claessen, Mary Sheeran, and Satnam Singh. Lava: hardwaredesign in Haskell. In ICFP ’98: Proceedings of the third ACM SIGPLAN inter-national conference on Functional programming, pages 174–184, New York, NY,USA, 1998. ACM Press. ISBN 1-58113-024-4.

[28] Xavier Blanc, Marie-Pierre Gervais, and Prawee Sriplakich. Model Bus: Towardsthe Interoperability of Modelling Tools. In MDAFA, pages 17–32, 2004.

[29] M. Bloos. Echtzeitanalyse der Kommunikation in KfZ Bordnetzen auf Basis des CANProtokolls. PhD thesis, TU München, 1999.

[30] Claus Brabrand, Mads Vanggaard, and Michael I. Schwartzbach. The metafront Sys-tem: Extensible Parsing and Transformation. In Proc. 3rd ACM SIGPLAN Workshopon Language Descriptions, Tools and Applications, LDTA ’03. ACM, April 2003.

[31] P. Braun and F. Marschall. The Bi-directional Object-Oriented Transformation Lan-guage. Technical report, Technische Universität München, 2003.

[32] Martin Bravenboer and Eelco Visser. Concrete syntax for objects: domain-specificlanguage embedding and assimilation without restrictions. In OOPSLA ’04: Pro-ceedings of the 19th annual ACM SIGPLAN conference on Object-oriented pro-gramming, systems, languages, and applications, pages 365–383, New York, NY,USA, 2004. ACM Press. ISBN 1-58113-831-9.

[33] Frederick P. Brooks. The Mythical Man-Month, chapter No Silver Bullet - Essenceand Accident in Software Engineering, pages 177–203. Addison Wesley LongmanInc., New York, 15., aufl. edition, 2001.

[34] S. A. Brown, C. E. Drayton, and B. Mittman. A description of the APT language.Commun. ACM, 6(11):649–658, 1963. ISSN 0001-0782.

[35] Manfred Broy. Challenges in automotive software engineering. In ICSE ’06: Pro-ceeding of the 28th international conference on Software engineering, pages 33–42,New York, NY, USA, 2006. ACM Press. ISBN 1-59593-375-1.

[36] Manfred Broy, Michael Deißenböck, and Markus Pizka. A holistic approach tosoftware quality at work. In 3rd World Conference for Software Quality (3WCSQ),September 2005.

[37] Frank Budinsky, David Steinberg, Ed Merks, Raymond Ellersick, and TimothyGrose. Eclipse Modeling Framework. Addison Wesley Professional, 2003.

100

[38] L. Burgy, C. Consel, F. Latry, J. Lawall, N. Palix, and L. Réveillère. LanguageTechnology for Internet-Telephony Service Creation. In IEEE International Con-ference on Communications, JUNE 2006. URL http://phoenix.labri.fr/publications/talks/icc06.pdf.

[39] Jean Bézivin. On the Unification Power of Models. Software and System Mod-eling (SoSym), 4(2):171–188, 2005. URL http://www.lina.sciences.univ-nantes.fr/Publications/2005/Bé05b.

[40] Jean Bézivin. On the unification power of models. Software and Systems Modeling,4(2):171–188, May 2005. URL http://www.metapress.com/link.asp?id=XN50242535640K10.

[41] Jean Bézivin and Olivier Gerbé. Towards a Precise Definition of the OMG/MDAFramework. In ASE ’01: Proceedings of the 16th IEEE international conferenceon Automated software engineering, page 273, Washington, DC, USA, 2001. IEEEComputer Society.

[42] Jean Bézivin, C. Brunette, R. Chevrel, Frédéric Jouault, and Ivan Kurtev. Bridgingthe Generic Modeling Environment (GME) and the Eclipse Modeling Framework(EMF). In OOPSLA Workshop on Best Practices for Model Driven Software De-velopment, 2005. URL http://www.lina.sciences.univ-nantes.fr/Publications/2005/BBCJK05.

[43] Jean Bézivin, Guillaume Hillairet, Frédéric Jouault, Ivan Kurtev, and William Piers.Bridging the MS/DSL Tools and the Eclipse Modeling Framework. In Proceed-ings of the International Workshop on Software Factories at OOPSLA 2005, SanDiego, California, USA, 2005. URL http://softwarefactories.com/workshops/OOPSLA-2005/Papers/Bezivin.pdf.

[44] Jean Bézivin, Fabian Büttner, Martin Gogolla, Frédéric Jouault, Ivan Kurtev, andArne Lindow. Model Transformations? Transformation Models! In MoDELS,pages 440–453, 2006.

[45] Jean Bézivin, Jean-Marie Favre, and Bernhard Rumpe. Introduction to GaMMa2006 first international workshop on global integrated model management. InGaMMa ’06: Proceedings of the 2006 international workshop on Global integratedmodel management, pages 1–3, New York, NY, USA, 2006. ACM Press. ISBN1-59593-410-3.

[46] Stefano Ceri, Piero Fraternali, and Aldo Bongio. Web Modeling Language(WebML): a modeling language for designing Web sites. Computer Networks (Am-sterdam, Netherlands: 1999), 33(1–6):137–157, 2000.

[47] Philippe Charles, Julian Dolby, Robert M. Fuhrer, Stanley M. Sutton Jr., and Man-dana Vaziri. SAFARI: a meta-tooling framework for generating language-specificIDE’s. In OOPSLA Companion, pages 722–723, 2006.

101

[48] Shigeru Chiba. A Metaobject Protocol for C++. In ACM Conference on Object-Oriented Programming Systems, Languages, and Applications (OOPSLA’95), SIG-PLAN Notices 30(10), pages 285–299, Austin, Texas, USA, October 1995.

[49] C. Consel, H. Hamdi, L. Réveillère, L. Singaravelu, H. Yu, and C. Pu. Spidle: ADSL approach to specifying streaming applications. Technical Report RR1282-02,LaBRI, Bordeaux, France, October 2002.

[50] James R. Cordy. The TXL source transformation language. Sci. Comput. Program.,61(3):190–210, 2006. ISSN 0167-6423.

[51] Corinna Cortes, Kathleen Fisher, Daryl Pregibon, and Anne Rogers. Hancock: alanguage for extracting signatures from data streams. In KDD ’00: Proceedings ofthe sixth ACM SIGKDD international conference on Knowledge discovery and datamining, pages 9–17, New York, NY, USA, 2000. ACM Press. ISBN 1-58113-233-6.

[52] Douglas Crockford. JSON: The Fat-Free Alternative to XML, 2006. URL http://www.json.org/xml.html. [Online; accessed 19-December-2006].

[53] Krzysztof Czarnecki and Simon Helsen. Classification of Model TransformationApproaches. In OOPSLA 2003 Workshop on Generative Techniques in the contextof Model Driven Architecture, oct 2003. URL http://www.softmetaware.com/oopsla2003/czarnecki.pdf.

[54] Ricardo de Almeida Falbo, Giancarlo Guizzardi, and Katia Cristina Duarte. Anontological approach to domain engineering. In SEKE ’02: Proceedings of the 14thinternational conference on Software engineering and knowledge engineering, pages351–358, New York, NY, USA, 2002. ACM Press. ISBN 1-58113-556-4.

[55] Joel de Guzman. Spirit Parser Framework, 2006. URL http://spirit.sourceforge.net/distrib/spirit_1_8_3/libs/spirit/index.html. [Online; accessed 5-January-2007].

[56] Jan Decaluwe. MyHDL: a python-based hardware description language. Linux J.,2004(127):5, 2004. ISSN 1075-3583.

[57] Verband der Automobilindustrie. Auto Annual Report, 2006. URL http://www.vda.de/en/service/jahresbericht/files/VDA_2006_en.pdf.

[58] A. van Deursen and P. Klint. Domain-Specific Language Design Requires FeatureDescriptions. Journal of Computing and Information Technology, 10(1):1–17, 2002.URL http://www.cwi.nl/~arie/papers/fdl/fdl.pdf.

[59] P. Devanbu and J. Poulin, editors. Modular Domain Specific Languages and Tools,1998. IEEE Computer Society Press.

[60] D. Di Ruscio, F. Jouault, I. Kurtev, J. Bézivin, and A. Pierantonio. ExtendingAMMA for Supporting Dynamic Semantics Specifications of DSLs. Technical re-port, LINA, 2006.

102

[61] E. W. Dijkstra. Notes on structured programming. In O.-J. Dahl, C. A. R. Hoare,and E. W. Dijkstra, editors, Structured Programming, pages 1–82. 1972.

[62] BMW Group Information and Communication Systems division. Python Test Au-tomation Framework, 2006.

[63] Dominic Duggan. A Mixin-Based, Semantics-Based Approach to Reusing Domain-Specific Programming Languages. In ECOOP ’00: Proceedings of the 14th Euro-pean Conference on Object-Oriented Programming, pages 179–200, London, UK,2000. Springer-Verlag. ISBN 3-540-67660-0.

[64] Sven Efftinge and Markus Völter. oAW xText: A framework for textual DSLs. InEclipse Summit 2006 Workshop: Modeling Symposium, 2006.

[65] Conal Elliott, Sigbjoern Finne, and Oege De Moor. Compiling embedded languages.J. Funct. Program., 13(3):455–481, 2003. ISSN 0956-7968.

[66] Eric Evans. Domain-Driven Design: Tacking Complexity In the Heart of Software.Addison-Wesley Longman Publishing Co., Inc., Boston, MA, USA, 2003. ISBN0321125215.

[67] Rickard E. Faith, Lars S. Nyland, and Jan F. Prins. KHEPERA: A System for RapidImplementation of Domain Specific Languages. pages 243–256.

[68] Jean M. Favre. Towards a Basic Theory to Model Model Driven Engineering. Work-shop on Software Model Engineering, October 2004.

[69] Jean-Marie Favre. Foundations of Meta-Pyramids: Languages vs. Metamodels –Episode II: Story of Thotus the Baboon1. In Jean Bezivin and Reiko Heckel, editors,Language Engineering for Model-Driven Software Development, number 04101 inDagstuhl Seminar Proceedings. Internationales Begegnungs- und Forschungszen-trum fuer Informatik (IBFI), Schloss Dagstuhl, Germany, 2005.

[70] Jean-Marie Favre. Foundations of Model (Driven) (Reverse) Engineering : Models– Episode I: Stories of The Fidus Papyrus and of The Solarus. In Jean Bezivin andReiko Heckel, editors, Language Engineering for Model-Driven Software Develop-ment, number 04101 in Dagstuhl Seminar Proceedings. Internationales Begegnungs-und Forschungszentrum fuer Informatik (IBFI), Schloss Dagstuhl, Germany, 2005.

[71] Matthias Felleisen, Robert Bruce Findler, Matthew Flatt, and Shriram Krishna-murthi. Fostering Little Languages. Dr. Dobb’s Journal, March 2004. URLhttp://www.ddj.com/documents/ddj0403a/.

[72] Raphael A. Finkel. Advanced Programming Language Design. Addison-WesleyLongman Publishing Co., Inc., Boston, MA, USA, 1995. ISBN 0805311912.

[73] Frédéric Fondement, Rémi Schnekenburger, Sébastien Gérard, and Pierre-AlainMuller. Metamodel-Aware Textual Concrete Syntax Specification. Technical re-port, 2006.

103

[74] Martin Fowler. Language Workbenches: The Killer-App for Domain Specific Lan-guages? May 2005. URL http://www.martinfowler.com/articles/languageWorkbench.html.

[75] William Frakes, Ruben Prieto-Diaz, and Christopher Fox. DARE: Domain analysisand reuse environment. Ann. Softw. Eng., 5:125–141, 1998. ISSN 1022-7091.

[76] Didier Vojtisek Cyril Faucher Franck Fleurey, Zoé Drey. Kermeta language - Refer-ence manual, 2007.

[77] Steve Freeman and Nat Pryce. Evolving an embedded domain-specific language inJava. In OOPSLA ’06: Companion to the 21st ACM SIGPLAN conference on Object-oriented programming systems, languages, and applications, pages 855–865, NewYork, NY, USA, 2006. ACM Press. ISBN 1-59593-491-X.

[78] Erich Gamma, Richard Helm, Ralph Johnson, and John Vliaides. Design Patterns,Elements of Reusable Object-Oriented Software. Addison-Wesley Profeaional Com-puting Series. Addison-Wesley, Boston, San Francisco, New York, 1995. ISBN 0-201-63361-2.

[79] Anna Gerber and Kerry Raymond. MOF to EMF: there and back again. In eclipse’03: Proceedings of the 2003 OOPSLA workshop on eclipse technology eXchange,pages 60–64, New York, NY, USA, 2003. ACM Press.

[80] ETAS GmbH. LABCAR-AUTOMATION V2.1, 2006. URL http://de.etasgroup.com/products/labcar/software_in_detail.shtml#automation. [Online; accessed 26-December-2006].

[81] Adele Goldberg. Why Smalltalk? Commun. ACM, 38(10):105–107, 1995. ISSN0001-0782.

[82] Jack Greenfield and Keith Short. Software factories: assembling applications withpatterns, models, frameworks and tools. In OOPSLA ’03: Companion of the 18thannual ACM SIGPLAN conference on Object-oriented programming, systems, lan-guages, and applications, pages 16–27, New York, NY, USA, 2003. ACM Press.ISBN 1-58113-751-6.

[83] R. Grønmo and J. Oldevik. An Empirical Study of the UML Model TransformationTool (UMT). In Proc. of the 1st Int. Conf. on Interoperability of Enterprise Softwareand Applications, 2005.

[84] James R. Groff and Paul N. Weinberg. SQL, the complete reference. Osborne /McGraw-Hill, 1999. ISBN 0-07-211845-8.

[85] Bernd Hardung, Thorsten Külzow, and Andreas Krüger. Reuse of software in dis-tributed embedded automotive systems. In EMSOFT ’04: Proceedings of the 4thACM international conference on Embedded software, pages 203–210, New York,NY, USA, 2004. ACM Press. ISBN 1-58113-860-1.

104

[86] Jan Hendrik Hausmann. Dynamic Meta Modeling - A Semantics Description Tech-nique for Visual Modeling Languages. PhD thesis, University of Paderborn, 2005.

[87] David Hearnden, Kerry Raymond, and Jim Steel. Anti-Yacc: MOF-to-Text. InEDOC ’02: Proceedings of the 6th International Enterprise Distributed ObjectComputing Conference, pages 200–211, Washington, DC, USA, 2002. IEEE Com-puter Society. ISBN 0-7695-1742-0.

[88] P.R. Henriques, M.J.V. Pereira, M. Mernik, M. Lenic, J. Gray, and H. Wu. Auto-matic generation of language-based tools using the LISA system. IEE Proceedings- Software, 152(2):54–69, 2005. URL http://link.aip.org/link/?IPS/152/54/1.

[89] CAP Gemini Innovation Hewlett Packard, Matra Marconi Space. Domain AnalysisMethod. Deliveable D3.2B, PROTEUS ESPRIT project 6086, 1994.

[90] Ellis Horowitz. Programming Languages: A Grand Tour. Computer Science Press,Rockville, Maryland, third edition, 1987.

[91] M. Huisman. The calculation of a polytypic parser. Master’s thesis, Utrecht Univer-sity, 1996. Master Thesis.

[92] Capers Jones. Programming Languages Table, 1996. URL http://www.theadvisors.com/langcomparison.htm. [Online; accessed 05-January-2007].

[93] Frédéric Jouault and Jean Bézivin. KM3: a DSL for Metamodel Specification. pages171–185, 2006. URL http://www.sciences.univ-nantes.fr/lina/atl/www/papers/KM3-FMOODS06.pdf.

[94] Frédéric Jouault and Jean Bézivin. On the Specification of Textual Syntaxes forModels. In Eclipse Modeling Symposium, Eclipse Summit Europe 2006, 2006.

[95] Frédéric Jouault and Ivan Kurtev. On the Architectural Alignment of ATL andQVT. In ACM Symposium on Applied Computing (SAC), model transforma-tion track, 2006. URL http://www.lina.sciences.univ-nantes.fr/Publications/2006/JK06.

[96] Frédéric Jouault, Jean Bézivin, and Ivan Kurtev. TCS: a DSL for the specification oftextual concrete syntaxes in model engineering. In GPCE ’06: Proceedings of the5th international conference on Generative programming and component engineer-ing, pages 249–254, New York, NY, USA, 2006. ACM Press. ISBN 1-59593-237-2.

[97] Basim M. Kadhim and William M. Waite. Maptool - Supporting Modular Syn-tax Development. In CC ’96: Proceedings of the 6th International Conference onCompiler Construction, pages 268–280, London, UK, 1996. Springer-Verlag. ISBN3-540-61053-7.

105

[98] Audris Kalnins, Janis Barzdins, and Edgars Celms. Model Transformation LanguageMOLA. In MDAFA, pages 62–76, 2004.

[99] Samuel N. Kamin. Programming languages: an interpreter-based approach.Addison-Wesley Longman Publishing Co., Inc., Boston, MA, USA, 1990. ISBN0-201-06824-9.

[100] K.C. Kang, S.G. Cohen, J.A. Hess, W.E. Novak, and A.S. Peterson. Feature-Oriented Domain Analysis (FODA) Feasibility Study. Technical Report CMUSEI-90-TR-21, Software Engineering Institute, CMU, November 1990.

[101] Hayato Kawashima and Katsuhiko Gondow. Experience with ANSI C Markup Lan-guage for a Cross-Referencer. In HICSS ’03: Proceedings of the 36th Annual HawaiiInternational Conference on System Sciences (HICSS’03) - Track 9, page 324.3,Washington, DC, USA, 2003. IEEE Computer Society. ISBN 0-7695-1874-5.

[102] Brian W. Kernighan. The C Programming Language. Prentice Hall ProfessionalTechnical Reference, 1988. ISBN 0131103709.

[103] Gregor Kiczales, Jim des Rivieres, and Daniel G. Bobrow. The Art of the MetaobjectProtocol. Cambridge, Mass., 1991.

[104] Holger M. Kienle. Using smgn for Rapid Prototyping of Small Domain-SpecificLanguages. 36(9):64–73, September 2001. ISSN 0362-1340.

[105] Anneke Kleppe, Jos Warmer, and Wim Bast. MDA Explained. The Model DrivenArchitecture: Practice and Promise. Addison-Wesley, 2003.

[106] Paul Klint, Ralf Lämmel, and Chris Verhoef. Toward an engineering discipline forgrammarware. ACM Trans. Softw. Eng. Methodol., 14(3):331–380, 2005. ISSN1049-331X.

[107] J. W. Klop. Term rewriting systems. pages 1–116, 1992.

[108] Andreas Knopfel, Bernhard Grone, and Peter Tabeling. Fundamental ModelingConcepts: Effective Communication of IT Systems. John Wiley & Sons, May 2006.ISBN 047002710X.

[109] Eugene Kohlbecker, Daniel P. Friedman, Matthias Felleisen, and Bruce Duba. Hy-gienic macro expansion. In LFP ’86: Proceedings of the 1986 ACM conferenceon LISP and functional programming, pages 151–161, New York, NY, USA, 1986.ACM Press. ISBN 0-89791-200-4.

[110] Dimitrios S. Kolovos, Richard F. Paige, and Fiona A.C. Polack. Model comparison:a foundation for model composition and model transformation testing. In GaMMa’06: Proceedings of the 2006 international workshop on Global integrated modelmanagement, pages 13–20, New York, NY, USA, 2006. ACM Press. ISBN 1-59593-410-3.

106

[111] G. Kramler, G. Kappel, T. Reiter, E. Kapsammer, W. Retschitzegger, andW. Schwinger. Towards a semantic infrastructure supporting model-based tool in-tegration. In GaMMa ’06: Proceedings of the 2006 international workshop onGlobal integrated model management, pages 43–46, New York, NY, USA, 2006.ACM Press. ISBN 1-59593-410-3.

[112] G. Kramler, G. Kappel, T. Reiter, E. Kapsammer, W. Retschitzegger, andW. Schwinger. Towards a semantic infrastructure supporting model-based tool in-tegration. In GaMMa ’06: Proceedings of the 2006 international workshop onGlobal integrated model management, pages 43–46, New York, NY, USA, 2006.ACM Press. ISBN 1-59593-410-3.

[113] Charles W. Krueger. New methods in software product line practice. Commun.ACM, 49(12):37–40, 2006. ISSN 0001-0782.

[114] Thomas Kühne. What is a Model? In Jean Bezivin and Reiko Heckel, editors,Language Engineering for Model-Driven Software Development, number 04101 inDagstuhl Seminar Proceedings. Internationales Begegnungs- und Forschungszen-trum fuer Informatik (IBFI), Schloss Dagstuhl, Germany, 2005.

[115] Ivan Kurtev and Klaas van den Berg. MISTRAL: A Language for Model Trans-formations in the MOF Meta-modeling Architecture. In MDAFA, pages 139–158,2004.

[116] Ivan Kurtev, Jean Bezivin, , and Mehmet Aksit. Technological Spaces: An InitialAppraisal. In CoopIS, DOA’2002 Federated Conferences, Industrial track, Irvine,USA, 2002.

[117] Ivan Kurtev, Jean Bézivin, Frédéric Jouault, and Patrick Valduriez. Model-basedDSL frameworks. In OOPSLA ’06: Companion to the 21st ACM SIGPLAN confer-ence on Object-oriented programming systems, languages, and applications, pages602–616, New York, NY, USA, 2006. ACM Press. ISBN 1-59593-491-X.

[118] Michael Lawley and Jim Steel. Practical Declarative Model Transformation withTefkat. In MoDELS Satellite Events, pages 139–150, 2005.

[119] A. Ledeczi, M. Maroti, A. Bakay, G. Karsai, J. Garrett, C. Thomason, G. Nordstrom,J. Sprinkle, and P. Volgyesi. The Generic Modeling Environment. In Workshop onIntelligent Signal Processing, Budapest, Hungary, volume 17, May 2001.

[120] Eckard Lehmann. Time Partition Testing - Systematischer Test des kontinuier-lichen Verhaltens von eingebetteten Systemen. PhD thesis, Technischen UniversitÄatBerlin, 2003.

[121] Michael R. Levy. Web programming in guide. Softw. Pract. Exper., 28(15):1581–1603, 1998. ISSN 0038-0644.

[122] Holloway C. M. Lfm2000 - Fifth NASA Langley Formal Methods Workshop. Tech-nical report, 2000.

107

[123] Alanen Marcus and Porres Ivan. Difference and Union of Models. Technical Report527, TUCS, April 2003.

[124] Stephen J. Mellor and Marc Balcer. Executable UML: A Foundation for Model-Driven Architectures. Addison-Wesley Longman Publishing Co., Inc., Boston, MA,USA, 2002. ISBN 0201748045. Foreword By-Ivar Jacoboson.

[125] Tom Mens and Pieter Van Gorp. A Taxonomy of Model Transformation. ElectronicNotes in Theoretical Computer Science, 152:125–142, March 2006.

[126] Marjan Mernik, Jan Heering, and Anthony M. Sloane. When and how to de-velop domain-specific languages. ACM Comput. Surv., 37(4):316–344, December2005. ISSN 0360-0300. URL http://portal.acm.org/citation.cfm?id=1118890.1118892.

[127] Microsoft. Microsoft Domain Specific Language Tool. URL http://msdn.microsoft.com/vstudio/DSLTool.

[128] Sachio Mizuta and Runhe Huang. Automation of Grid Service Code Generationwith AndroMDA for GT3. In AINA ’05: Proceedings of the 19th InternationalConference on Advanced Information Networking and Applications, pages 417–420,Washington, DC, USA, 2005. IEEE Computer Society. ISBN 0-7695-2249-1.

[129] Pierre-Alain Muller and Michel Hassenforder. HUTN as a Bridge between Model-Ware and GrammarWare. In WISME Workshop, MODELS / UML’2005, MontegoBay, Jamaica, 2005.

[130] Bonnie A. Nardi. A small matter of programming: perspectives on end user com-puting. MIT Press, Cambridge, MA, USA, 1993. ISBN 0-262-1405305.

[131] J. M. Neighbors. Draco: a method for engineering reusable software systems. pages295–319, 1989.

[132] James Neighbors. Software Construction Using Components. PhD thesis, Universityof California Irvine, 1980.

[133] Inc. Object Management Group. UML 2.0 Specification. http://www.uml.org/UML2.0, 2003.

[134] Inc. Object Management Group. Human-Usable Textual Notation, v1.0, 2004. URLhttp://www.omg.org/technology/documents/formal/hutn.htm.

[135] Inc. Object Management Group. Meta Object Facility (MOF) 2.0 Core Specifica-tion. Object Management Group, Inc., 2004. URL http://www.omg.org/cgi-bin/apps/doc?ptc/03-10-04.pdf.

[136] Inc. Object Management Group. Meta Object Facility (MOF) 2.0 Query/View/Trans-formation Specification - Final Adopted Specification. Object Management Group,Inc., 2005. URL http://www.omg.org/docs/ptc/05-11-01.pdf.

108

[137] Inc. Object Management Group. SysML Specification 1.0. Object Manage-ment Group, Inc., 2006. URL http://www.omg.org/cgi-bin/doc?ptc/06-05-04.

[138] Martin Odersky, Philippe Altherr, Vincent Cremet, Burak Emir, Sebastian Maneth,Stéphane Micheloud, Nikolay Mihaylov, Michel Schinz, Erik Stenman, andMatthias Zenger. An Overview of the Scala Programming Language. Techni-cal Report IC/2004/64, École Polytechnique Fédérale de Lausanne, 1015 Lau-sanne, Switzerland, 2004. URL http://scala.epfl.ch/docu/files/ScalaOverview.pdf. Revised June 3, 2005.

[139] Didier Parigot. Towards domain-driven development: the smartTools software fac-tory. In OOPSLA ’04: Companion to the 19th annual ACM SIGPLAN conference onObject-oriented programming systems, languages, and applications, pages 37–38,New York, NY, USA, 2004. ACM Press. ISBN 1-58113-833-4.

[140] Terence Parr. A Functional Language For Generating Structured Text. URL http://www.cs.usfca.edu/~parrt/papers/ST.pdf. 2006.

[141] Terence J. Parr and Russell W. Quong. ANTLR: A Predicated-LL(k) Parser Gener-ator. Software Practice and Experience, 25(7):789–810, 1995.

[142] Octavian Patrascoiu. Model Transformations in YATL. Studies and Experiments.Technical Report 3-04, March 2004. URL http://www.cs.kent.ac.uk/pubs/2004/1863.

[143] Jurgen Vinju Paul Klint, Tijs van der Storm. Term Rewriting Meets Aspect OrientedProgramming. In Aart Middeldorp, Vincent van Oostrom, Femke van Raamsdonk,and Roel C. de Vrijer, editors, Processes, Terms and Cycles: Steps on the Road toInfinity, Essays Dedicated to Jan Willem Klop, on the Occasion of His 60th Birthday,volume 3838 of Lecture Notes in Computer Science. Springer, 2005.

[144] Luis Pedro, Levi Lucio, and Didier Buchs. Principles for System Prototype and Ver-ification Using Metamodel Based Transformations. In RSP ’06: Proceedings of theSeventeenth IEEE International Workshop on Rapid System Prototyping (RSP’06),pages 10–17, Washington, DC, USA, 2006. IEEE Computer Society. ISBN 0-7695-2580-6.

[145] Mikael Peltier. MTrans, a DSL for Model Transformation. In EDOC ’02: Pro-ceedings of the Sixth International ENTERPRISE DISTRIBUTED OBJECT COM-PUTING Conference (EDOC’02), page 190, Washington, DC, USA, 2002. IEEEComputer Society. ISBN 0-7695-1656-4.

[146] Muller Pierre-Alain. Weaving Executability into Object-Oriented Meta-Languages.In MODELS/UML’2005, pages 264–278. Springer. URL http://www.irisa.fr/triskell/publications/testbib/triskellbib/Muller05a.

109

[147] Ruben Prieto-Diaz. Domain analysis: an introduction. SIGSOFT Softw. Eng. Notes,15(2):47–54, 1990. ISSN 0163-5948.

[148] Arend Rensink. Subjects, Models, Languages, Transformations. In Jean Bezivin andReiko Heckel, editors, Language Engineering for Model-Driven Software Develop-ment, number 04101 in Dagstuhl Seminar Proceedings. Internationales Begegnungs-und Forschungszentrum fuer Informatik (IBFI), Schloss Dagstuhl, Germany, 2005.

[149] Armin Rigo and Samuele Pedroni. PyPy’s approach to virtual machine construction.In OOPSLA ’06: Companion to the 21st ACM SIGPLAN conference on Object-oriented programming systems, languages, and applications, pages 944–953, NewYork, NY, USA, 2006. ACM Press. ISBN 1-59593-491-X.

[150] Vincent Rosener and Denis Avrilionis. Elements for the definition of a model ofsoftware engineering. In GaMMa ’06: Proceedings of the 2006 international work-shop on Global integrated model management, pages 29–34, New York, NY, USA,2006. ACM Press. ISBN 1-59593-410-3.

[151] Davide Di Ruscio, Frédéric Jouault, Ivan Kurtev, Jean Bézivin, and Alfonso Pieran-tonio. A Practical Experiment to Give Dynamic Semantics to a DSL for TelephonyServices Development. Technical Report 06.03, LINA, 2006. URL http://www.lina.sciences.univ-nantes.fr/Publications/2006/RJKBP06a.

[152] Andrea Schauerhuber, Manuel Wimmer, and Elisabeth Kapsammer. Bridging ex-isting Web modeling languages to model-driven engineering: a metamodel forWebML. In ICWE ’06: Workshop proceedings of the sixth international confer-ence on Web engineering, page 5, New York, NY, USA, 2006. ACM Press. ISBN1-59593-435-9.

[153] Douglas C. Schmidt, Hans Rohnert, Michael Stal, and Dieter Schultz. Pattern-Oriented Software Architecture, Volume 2: Patterns for Concurrent and NetworkedObjects. John Wiley & Sons, Inc., New York, NY, USA, 2000. ISBN 0471606952.URL http://portal.acm.org/citation.cfm?id=557786.

[154] Eric C. Schnarr, Mark D. Hill, and James R. Larus. Facile: a language and compilerfor high-performance processor simulators. In PLDI ’01: Proceedings of the ACMSIGPLAN 2001 conference on Programming language design and implementation,pages 321–331, New York, NY, USA, 2001. ACM Press. ISBN 1-58113-414-2.

[155] A. Schürr, A. Winter, and A. Zündorf. PROGRES: Language and Environment. InH. Ehrig, G. Engels, H. Kreowski, and G. Rozenberg, editors, Handbook on GraphGrammars and Computing by Graph TransformationApplications, Languages, andTools, volume 2, pages 487–550. World Scientific, Singapur, 1999.

[156] Ed Seidewitz. What Models Mean. IEEE Softw., 20(5):26–32, 2003. ISSN 0740-7459.

110

[157] Hana Sevikova, Alan Borning, David Socha, and Wolf-Gideon Bleek. Automatedtesting of stochastic systems: a statistically grounded approach. In ISSTA ’06: Pro-ceedings of the 2006 international symposium on Software testing and analysis,pages 215–224, New York, NY, USA, 2006. ACM Press. ISBN 1-59593-263-1.

[158] M. Simos and J. Anthony. Weaving the Model Web: A Multi-Modeling Approachto Concepts and Features in Domain Engineering. In ICSR ’98: Proceedings of the5th International Conference on Software Reuse, page 94, Washington, DC, USA,1998. IEEE Computer Society. ISBN 0-8186-8377-5.

[159] Emin Gün Sirer and Brian N. Bershad. Using production grammars in software test-ing. In PLAN ’99: Proceedings of the 2nd conference on Domain-specific languages,pages 1–13, New York, NY, USA, 1999. ACM Press. ISBN 1-58113-255-7.

[160] Eric J. Smith. Codesmith: Template based code generation, 2006. URL http://www.codesmithtools.com. [Online; accessed 19-December-2006].

[161] Diomidis Spinellis. Notable Design Patterns for Domain Specific Lan-guages. Journal of Systems and Software, 56(1):91–99, February 2001.ISSN 0164-1212. URL http://www.dmst.aueb.gr/dds/pubs/jrnl/2000-JSS-DSLPatterns/html/dslpat.html.

[162] Vijayan Sugumaran, Sooyong Park, and Kyo C. Kang. Software product line engi-neering: Introduction. Commun. ACM, 49(12):28–32, 2006. ISSN 0001-0782.

[163] Alistair Sutcliffe and Nikolay Mehandjiev. End-user development: tools that em-power users to create their own software solutions. Communications of the ACM.SPECIAL ISSUE: End-user development, 47(9), September 2004. See Table of Con-tents.

[164] Michiaki Tatsubori, Shigeru Chiba, Kozo Itano, and Marc-Olivier Killijian. Open-Java: A Class-Based Macro System for Java. In OORaSE, pages 117–133, 1999.

[165] Richard N. Taylor, Will Tracz, and Lou Coglianese. Software development usingdomain-specific software architectures: CDRl A011 a curriculum module in the SEIstyle. SIGSOFT Softw. Eng. Notes, 20(5):27–38, 1995. ISSN 0163-5948.

[166] Scott Thibault, Renaud Marlet, and Charles Consel. Domain-Specific Languages:From Design to Implementation Application to Video Device Drivers Generation.Software Engineering, 25(3):363–377, 1999.

[167] Dave Thomas, David Hansson, Leon Breedt, Mike Clark, Thomas Fuchs, and An-drea Schwarz. Agile Web Development with Rails (The Facets of Ruby Series). Prag-matic Bookshelf, July 2005. ISBN 097669400X.

[168] Andrea Valerio, Giancarlo Succi, and Massimo Fenaroli. Domain analysis andframework-based software development. SIGAPP Appl. Comput. Rev., 5(2):4–15,1997. ISSN 1559-6915.

111

[169] Mark van den Brand, Arie van Deursen, Jan Heering, H. A. de Jong, Merijn de Jonge,Tobias Kuipers, Paul Klint, Leon Moonen, Pieter A. Olivier, Jeroen Scheerder, Jur-gen J. Vinju, Eelco Visser, and Joost Visser. The ASF+SDF Meta-environment: AComponent-Based Language Development Environment. In Computational Com-plexity, pages 365–370, 2001.

[170] Mark van den Brand, Bas Cornelissen, Pieter Olivier, and Jurgen Vinju. TIDE: AGeneric Debugging Framework - Tool Demonstration. Electronic Notes in Theoret-ical Computer Science, 141(4):161–165, 2005.

[171] Frank van der Linden, editor. Proceedings of the Second International ESPRITARES Workshop on Development and Evolution of Software Architectures for Prod-uct Families, London, UK, 1998. Springer-Verlag. ISBN 3-540-64916-6.

[172] Arie van Deursen and Paul Klint. Little languages: little maintenance? In 62,page 17. Centrum voor Wiskunde en Informatica (CWI), ISSN 1386-369X, 30 1997.

[173] Ghica van Emde Boas. Fantastic, unique, UML tool for the Java environment(FUUT-je) (poster session). In OOPSLA ’00: Addendum to the 2000 proceedings ofthe conference on Object-oriented programming, systems, languages, and applica-tions (Addendum), pages 109–110, New York, NY, USA, 2000. ACM Press. ISBN1-58113-307-3.

[174] Frank van Harmelen and Deborah L. McGuinness. Feature Synopsis forOWL Lite and OWL, July 2002. URL http://www.w3.org/TR/2002/WD-owl-features-20020729/. W3C Working Draft.

[175] Gergely Varro, Andy Schurr, and Daniel Varro. Benchmarking for Graph Trans-formation. In VLHCC ’05: Proceedings of the 2005 IEEE Symposium on VisualLanguages and Human-Centric Computing (VL/HCC’05), pages 79–88, Washing-ton, DC, USA, 2005. IEEE Computer Society. ISBN 0-7695-2443-5.

[176] Todd L. Veldhuizen. C++ Templates as Partial Evaluation. In Partial Evaluationand Semantic-Based Program Manipulation, pages 13–18, 1999.

[177] Eelco Visser. Stratego: A Language for Program Transformation based on RewritingStrategies. System Description of Stratego 0.5. In A. Middeldorp, editor, RewritingTechniques and Applications (RTA’01), volume 2051 of Lecture Notes in ComputerScience, pages 357–361. Springer-Verlag, May 2001.

[178] Konrad Voigt. Eine praxisnahe Evaluierung von QVT am Beispiel von UML undXML. URL http://www2.informatik.hu-berlin.de/Institut/struktur/systemanalyse/zweckverband/qvt_uml_xml_rev.pdf.March 2006.

[179] Robert Wagner. Developing Model Transformations with Fujaba. In Holger Gieseand Bernhard Westfechtel, editors, Proc. of the 4th International Fujaba Days 2006,Bayreuth, Germany, volume tr-ri-06-275 of Technical Report, pages 79–82. Univer-sity of Paderborn, September 2006.

112

[180] Qian Wang and Gopal Gupta. Rapidly prototyping implementation infrastructure ofdomain specific languages: a semantics-based approach. In SAC ’05: Proceedingsof the 2005 ACM symposium on Applied computing, pages 1419–1426, New York,NY, USA, 2005. ACM Press. ISBN 1-58113-964-0.

[181] David A. Watt. Programming language concepts and paradigms. Prentice-Hall,Inc., Upper Saddle River, NJ, USA, 1990. ISBN 0-13-728874-3.

[182] David M. Weiss and Chi Tau Robert Lai. Software product-line engineering: afamily-based software development process. Addison-Wesley Longman PublishingCo., Inc., Boston, MA, USA, 1999. ISBN 0-201-69438-7.

[183] Siegfried Wendt and Frank Keller. FMC: An Approach Towards Architecture-Centric System Development. In Proceedings of 10th IEEE Symposium and Work-shops on Engineering of Computer Based Systems, Huntsville Alabama USA (2003),pages 173–182, April 2003. Proceedings of 10th IEEE Symposium and Workshopson Engineering of Computer Based Systems.

[184] Wikipedia. Semi-Thue-System — Wikipedia, Die freie Enzyklopädie,2006. URL http://de.wikipedia.org/w/index.php?title=Semi-Thue-System&oldid=19764219. [Online; accessed 5-March-2007].

[185] Wikipedia. List of compiler-compilers — Wikipedia, The Free Encyclopedia,2007. URL http://en.wikipedia.org/w/index.php?title=List_of_compiler-compilers&oldid=105714730. [Online; accessed 14-February-2007].

[186] David Wile. Lessons learned from real DSL experiments. Sci. Comput. Program.,51(3):265–290, 2004. ISSN 0167-6423.

[187] Hui Wu, Jeff Gray, Suman Roychoudhury, and Marjan Mernik. Weaving a debug-ging aspect into domain-specific language grammars. In SAC ’05: Proceedings ofthe 2005 ACM symposium on Applied computing, pages 1370–1374, New York, NY,USA, 2005. ACM Press. ISBN 1-58113-964-0.

[188] Eric Van Wyk, Lijesh Krishnan, Derek Bodin, and Eric Johnson. Adding domain-specific and general purpose language features to java with the java language ex-tender. In OOPSLA ’06: Companion to the 21st ACM SIGPLAN conference onObject-oriented programming systems, languages, and applications, pages 728–729, New York, NY, USA, 2006. ACM Press. ISBN 1-59593-491-X. doi: http://doi.acm.org/10.1145/1176617.1176696.