Juha-Pekka on DSM

Learning by doing is perhaps one of the most effective ways to discover and master new practical skills. This year at Code Generation 2009 we are running a hands-on session in which participants implement from the scratch a domain-specific modeling language. Our plan is to do language creation iteratively: Develop several versions of the DSL and after using the language we are better equipped to improve the language further. When we finalize, we will see how the DSL became better (powerful, simpler to use, easier to learn).

The session shows repeatable steps to invent and implement your own modeling language. Participants will use MetaEdit+ (no previous experience required) helping in the process of trying out the ideas and iteratively defining the DSL. MetaEdit+ also provides tooling for the language users with features you expect from modern environments. You can register for the session at Code Generation website.

Leipzig IT Radar interviewed me earlier this year on Domain-Specific Modeling. While IT Radar focuses on management topics we discussed mostly the organizational side: who defines domain-specific languages, how the introduction should be started, what changes in the development process, where DSLs make most sense and what are the experiences from the industry.

Although I’ve lived in Germany and learned the basics of German language (to eat/drink/sleep/shop etc.) the podcast is in English. Perhaps some day I can manage computer topics as well...

I received last weekend the confirmation that the workshop on Domain-Specific Modeling will be organized as a part of OOPSLA conference between 25 and 29th October. The location is a bit special this year since the event will be held at Walt Disney World Resort in Florida, Orlando. I’m expecting to see many domain-specific languages applied in the entertainment domain :-)

This was actually a poor joke as languages fitting to the task help focusing on creative parts and leave routine to the computers, aka editors and generators. A nice example of this is how Risto Pohjonen from MetaCase, has created a DSM solution to help designing menu structures and communicating authoring plans for DVDs. The results have been acceptable - at least I consider two DVDs charting #1 (A,B )and a gold disc as good results.

CfP for the 9th DSM workshop is available at the workshop website.

InfoQ has published the recording from the OOPSLA panel "Domain-Specific Languages: The good, the bad, and the ugly". They did particularly nicely the video as included there also the questions from the audience - often the best part of the panels. The video is available here.

A quite common belief is that it takes a lot of time and effort to define modeling languages and code generators along with supporting tooling. Usually people expect that it will be a project where the effort is counted in man-years. Based on our experience this is not the case at all as we have seen companies to implement DSLs and code generators in days - depending on the domain of course - as illustrated with few cases below:

These figures may look surprising - especially if having invested much more time and effort on DSL and tool development. Last month, SYTYKE, a Finnish association on software development, was running seminars on DSM with talks from several companies having defined domain-specific modeling languages and generators. A commonly asked question from the audience was: “how much effort went to implement your domain-specific language and generators along with tool support”. Some answers from the companies were:

• Ouman: 5 days for modeling and code generation support
• Sandvik: 2 days for modeling support
• VTT: several cases with modeling support and generators: few days to 2 weeks

In my opinion these are good, but typical figures. I also know these cases as they used MetaEdit+ for both language and generator definition and for their use. What could then explain the gap between the expected effort and the actual effort? I would like to point out three reasons:

• The expectations are false simply because not based on any real experience, and perhaps made even without ever having defined languages and generators. The above cases clearly indicate that those having created DSM solutions do not report about man-year, or even man-month, projects. Needless to say, but I tend to believe more those having done it.
• Being able to narrow down the problem domain where modeling and code generators are applied. If we target too broad or low level of abstraction we end up implementing a general-purpose language - and that naturally takes a lot of time. Also if we don’t know what we are developing it is pretty hard to bring automation in - so we never can start to apply the DSL in a real project.
• Wrong tooling is used requiring extensive use of resources for developing the language, generator and modeling tool support. The horror story I heard at OOP conference was a talk reporting having used 25 man-years to define modeling languages and tools with Eclipse EMF. I don’t think there are many companies who can make such an investment. One easy to read and understand example on tool differences was reported at OOPSLA workshop on best practices for MDSD (Model-Driven Software Development).

Code Generation conference, #1 in my scale on modeling and code generation topics, has published the program for 2009 conference. There is again a lot of content covering cases, experiences, working practices and tooling. What I in particularly like is that so many sessions allow everybody to join and contribute, like Goldfish Bowl, Hands-on and BoF sessions.

From the program I would like to highlight two sessions that I found particularly interesting: The first is the two keynotes by Steven Kelly and Markus Völter on Model-Driven Development as the speakers can provide experiences from multiple cases, languages and tools. Check the titles as they promise something really interesting and I'll bet fun too. Another session that I’m looking is the Think Tank by Grady Campbell discussing tooling support for Domain-Specific Engineering. He focuses on product lines and I’m eager to see how he contrasts variability-based product generation with model-based generation - and how it is different from mine.

You may register with the early bird offer before 31st March.

Thomas Kühne is editing a special issue for SoSyM (the Journal on Software and Systems Modeling) on metamodeling. Thomas contacted me asking when the first tools were developed that actually used metamodels to define languages (rather than grammars).

I thought the tool history - as far as I know about it - would interest others too so decided to reply in my blog too. Please note that the metamodel based tools have (had) different names, such as language workbench, DSL tool, metaCASE tool, CAME tools (Computer Aided Method Engineering), CASE shells (notice the analogy to AI expert system shell) and metasystems.

To my knowledge ISDOS project (Information System Design and Optimization System) at the university of Michigan reported first about the metamodel-structure in a tool at the 70's, namely D. Teichrow and E. Hershey:PSL/PSA: a computer aided technique for structured documentation and analysis of information processing systems, IEEE Trans. on SE , 3(1), (1977), pp.41-48. They focused on developing languages suitable for tools and focused on requirements engineering side. Luckily the project and its results have started to appear in Internet.

Another tool that deserves a special notice is QuickSpec. It used an explicit (meta)metamodel, called OPRR, created to overcome the problems of binary and relational models. There is a very good paper that discusses this topic at DSMForum - with a little explanation of how some of the terms used then differ from those that the industry is using now. The paper is quite topical again as people are looking repository support for models (and metamodels) instead of having them in separate files.

The first graphical metamodeling tool was MetaEdit (not the current product which is MetaEdit+) and it used OPRR to specify languages for other metamodel-based tools, like to Swedish Ramatica and naturally for itself too. Reference is Smolander, K., Tahvanainen, V.-P., Lyytinen, K., Marttiin, P., (1991) MetaEdit - a flexible graphical environment for methodology modeling. In: Advanced Information Systems Engineering (eds. R. Andersen, J. Bubenko, A. Sølvberg), Berlin, Germany, Springer-Verlag, pp. 168-193.

It’s architecture was quite similar to what most metamodeling tools have today, but it showed us how badly that architecture supports DSL design and use. For example, as models and metamodels where stored to individual files - and there was separate tools running for language design and for language use - things got complicated for anything real: In a small project at the university diff, merge, grep helped to keep things going but obviously that approach would not scale to anything bigger. Also after the metamodel changed it could be that the models already made would not necessarily open anymore... aaaargh. Well, that was 18 years ago. We naturally changed the architecture so that in MetaEdit+ models update automatically if the metamodel changes and naturally models always open.

The SoSyM issue on metamodeling should appear July 2009.