Software Language Engineering: Creating Domain-Specific Languages Using Metamodels - Softcover

Kleppe, Anneke G.

Softcover

ISBN 10: 0321553454 ISBN 13: 9780321553454

Publisher: Addison-Wesley Professional, 2008

Synopsis

Software practitioners are rapidly discovering the immense value of Domain-Specific Languages (DSLs) in solving problems within clearly definable problem domains. Developers are applying DSLs to improve productivity and quality in a wide range of areas, such as finance, combat simulation, macro scripting, image generation, and more. But until now, there have been few practical resources that explain how DSLs work and how to construct them for optimal use.

 

Software Language Engineering fills that need. Written by expert DSL consultant Anneke Kleppe, this is the first comprehensive guide to successful DSL design. Kleppe systematically introduces and explains every ingredient of an effective

language specification, including its description of concepts, how those concepts are denoted, and what those concepts mean in relation to the problem domain. Kleppe carefully illuminates good design strategy, showing how to maximize the flexibility of the languages you create. She also demonstrates powerful techniques for creating new DSLs that cooperate well with general-purpose languages and leverage their power.

 

Completely tool-independent, this book can serve as the primary resource for readers using Microsoft DSL tools, the Eclipse Modeling Framework, openArchitectureWare, or any other DSL toolset. It contains multiple examples, an illustrative running case study, and insights and background information drawn from Kleppe’s leading-edge work as a DSL researcher.

 

Specific topics covered include

 

• Discovering the types of problems that DSLs can solve, and when to use them
• Comparing DSLs with general-purpose languages, frameworks, APIs, and other approaches
• Understanding the roles and tools available to language users and engineers
• Creating each component of a DSL specification
• Modeling both concrete and abstract syntax
• Understanding and describing language semantics
• Defining textual and visual languages based on object-oriented metamodeling and graph transformations
• Using metamodels and associated tools to generate grammars
• Integrating object-oriented modeling with graph theory
• Building code generators for new languages
• Supporting multilanguage models and programs

 

This book provides software engineers with all the guidance they need to create DSLs that solve real problems more rapidly, and with higher-quality code.

About this title

About the Author

Anneke Kleppe has over twenty years of experience in IT. She started her career in telecommunications and then worked as an independent consultant with her own company, Klasse Objecten. She has coached and trained employees of companies working with MDA, OCL, and UML. Currently, she is a consultant at Capgemini and is responsible for the introduction of domain-specific languages for various clients.

Excerpt. © Reprinted by permission. All rights reserved.

Preface

Preface

This book started out as a PhD thesis, a work I started rather late in my career. In it you can find a condensed report of the knowledge that I have gained over the years, on the topic of designing languages for the software industry. I hope this book will be helpful for you in learning about languages, what their constituting elements are and how they can be defined. However, before you start reading, I would like to explain why this book is not a thesis.

Not a Thesis

As it turned out, for me it was a wrong move to go from industry to academia. There are certain requirements to a PhD thesis (or maybe it is the way these requirements are upheld?) that prohibited a truthful expression of my ideas and insights in the subject matter. First, the work should be new. Second, the work should be judged by a jury of peers. Third, the work should be based on a sound theory. So, you might ask, what’s wrong with that? These requirements certainly appear to be very good ones. Let me elaborate on these for a bit.

For a scientist to be sure that the work he/she is doing is new, requires a large investment in studying what other people have been doing. With the amount of scientists ever growing, as well as the amount of publications per scientist, this requirement can in practice not be verified, only falsified. The limited life span of the average scientist is simply too short in view of the large body of scientific publications. This is the reason that the work of most scientists resembles the work being done by a worm: dissecting a single square yard (or even worse using metrics: a single square meter) of the garden of knowledge completely and ever so thoroughly. Only on this small area the scientist can be sure he/she knows all related work. Unfortunately, the work I wanted to do is better resembled by the work of a bee: visiting the many wonderful flowers in the garden of knowledge and bringing ideas, concepts, and techniques from the one to the other.

Furthermore, one can question this requirement even more fundamentally: what is newness? How do we decide what is new and what is not? The following quote 1 expresses beautifully how deceptive the difference between old and new is.

"... (to) make something that was not there before, ... is deceptive, because the separate elements already existed and floated through history, but they were never before assembled in this manner. Joining, assembling, the new will always consist of that." (Connie Palmen, Lucifer, page 261)

As an example, when Jos Warmer and I created the Object Constraint Language, did we create something new? In one way we did not, because every element of the language was already there: set theory, object-orientation, the notation used in Smalltalk, pre- and postconditions, you name it. Yet somehow we managed to put all these things together like ingredients in a soup, stir them, and end up with something that most people consider to be a new language.

The second scientific requirement is that the work should be judged by a jury of peers. In practice this means that the life of a scientist is all about judging (doing reviews) and being judged (getting reviewed). I have found that this is not beneficial for qualities like open-mindedness and creativity which every scientist is assumed to possess and cherish. Nor does it encourage cooperation, for who takes the credits? This life full of judgement, combined with the pressure to publish regularly, simply does not provide the right breeding ground for innovative research.

Furthermore, who are these peers that should do the judging? When you are a worm-like scientist, most of the times it is possible to find a few others working on the same square yard of the garden; people that are able to understand the work presented. Still many scientists complain about the quality of the reviewers assigned to judge their work. Even worse is the case for a bee-like scientist. Suppose the bee takes an idea from patch A and applies it to patch B. The people in A will not be interested, whereas the people in B will have trouble understanding this strange idea. In a world full of worms the bee has no peers. Please note that I do not object to having worms in the garden of knowledge. The work of the worms is necessary to keep the soil fertile. I just wish there where more bees, because they are just as necessary; without their work the garden cannot bear fruit.

