omain-specific languages (DSLs) and model-driven development (MDD) offer developers powerful new ways to improve productivity, enhance quality, and insulate systems from rapid technological change. The Eclipse Modeling Project allows developers to create DSLs and use MDD techniques with the open source Eclipse platform. In the book Eclipse Modeling Project: A Domain-Specific Language (DSL) Toolkit
, Richard C. Gronback illuminates both the principles and techniques software professionals need to master.
In Chapter 3, "Developing a DSL Abstract Syntax," Gronbackan Eclipse Modeling Project co-leaderwalks through the development of a DSL using the Eclipse Modeling Framework (EMF) and supporting components. This article is an excerpt of Chapter 3.
Editor's Note: This chapter is an excerpt from the book, Eclipse Modeling Project: A Domain-Specific Language Toolkit, authored by Richard Gronback, published by Addison-Wesley Professional as part of the eclipse series: www.informit.com/series/eclipse, Copyright 2009 Pearson Education, Inc. ISBN 0321534077, published March 2009. Safari Books Online subscribers can access the book here: http://safari.informit.com/.
Chapter 3: Developing a DSL Abstract Syntax
In this chapter, we walk through the development of a domain-specific language (DSL) using the Eclipse Modeling Framework (EMF) and supporting components. Specifically, we develop the DSL's abstract syntax using the Ecore metamodel. But first we cover some basics on what to consider when creating a DSL and the different implementation strategies you might want to employ when using EMF. Next, we provide an overview of EMF, leaving detailed information to the book  dedicated to this purpose. We cover some additional components of EMF and Model Development Tools (MDT) that enable you to further refine DSLs, and we develop a series of domain models for use in the sample projects.
|Disclaimer: The domain models developed as samples are constructed to illustrate certain features of the associated tooling and, as such, should not necessarily be considered "best practices" in some cases.|
3.1 DSL Considerations
Many considerations are involved in creating a DSL. Does a model already exist that is close enough? If so, can an existing model be extended, or is it fixed? Does the model need to be based on a standard? Does the DSL lend itself to graphical display and editing? Does the DSL require a textual syntax and editor? Will a product line be built on the DSL, and perhaps others? Is the Ecore metamodel expressive enough to suit your needs for a DSL? How can you model dynamic behavior?
|Best Practice: Leverage existing models, when appropriate. XML Schema Definition (XSD) and EMF are very popular technologies, and EMF can import just about any XSD, so search for existing domain models before you reinvent the wheel. Also consider publishing your domain model if you think that others might find it useful, if only as part of your application's API to aid in integration.|
A key consideration is the amount of flexibility you need or will tolerate in the DSL. As you can see in the examples, sometimes a change in the domain model makes your transformation definitions much easier to write. Also, frameworks such as GMF have certain limitationsor, rather, were designed with particular use cases in mind. Your particular style of modeling might not lend itself well to graphical representation, but a few changes might allow mapping to diagram elements much easier. For example, certain mappings in Query/View/ Transformation (QVT) and template expressions can be facilitated by adding derived features or methods to the domain model. Complex queries using Object Constraint Language (OCL) (and, therefore, useful ones in QVT and Xtend) can be added to the domain model with code generated for their implementation at runtime. Having a feature available in the model will greatly simplify transformations and templates that access them.
|Tip: Don't be afraid of modifying your domain model to make working with templates, transformations, and diagram definitions easier. Unless you're using a model that cannot be altered, the Toolsmith will appreciate being able to make certain design decisions in the domain model to suit the tooling, instead of having to create workarounds or write custom code to use the tooling with a domain model.|
This is not to say that you should let the tooling influence your DSL to an extent you are not comfortable with. The question is, how do you maintain a satisfactory level of "purity" in your DSL when considering the additional complexity associated with developing and maintaining the other Model-Driven Software Development (MDSD) artifacts? In general, the more complex the metamodel (DSL) is, the more complex the transformation definitions, templates, and diagram definitions are.
A set of conventions and best practices for the definition of DSLs, transformations, and templates likely will arise, as it has for Java and other popular programming languages. With conventions and best practices comes tooling to support refactorings, static analysis, and cleanup. At this stage of the Modeling project's evolution, operations are still quite manual and even error prone. As an open source project that forms the basis for commercial products, Eclipse eventually will see more advanced features pushed down into it, thereby improving the Toolsmith experience.