These days, I’m about to prepare a presentation on a project we concluded recently. In that project, we validated a prototype implementation of some graphical editors for a more or less domain specific modeling language. While thinking about some possible introductory slides, I remembered a similar presentation not too long ago, where I tried to present the benefits of using domain specific modeling languages.

I well remember the looks of doubt on most of the audience faces, with comments along the lines of “Now we spent years of coming up with a standard like UML and you tell us DSLs are better.” Well, the thing with UML in my opinion is that it has grown into a rather bloated standard which tries to address all possible modeling domains. Add to that the ongoing debate whether it’s better to use profiling or metamodeling to customize it. And on top of it, at OMG, tool-vendors typically try to standardize what they have already implemented. I’m not saying UML is a bad thing, it’s just that this evolution has created an opposite trend.

What I also recall are the days back in the 90s, when CASE was the silver bullet for all kinds of software problems and where we had a plethora of methods and notations. Obviously, at that time, standardization was the only solution to get out of that universe of notational solar systems which were floating around in virtual space. The time has come, though where that standardization effort has developed a momentum of its own, which in a lot of cases is more and more disconnected from end-users. An electrical engineer which needs to collaborate with a software engineer will simply not want to learn UML – which is really just some fancy software thing.

Enter DSLs. On the presentation layer, DSLs most importantly attempt to pick up the user (who is typically an expert in his domain) by using a visualization (aka notation) and a terminology she’s used to. On the storage, and more importantly the interchange layer, the data which is collected and modeled by the expert is however mapped to a metamodel which is ideally common to many different DSLs. Although this common mapping is far from being in use everywhere and is certainly very challenging to design in the beginning, from an overall perspective, such a common metamodel is the big step forward. This is where DSLs have learned from UML and its standardization based on MOF and this is where DSLs significantly differ from the notation universe from the 90s – provided the DSLs are built on a common foundation.

That common foundation is also a technical aspect and in this area, we find another reason why nowadays DSLs can reach a higher level of maturity. With frameworks such as EMF and GMF which in turn build on a proven platform like Eclipse, the technical challenges of creating DSL tools become much more manageable. So much, that these tools are more often built by end-users themselves and less and less by typical tool-vendors. As a result, what used to be proprietary know-how of tool vendors some years ago, now shifts more and more to end-users.

The challenge for tool vendors and consultants in this evolving eco-system is now to focus more on the back-end frameworks and be less dogmatic on how modeling has to be properly done. But that’s a topic for another article …