Let’s proceed to the last requirement, which is that the work should be based on a sound theory. Actually, I have found that this requirement collides with the first. If you want to do innovative research, which I do, it appears that in computer science, the advances in theory no longer precede the advances in practice. Most of the major programming languages (Java, C#), modeling languages (UML), combined with model driven software development, application architectures (SOA), network architectures (.Net, J2EE) of the last two decades were conceived in industry. Academic computer science is in danger of slowly becoming an empirical field which studies the advances being made in industry.

Furthermore, most theory in academic computer science is mathematics based. Because only the very basic elements of mathematics are taught to students, most of whom end up working in industry, the gap between theory and practice is growing larger and larger. That leaves us with innovative research on the one side of the gap, in industry, and sound theory on the other, in academia.

A thing that widens the gap even further, is the existence of a certain disdain for applied research in academia. When faced with making their theories applicable to industry most scientists react as the mathematician in a well-known joke. This mathematician wakes up to see a starting fire in his bedroom. He looks at the fire and thinks: "Well, I have got a bucket in kitchen, water in the bathroom, and I know how to apply these to put out the fire. So, all’s well." And he goes back to sleep. In my opinion, progress in computer science is not only about knowing how to do things, but also about doing them. Specially because doing things always poses new challenges, thus providing you with extra knowledge about how to do (or not to do) these things. On the other hand, a different type of disdain exists in industry. Scientist are regarded as being strange creatures that speak gibberish and are extremely unpractical. Because of this, people from industry are rather reluctant to use new ideas from academia, even when they are good ones.

As is, this book is not a thesis. It presents some things that are new but which are based on existing concepts, and some things which are old but still relevant for software language design. It is not in detail judged by peers, although many parts have been published in reviewed conferences. Finally, I am certain that the theory on which it is based, leaves lots of room for worm-like scientists to work on and improve what is presented here.

What is in this Book

If this book is not a thesis, then what can you expect to find in it? First, there are many areas of expertise that can contribute to your knowledge of software languages. In this book the following areas of expertise will be visited (randomly ordered):

• Fundamental Mathematics
• Graphs and Graph Transformations
• Philosophy
• Grammars and Compiler Technology
• Computational linguistics
• Visual Language Design
• Natural languages research
• Modeling and Metamodeling
• Model Driven Software Development

Not all of these areas are as standalone as they appear to be. Studying the wealth of knowledge that these areas comprise, you can find many connections between them and similarities in the concepts used. Examples are grammar versus metamodel, model versus graph, and textual versus visual (graphical) language. Building on these connections and similarities, this book offers you:

• A way to define languages (textual and visual), including their semantics, based on object-oriented (meta)modeling and graph transformations.
• An insight in the differences and similarities of the theories of textual and visual languages.
• Additions to the integration of object-oriented modeling with graph theory.
• A method for generating (1) a grammar from a metamodel and (2) the tools for supporting this.
• Insights in how to built a code generator for a new language.
• A way to create support for multi-language models/programs.

What you will not find in this book is a step-by-step plan of how to create a new software language. Instead it shows you what the ingredients of a language specification are and how each of these can be best expressed.

Acknowledgements

During the years many people have helped me gain the knowledge that I am sharing with you in this book, for which I am very grateful to them. However, there are a number of people that on this occasion deserve special attention. First and foremost, I want to thank Arend Rensink for given me the opportunity to experience life in academia. We cooperated on the work for Chapter 5, and together with Harmen Kastenberg we worked on the topic of operational semantics for software languages, which you can find in Chapter 9. In all this he proved to be much more than a worm-like scientist: open and broad-minded, while remaining critical on details and underlying theory.

I would also like to thank another former colleague from the University of Twente: Theo Ruys. Our discussions on the grammar generator where very helpful. My thanks go to David Akehurst for working with me on the comparison of textual and graphical syntaxes, to Jos Warmer for his cooperation on multi-language support, and to my students for bringing some fun into my research. Certainly the reviewers of early versions of this book deserve to be mentioned: Tony Clark, Ron Kersic, Markus Vöter, Anders Hessellund, Dave Hendricksen, and Barney Boisvert. I am grateful for their remarks, which hopefully made this book a better read for all of you.

Finally I want to thank the Netherlands Organization for Scientific Research (NWO) which funded the GRASLAND project at the University of Twente of which I have been part.

Finally

As I wrote in the first paragraph of this preface, I hope this book will be helpful for you in learning about software languages. Like the author of a thesis I too feel that I have gained some good insights in this topic. I have written this book simply to offer my knowledge to you, its reader. Whether or not you agree with what I write, I hope it will improve your knowledge of the subject.

Soest, Netherlands, June 2008

1Translated from Dutch by AK. The original quote is "... wanneer je zelf iets maakt wat er niet eerder was, ... is dat bedrieglijk, want de afzonderlijke elementen bestonden wel en zweefden in de geschiedenis, maar ze werden nooit eerder op deze wijze samengebracht. Samenbrengen, bijeenvoegen, het nieuwe zal altijd daaruit bestaan."

© Copyright Pearson Education. All rights reserved.

Edition details

• Publisher: Addison-Wesley Professional
• Publication date: 2008
• ISBN 10: 0321553454
• ISBN 13: 9780321553454
• Binding: Paperback
• Language: English
• Edition number: 1
• Number of pages: 207