Posts from January 2010.

Searching for the essential building bricks of MDD

Red Brick Wall. Photo by Cibergabi via

A title like this could sound utopian and probably it is in the extreme, but at the same time provides two advantages:

  1. a suggestive title brings more blogs readers :), and
  2. these kind of Quests keep me active developing and testing my ideas about MDD.

Sorry for 1, the joke. But Let me explain 2 a little further if you are interested:

Some months ago, I started to develop a new tool for doing Model Driven Development. I always start new developments with contained expectatives. I consider most of them throw away propotypes just to test a new way of doing the same thing, but luckily, with less effort and better productivity. But when you found the way, you follow it again whenever you need it, isn’t it?

So, this time is one of those moments: I am quite happy with the results, and I will continue building on the top of it to make it grow.

Today (almost?) everyone agrees on code generation can make your life notably easier as long as you have:

  1. a stable domain,
  2. a clear knowledge of your domain (domain expert) and,
  3. tools: modelling editors, model checkers, and code generator adapted to your domain and your chosen target architecture and language.

The trickiest one to get is, not surprisingly, the third one. And this issue: the quality and the applicability of the MDD tools is the main stopper when considering applying MDD for a software development project.

So, my motivation during years is not only to create code generators one more time, but do it in a way that it will be cheaper to obtain results in next projects. Therefore, reducing the requirements for the entry level will help the MDD adoption to gain speed.

Ok, wait a minute, are you reinventing the wheel again? Building another meta-code-generator?

Yes I know, there are very good and mature tools for doing MDD: such as EMF/GMF, XText, ATL, TextUml, Metacase, MS DSL Tools, etc.

However, guided by my intuition and the experiences in the domains I have worked in, I have a strong opinion on of how some things should be done and for the moment I didn’t found the perfect tool to satisfy my needs.

But, instead of complain, I decided to take to the action and add my two cents implementing my view about MDD tool support: taking the good ideas of the standards available and reinventing the parts that don’t fit.

The tool

After this introduction, the name of the tool is not going to surprise you. It is named Essential.

The goals of the project are following ones:

  • to declaratively describe metamodels, models, templates, and transformations using textual DSLs
  • to provide a comfortable editor for each of these four pillars,
  • to provide model checkers to assure the integrity of the four, and
  • to build code generators and transformation interpreters to achieve the output we are looking for.

In the next posts I will depict the DSLs used in Essential and some architectural choices. This will help us to discuss the essence of the problems found in MDD.

I want to thanks Javier Hernandez for his constant help, good discussions and counterpoints about choosing design alternatives for Essential. And also to Nicolas Cornaglia and Ángel Marín for their active beta testing as early adopters and providing good test fields.