Eating the world through DSML

I borrowed this blog entry title from an interesting post in the January 2016 Eclipse Newsletter titled “How to Eat the World with DSLs.”

In that article, the author makes many good point about DSL, such as creating a language with which the users are already familiar and abstracting the more complex aspects of coding (a payroll system implemented in Excel sheet in this case) to facilitate the domain expert’s job.

The same approach can be used when dealing with the complexity of modeling. UML is known to be rather complex, but a using a DSML to represent your domain will simplify the work of your developers. Ericsson presented a good example of this at EclipseCon Europe 2014: “UML or DSML? You can now have both with Papyrus 1.0!

An advantage of using a UML-based DSML, at least in the Systems Domain, is that existing analysis tools can be used on the underlying UML model to do common functions, e.g. traceability. Using UML as the base for your DSML also allows you reuse parts of the UML that would make sense in your domain (e.g., sequence diagrams are already available for free). For other aspects, such as collaborative modeling, you would still need to do some toolsmith work to be able to present the results in the context of your DSML instead of UML. Domain experts should not have to understand the underlying implementation and must be kept at their level of abstraction!

The capability to author DSMLs is already available within Papyrus and will continue to evolve and improve as part of the newly created Papyrus Industry Consortium.

And even if you do not feel like you need to base your DSML on UML, there are other Eclipse offerings, such as Xtext (mentioned in the article referenced above, textual DSL) and Eclipse Sirius (graphical DSML based on its own metamodel).

Within Eclipse PapyrusRT, we already use Papyrus’ DSML capabilities to implement the graphical UML-RT modeling language. We are now investigating combining this with an Xtext-based representation of UML-RT to blur the line between graphics and text. Our take is that you should not limit yourselves to only textual or graphical representation – some things are easier in one or the other and, sometimes, a mix of both can be better!

With a good infrastructure to support it, DSMLs are the modeling approach of the future and is available now. You should take a closer look!


Jordi Cabot has an interesting Blog on Modeling Languages. In it (an on LinkedIn) there was a discussion recently on the difference or similitudes between MDA, MDD, and MDE. It’s interesting that Wikipedia treats the last two as the same thing – I like Jordi’s description better.

However, as I read Jordi’s blog posting, I found that his explanation certainly makes sense and is probably correct nowadays, in a more modern sense of the terms.

However, “MDD” has been used for quite a long time to describe model-based (as opposed to model-driven) development. That use of the term would not fit within the definitions presented by OMG as part of MDA (e.g., the CIM/PIM/PSM levels of abstractions and transformations). I suspect that this approach may also still be in use today – although probably not the best way of working with models. This may especially be true of some of the model uses seen in “agile” approaches.

So perhaps there is a need, in the diagram shown on that blog, to also have a model-based development (MBD?) circle that would intersect with MDD, but not the others?

All this also can not be discussed without mentioning the standards, processes, and methods (and the effect of tools on these) surrounding these approaches. Models need to have a standard representation to be useful – and the UML (and SysML) is certainly one that is common these days. However, other notations such as BPMN, ERD, etc., should not be discounted as they represent interesting domain specific modeling languages – and not all can be easily expressed using UML . Tools are too often viewed as a panacea to what ails software development – when they can be a hindrance when one does not understand the standards, processes, and methods they support.