MDSD and DSLs

I'm regularly reading Martin Fowler's blog and am especially interested in his writings about DSLs. I usually tend to agree with and like what he says about that topic.
In his recent posts he started to talk about MDSD and how it's related to DSLs. As I'm somewhat involved in the MDSD community, I wanted to clarify what MDSD means to me.

Basically, MDSD is about
1) defining domain-specific abstraction (no matter how) and
2) make them executable (no matter how).

Defining abstractions

Sometimes the general-purpose programming language (GPL), e.g. Java or Ruby, can be used to define such abstractions (we call these abstractions APIs or internal DSLs). If the GPL is not flexible enough or we need static typing or better tooling, etc. we design an external DSL.

Most people think that developing an external DSL is complicated, because if it's a textual DSL you need to develop a parser, if it's graphical you need an editor, etc.. Therefore people customize/extend existing languages like XML or UML a lot.

However, nowadays it's not complicated to define an external DSL anymore. Frameworks like Xtext and the Eclipse Modeling Project in general offer a variety of tools and libraries to make the design of external DSLs easy and more important flexible, in terms that the DSL can grow and evolve over time. DSLs are a lively part of your project and therefore need to evolve like the rest of your software.

Make DSLs executable

"A difference is that most MDSD people assume that you'll want to generate code from that model rather than executing the model directly."

I don't assume code generation. Interpretation is of course a common option. Both approaches have their pros and cons. Generally speaking, one could say that code generation has strength when the DSL is of a structural nature (like a domain or component model), the target language is statically typed and you don't need to have dynamic execution of DSL expressions.
But it's also perfectly ok to generate code out of behavioural languages (such as statemachines) or interpret structural information like hibernate or spring do with their XML-based configuration DSLs.

Other misconceptions about MDSD

"In order to use model-oriented DSLs you need a different, RepositoryBasedCode, approach to tooling."

There are a lot of modeling tools using this approach. However we (Eclipse Modeling) use plain text files to store our models, because we think it's important to have all relevant information to build the software system in the same version control system. Also we want to reuse common, proven tools such as Diff and Merge.

"DSLs seem to have a proportionately higher emphasis in the MDSD world than they do in the mainstream programming world."

MDSD is not a holistic approach to develop software or a replacement to "mainstream programming", it's just the "how can I use external DSLs"-technique. And DSLs are just one useful thing among many others. MDSD emphasizes DSLs like AOP emphasizes Aspects.

"A particularly visible sub-community of MDSD is centered around ModelDrivenArchitecture (MDA). I'm not much of a fan of MDA in particular ..."

MDA indeed is a heavyweight thing which is based on overly complex standards and faces problems which are not relevant in most situations (like being platform independent). Also the suggestion of using UML and it's profile mechanism to define DSLs and layering code generators (make them target platform independent) with multiple model transformations is questionable.
To me MDSD has not much in common with MDA.

"Model Driven Software Development (MDSD) ... considers itself as an alternative to the traditional style of programming"

To me it's more like an extension. Again: MDSD is only about using DSLs, interpreters and code generators and integrate them in your project. To be a good software developer you need to have much more than this in your mental tool box.

"Most fans of MDSD base their enthusiasm on the basis that models are ipso facto a higher level abstraction than programming languages."

I also have met people (mostly with a CASE or MDA background) who haven't yet understood that models are just information like code is information and DSLs are just about specifying information in an abstract, concise, intentional and non-redundant manner. Models are code!
Sometimes those people even talk about "hand-written code" like it was something dirty. They argue that with models and code generation everything gets automated and forget that especially modeling in a graphical tool takes more time than writing the same information into a text document. IMHO such statements are one of the reasons why people like Martin think of MDSD being a holistic, tool-centric, heavy-weight approach (this is what I read between the lines).

MDSD Best Practices

InfoQ just published a new article written by Jan, Peter and me.
It's called "Best Practices for Model-Driven Software Development".

I hope you enjoy it!

Next Monday: Eclipse Stammtisch in Dortmund, Germany!

