Raise your level of abstraction

Which workbench?

The web, Twitter, newsletters, 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!!!

Tags: code, development, domain, driven, engineering, generation, language, languages, model, modeling, More…software, specific, workbenches

Add a Comment

You need to be a member of The Model Driven Software Network to add comments!

Join The Model Driven Software Network

Comment by Andreas Leue on April 27, 2011 at 12:06: Oh, really? I'd love to contribute a use case. I send you an email!

Comment by Angelo Hulshout on April 27, 2011 at 11:52: >> ...Well, we're seeking such a solution, not offering.

That is what I meant: most presenters are offering, so they should appreciate some challenging by a 'seeker'.

Comment by Andreas Leue on April 27, 2011 at 11:32: > ...participate and challenge our presenters with this?

Well, we're seeking such a solution, not offering.

We focus on "creating fully model driven applications". Of course there's an overlap to language workbenches (M2M, Code Generator), but with respect to the the "final frontend" (textual & graphical editors) we rely (and would like to rely much more) on third party offerings.

Our underlying interface technology to bind to such tools is based on "Object Construction Plans" (OCP), which provide flexibility, maintainability, extensibility, modularity etc. etc., but IDE integration, syntax coloring, a graphical editor and such stuff is what we are actually looking for.

Comment by Angelo Hulshout on April 27, 2011 at 8:54: Hello Andreas,

I like your requirements, and largely agree to them.

Your statement regarding usability vs. maintainability is a very good one.

"either your solution is easy to maintain, but unacceptable to the end user, or it is easily usable, but a maintenance mess (tool dependent, release dependent, proprietary, costly). This is not a choice."

I agree that we need to balance these two, and ideally come up with a win-win, not a compromise. An interesting question would be whether any of the tools presented in the workshop comes close to that win-win, and meets your requirements. Maybe you can participate and challenge our presenters with this?

Comment by Andreas Leue on April 27, 2011 at 8:31: Hi Angelo,

> ...whether the ideal workbench ... exists...

actually, I think the named requirements are conservative, not exaggerated. If we want to do more than just "add a little mdx" to traditional coding, they become a minimal must.

A simple, surely not uncommon example: augment a standard language (UML, BPMN, ...) with some extensions, in a standardized way. Yes, UML in theory provides four types of extensibility, so it seams you have a choice. Yet the choice basically is: either your solution is easy to maintain, but unacceptable to the end user, or it is easily usable, but a maintenance mess (tool dependent, release dependent, proprietary, costly). This is not a choice.

Here's my list of requirements:

- describe a nontrivial language extension in a standard language which exists in only one variant (I don't want to change it on each upgrade of the tools, and the customer typically prefers another toolprovider than the one we support already)
- describe only what is necessary, describe it only once, describe it comprehensible (keep costs low)
- put this description into any of many versions of the underlying standard tool(s) (the customer always has a different version of that same tool already in use)
- do it in a blackbox fashion, i.e. just copy your spec to a certain place e.g., or provide it as an installable plugin (otherwise noone is willing to do it repeatedly)
- do nothing but that
- you get: a textual editor, or a graphical editor, whichever you prefer (tastes differ)

Is this science fiction? Or is it the bare minimum required for a working MDx toolchain?

Comment by Angelo Hulshout on April 26, 2011 at 21:57: That is exactly the point, Rui: there are many workbenches out there, the 'competition' is not a competition in the sense that we are looking for a single winner - we want to give people the opportunity to learn what aspects to look at, and based on that, which tool to pick for their problem and environment.

Comment by Rui Curado on April 26, 2011 at 21:38: "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?"

Everyone has its own view of the subject. The result is of course may similar, but different tools. There will be no such thing as "the right workbench", but perhaps a "winner": the one whose vision is shared by most people. Put ease of use and power in that choice too.

Language workbenches will be like cars, phones, software: many choices, several pieces of the "market" share pie.

Which workbench?

You need to be a member of The Model Driven Software Network to add comments!

Badge