Excellent show. One comment:

It is actually easy to handle the kind of “emergency stop” cases you talk about in DSL defined state machines. Simply use a hierarchical state machine and the “emergency stop” case can be handled by drawing a single transition.

For example, we are using an internal Ruby DSL to generate our state machines and can do your example like this:

state :BootState
if_true :Emergency => :EmergencyState
state :NormalState
end
state :OtherState
end
...
state :EmergencyState
end
end


yes, I am of couse aware of composite states, but I wanted to illustrate the use of model transformations in general. Also, depending on the meta model you have to work with, you might not have the ability to use comoposite states; I know a couple of systems where people did not include composite states in their meta model “to keep it simple”.

But I guess I should have made this explicit in the podcast.

Thanks for your feedback!
Markus

Your question on what are the places for using M2M is still valid. In my opinion often people are looking for M2M simply because the tools in use have limited functionality, e.g. need to combine data from several individual files.

For example, a DSL that generate UML models would then be a “model transformation”?

Cheers
Morten

Of couse, you can code-generate the serialization format of a model – hence you can emulate a M2M via a code generator.

But real M2M, with a suitable language, is more productive.

Having said that, assuming most tools can import and export XML, it would be fairly easy to load XML files into a dynamic language (say Ruby) and generate internal objects for direct manipulation and transformation. Then you would get the benefit of working with objects while staying in a general purpose language. No need to learn a separate M2M language.

Morten

If you are writing a DSL in a general purpose language without using text templates, you already have the full power of a general purpose language to do optimizations, transformations etc. There would be no point in adding a M2M step.

But I can see that a M2M step would be needed if you are using a text template based tool. Text based templates limits what your generator can do.

Morten

Your question on cost efficiency is highly relevant and we wrote whole chapter on economics side in our book on DSM (http://dsmbook.com/toc.html). The cost efficiency depends usually on the repetition: how many developers, number of products/product versions or customization projects will be there? Sometimes another view to cost efficiency is looking the value of domain experts being able to make the ”development” work. Both of these kinds of things can be usually estimated and calculated well enough to make a decision.

Based on our experience, language definition (metamodel, notation, editors) takes almost always less time than making the generator/transformation. So if you have an existing metamodel (I can’t say UML to be proven metamodel you may need several transformations and finally still need to develop the generator. Making M2M based on universal metamodels is usually also costly since the source model contains errors and is incomplete and those need to be checked in relation to M2M. Otherwise we are transforming models with errors. By placing these rules directly to the language (DSL rather than universal/general-purpose) we can prevent errors to happen already early on and guide developers on making the specifications.

One part of the cost-efficiency is tools used to create languages, transformations and generators. Few years ago at OOP conference a German tool developer company told that it took 25 man-years to develop UML tool with Eclipse EMF. Obviously, that kind of figure does not make the creation of modeling editors cost effective for most organizations. But what if you could develop the same kind of UML tooling in one man-month? So tools used may make the calculation of cost-efficiency to look quite different.

Still, I wonder what is the problem M2M aims to solve? In the podcast we agreed on at least one: there is already a generator and we transform models to the structure/format it expects. A generalization of this is the need to integrate tools (usually one direction only) based on different metamodels.