Just a short reminder for those who're interested in meeting up with Ralph and other Eclipse enthusiasts.
On next monday (June 23rd) an Eclipse Stammtisch is taking place at 7 p.m in the Strandbar SOLENDO (http://www.solendo.de) near Dortmund harbor (didn't know they even have water there ;-)). Anyway they have BEER!
Cheers!

Fowler's DSL example with Xtext

In his recent DSL related blog entries (ParseFear and Syntactic Noise), Martin Fowler mentioned a DSL example he's using in his upcoming DSL book. Here you can see how it is implemented using Antlr and a lot of Java.

This is how it can be done using Xtext and openArchitectureWare.
1) Download the oAW distro from itemis
2) Create a new Xtext Project
3) Paste the following Xtext grammar into the opened editor:

Statemachine :
  'events'
     (events+=Event)*
  'end'
  'commands'
     (commands+=Command)*
  'end'
  (states+=State)*;
 
Event :
  (resetting?='resetting')? name=ID code=ID;
 
Command :
  name=ID code=ID;
 
State :
  'state' name=ID
     ('actions' '{' (actions+=[Command])+ '}')?
     (transitions+=Transition)*
  'end';
 
Transition :
  event=[Event] '=>' state=[State];

4) start the generator (right click on generate.oaw Run->oaw workflow)
your're done.

You not only get an Antlr based parser but also get an EMF based AST (SemanticModel), and a fully fledged eclipse editor.

Of course it's up to you whether you want to interpret models or generate some code out of them. I choosed to write a small Xpand template file, generating a "controller".
Here it is.

Codegeneration 2008

Codegeneration 2008 is coming! And there'll be a lot of friends giving talks.
Peter and Frank are talking about model-driven Lego.
Markus will give two talks (Implementation Techniques for Domain-Specific Languages and Building Interpreters with EMF, Xtext and Scala).
I'll do two tutorials together with Arno:
One is called Concrete Syntaxes of DSLs and the other will give an Overview of Eclipse Modeling.
Finally on Friday, Karsten, Jan and me are holding a workshop about Using openArchitectureWare for M2M and M2T.
As this conference is specialized on code generation I'm looking forward to some interesting discussions. See you there!

Current Development at itemis Kiel

Just to give you a short update.
We've been working on a complete rework of Xtext for the last two weeks. While Jan and me have been developing the grammar language and witten the code generator, Peter and Dennis started to develop Xtext's new IDE framework.

Started with the new grammar language written in the new grammar language, we are now able to generate the parser, meta model and some other cool stuff from that description. Actually it took us some time to understand and manage the whole bootstrapping process. It 's never been so easy to shoot yourself in the foot... :-)

Currently we're working on a generic serialization mechanism. With this, one can modify instantiated models and write them back without loosing original layout information or comments.

Hopefully it won't be long until we can start reimplementing Xpand using the new framework (we yet have to add syntactic and semantic predicates to the grammar language in order to describe Xpand).

The current state can be checked out from eclipse's cvs : :pserver:anonymous@dev.eclipse.org:/cvsroot/modeling/org.eclipse.tmf/org.eclipse.xtext
Milestone planning can be found here : http://wiki.eclipse.org/Xtext_Project_Plan
Feedback or feature requests are of course welcome. Please use the developer mailing list for that : xtext-dev@eclipse.org

Game development with oAW

Last week Jens Wagener posted a small riddle in his blog. He stated that it is claimed that 98% of all people are incapable of solving it.
To put it short: I didn't solve it. (Thank God! I'm not that freaky ;-))

But hey, as we're currently testing our next release of openArchitectureWare, I thought I should give it a try and do something which helps solving it (our at least help to understand that it is really hard to solve ;-)) using oAW.

So first I wrote a DSL implemented in Xtext and then I specified the constraints outlined in the riddle using Check. (At this point you should have read Jens' post so you can understand what I'm talking about)

Using the DSL one writes the attributes (Color, Role, Pet, Language and Magazine) for the five houses down, one house per line. As I said the constraints outlined in the riddle are implemented using Check. So if there are any of theses constraints violated the editor provides the appropriate feedback.
The puzzle is solved when all markers have gone and there are no more wildcards 'X' in it.

This is a screenshot, of the "game" implemented in oAW:


So if you want to play around with it, just drop me a mail, and please don't come up with boring rule engine solutions ;-)