hide all comments


Domain-Specific Modeling: MDD that works

March 17, 2010 20:04:43 +0200 (EET)

Long time no blog. Aside from working on the next version of MetaEdit+ (about which more in a later post), I've been speaking at a variety of events. The first, back in November, was for the members of the International Association of Architects: a webcast on Domain-Specific Modeling: MDD that works. (The link will take you to the webcast, which was recorded live. Update: Added the codec and a Flash video alternative.) The format worked surprisingly well, even for the question and answer session: the participants could submit questions via the webcast chat tool, and Juha-Pekka picked a selection of them to ask me at the end. Something that was asked later was the size of the domain: with DSM, this is never something as broad as "embedded systems", or even "mobile phones". Normally it will be much narrower, e.g. a particular family or product line of mobile phones from a particular manufacturer, or then home and auto insurance policies in the EU. Making things no broader than necessary is one of the keys to high productivity with your DSM language, and also to making it easier to build the language: stick to what you are experts in, and follow YAGNI to avoid creating extra work for yourself.

One thing that struck me when preparing for the talk was that we often show graphs of how productivity increased in various DSM cases, but we don't normally have time to provide the details of each case. The cases studies are, however, available (see table below): some even with the modeling languages and generators publicly available. Most importantly, some of the cases obtained their productivity figures with scientifically rigorous experiments; not many companies have time for that, but those experiments serve to confirm the validity of engineers' estimates in other cases.

Productivity figures can seem a little abstract, so in the talk I looked at the in terms of something more concrete. Imagine that you can build one product in a certain time by coding. How much more can you build if you apply various kinds of modeling? In a previous post we already saw how with normal UML, you can actually build less than with manual coding. With MDA, the tool vendors' own figures range from 22% extra (Obeo: average cost reduction of an MDA project is 18% => 22% productivity increase) to 35% extra (OptimalJ: 30–40%). You can see from the red bars on MDA1 and MDA2 below just how little you get for your investment in tools and training — not to mention the long term nightmare of trying to maintain CIM, PIM, PSM and code in synch with only semi-automatic support. The productivity results for DSM tell a very different story: 5–10x faster, and completely automatic code generation.

But what is the cost of creating your own DSM language and generator? After all, the MDA tool vendors promise to provide those, so that's an extra cost for DSM. Here are the figures in person days for the cases above. I think they speak for themselves: 2–3 weeks by one person is so small it makes you cry. How many companies out there could spend 2–3 weeks to make themselves 5–10x faster?

Of course those figures demand good tools: all those cases are with MetaEdit+. Your mileage will definitely vary with other tools — and what's worse, because they make you do more work, your brain power will be directed away from creating the best possible language. At the end of the day, it's the size of the productivity improvement for the modelers that counts the most. If you can make 10 modelers 6x faster rather than 5x faster, that's worth 10 extra person years per year. With MetaEdit+, you're far more likely to get those extra person years, and you're sure to get your language ready faster. When we see the first case with GMF or DSL Tools making it into the 5 10x range, we can look at this topic again...

Referenced DSM Cases (for more see www.dsmforum.org)

Heart rate monitor Polar Kärnä et al., Evaluating the use of DSM in embedded UI application development, Procs of DSM’09 at OOPSLA, 2009.
Call processing services   Kelly, S., Tolvanen, J.-P., Chapter 5, Domain-Specific Modeling: Enabling Full Code Generation, Wiley, 2008.
[CPL project in MetaEdit+]
Touch screen UI applications Panasonic Safa, L., The Making Of User-Interface Designer: A Proprietary DSM Tool, Procs of DSM’07 at OOPSLA, 2007.
Home automation   Kelly, S., Tolvanen, J.-P., Chapter 5, Domain-Specific Modeling: Enabling Full Code Generation, Wiley, 2008.
[Home automation project in MetaEdit+]
Mobile phone applications Nokia MetaCase, Nokia case study, 2000
Phone switch features   Weiss, D. M., Lai, C. T. R., Software Product-line Engineering: A Family-Based Software Development Process, Addison Wesley Longman, 1999.
Financial web application Pecunet Kelly, S., Tolvanen, J.-P., Chapter 6, Domain-Specific Modeling: Enabling Full Code Generation, Wiley, 2008.
MetaCase, Pecunet case study, 2001.
IASA Architect Skills Library: Domain-Specific Modeling, 2007.
[Insurance project in MetaEdit+]


Barriers to Adoption

[Julius Campbell] March 19, 2010 03:53:14 +0200 (EET)

I saw the webinar you mentioned in this blog post.  Such a boost in productivity seems very attractive.  What in your opinion is keeping more people from adopting DSM with MetaEdit+ ?  What advice would you give someone who wants to introduce MetaEdit+ within their organization?



Re: Domain-Specific Modeling: MDD that works

[Steven Kelly] March 19, 2010 17:39:57 +0200 (EET)

Good question, Julius! First off, many people are adopting DSM with MetaEdit+. However, you're right in saying that many more could join in and get the same benefits. Normal resistance to change is of course one issue. We talk to many people who know this is the right way to go, but can't start just yet, because they have to get the current product out of the door. Or because they're just getting started on the next product. Or are right in the middle of a product.

My advice on how to effectively promote and deploy DSM within an organization is contained in a chapter of the DSM book. It's hard to summarize a chapter in a sentence, but maybe: small steps, proving the worth throughout.