The web, Twitter, news letters, advertisements and magazines continue to show a growing interest in Model Driven Development, and for model driven development tools that are often referred to as language workbenches. Apparently, this concept has found an audience amongst tool developers and software development organisations.

However, this attention has a downside - in the form of many different solutions, with varying functionality and qualiy, which makes the choice for the right workbench a non-trivial exercise. Maybe we should all build our own?

The challenge starts with the question what type of language one would like to develop: graphical, textual or maybe a mixture. In relation to that, do we aim for a home grown domain specific language, a standardized language like UML or SysML, or is it more efficient to create an extension to an existing programming language?

It doesn't end there - we also have to decide what to do with the models. Are they intended to become diagrams that support written documentation, or will we actually use them as a basis for code generation, the ultimate goal of a model driven development approach?

 

All these questions are dependent from the environment we work in, and the goals we want to achieve. This was one topic that was discussed heavily during Code Generation 2010, especially over lunch, diner and breakfast (in that order). As a result, a group of people, mainly members of the model driven network, including Markus Völter, Steven Kelly, Eelco Visser and Jos Warmer concluded that an objective comparison would be useful - focusing on key characteristics of language workbenches. Mid July 2010, a concept assignment for a so called Language Workbench Competition was drafted. Participants were requested to show a solution to a rather generic case, on three levels of complexity, what their language workbench of choice is capable of.

 

So, what should a language workbench adhere to? First of all, it must be possible to create structural languages, including support for correct usage, let's say a built-in grammar check. These languages should then be used to create models, from which code can be generated in a mainstream programming language.

Apart from that, and less basic, functionality is required to support project based development in average size teams. This implies the models will have to be allowed to become larger than your average 'Hello modelling world' example, and should be splittable into smaller, but consistently managed pieces. Team members should be able to work with these pieces independently, without losing model coherence.

Beyond that, it is useful to support multiple languages in a mixed environment, with as many or more code generators. After all, software systems have a mixed nature - data, behavior and maintenance all require different languages and thus code generators. This includes integration with existing programming languages, if not only then at least because of the fact that most model driven development projects start from an existing code base, which is considered an investment that should not be thrown away. Projects starting from scratch are almost as rare as tropical snakes on Antartica.

Finally, continuity in development plays an important role. This means that a workbench must natively support evolution of modelling languages and code generators, with or without the support of external configuration and life cycle management systems. Scalability plays another important role - just like the amount of code in a product will grow from release to release, models will do the same. This of course directly affects the need to allow teams teams to work on the same modeling base.

 

The only question remaining now is whether the ideal workbench, which supports all of the above, actually exists. I have my doubts, although there is hope for the future. What I do know is that the Language Workbench Competition acquired it's 12th participant this week, and that 10 of them will be presenting their solutions in a one day workshop on May 24th. This is the first in what I hope to be a series of Language Workbench Competiton workshops, and it will be held in conjunction with Code Generation 2011, in Cambridge.

Not a bad result for what started as a discussion over a barbecue lunch at Code Generation 2010. I can only hope that we will be discussing and preferably using the results. See you all on May 24th!!!