Software Language Engineering Creating Domain-Specific Languages Using Metamodels

by Kleppe, Anneke

• ISBN13: 9780321553454
• ISBN10: 0321553454
• Edition: 1st
• Format: Paperback
• Copyright: 2008-12-09
• Publisher: Addison-Wesley Professional

Summary

The definitive guide to Domain Specific Languages (DSLs): the newest breakthrough in software engineering productivity and quality.  The first comprehensive, tool-independent guide to DSL design.  Clearly explains all the complex concepts that DSL creators and users need to understand: syntax, semantics, and much more.  For DSL developers in all environments, from advanced software engineering to vertical markets.  By a leading expert who has created DSLs as a participant in both UML and OCL design. More and more software engineers are turning to Domain Specific Languages (DSLs) to solve specific types of problems, or to enhance software productivity and quality. This complete guide to DSL design will be invaluable to professionals interested in advanced techniques ranging from model-driven development to software factories - many of whom have no previous experience in creating new languages. Completely tool-independent, this book can serve as a primary resource for readers using Microsoft DSL tools, the Eclipse Modeling Framework, Open Architecture Ware, or any other toolset. Experienced DSL creator and researcher Anneke Kleppe introduces and explains every ingredient of an effective language specification, including its description of concepts, its description of how those concepts are denoted, and its description of the concepts' meaning and relationship to the specific domain. Kleppe carefully illuminates good design strategy, showing how to achieve maximum flexibility. Readers will also learn how to create new languages that cooperate well with other languages, and contain references to elements written in those languages. The book contains multiple examples, as well as a running case study, handy summaries, and references, as well as a glossary and abbreviation list. Sidebars, figures, and cartoons present insights and background knowledge designed to help software engineers create successful DSLs as rapidly as possible.

Author Biography

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.

Table of Contents

Background Information	p. xvii
Preface	p. xix
Foreword	p. xxvi
Why Software Language Engineering?	p. 1
An Increasing Number of Languages	p. 2
Software Languages	p. 3
The Changing Nature of Software Languages	p. 4
Graphical versus Textual Languages	p. 5
Multiple Syntaxes	p. 6
The Complexity Crisis	p. 7
What We Can Learn From	p. 8
Natural-Language Studies	p. 9
Traditional Language Theory	p. 10
Graph Theory	p. 10
Summary	p. 12
Roles in Language Engineering	p. 15
Different Processes, Different Actors	p. 15
The Language User	p. 16
Tool Set of the Language User	p. 17
The Language Engineer	p. 19
Tool Set for the Language Engineer	p. 19
Tool Generators	p. 20
Summary	p. 21
Languages and Mograms	p. 23
What Is a Language?	p. 23
Mogram, or Linguistic Utterance	p. 24
Primitive Language Elements and Libraries	p. 26
Abstraction Levels and Expressiveness	p. 27
Abstract versus Incomplete	p. 29
Raising the Level of Abstraction	p. 29
Growing Business Expectations	p. 31
Languages and Abstraction Levels	p. 32
Domain-Specific Languages	p. 33
Domain-Specific versus General Languages	p. 33
Domain Experts versus Computer Experts	p. 33
Large User Group versus Small User Group	p. 34
Horizontal DSLs versus Vertical DSLs	p. 34
DSLs versus Frameworks and APIsp37
DSLs as Software Languages	p. 37
Summary	p. 38
Elements of a Language Specification	p. 39
Language Specification	p. 39
Forms of a Mogra	p. 40
Parts	p. 41
Creation Process	p. 42
An Example	p. 43
Formalisms to Specify Languages	p. 47
Context-Free Grammars	p. 47
Attributed Grammars	p. 49
Graph Grammars	p. 51
UML Profiling	p. 52
Metamodeling	p. 53
Formalism of Choice	p. 53
Summary 54 Cha
Table of Contents provided by Publisher. All Rights Reserved.

Excerpts

Preface PrefaceThis 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 ThesisAs 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,