A metaphor for Model Driven Engineering

A couple of weeks ago I wrote an article introducing a framework for Model-Driven SOA. This article doesn’t stand on its own, it’s based on earlier pieces on Model-Driven SOA and observations that Model-Driven Engineering should focus on the problem domain. However, I’m noticing that these articles can be hard to grasp if you have no background knowledge. That’s why I want to explain Model-Driven Engineering using a simple metaphor I often use in my presentations.

Figure 1 shows the metaphor which compares building a house with building software. ‘Traditional’ programming can be compared with building a house manually. Someone studies the design and instructs people how to build the house (the upper half of the picture).

a metaphor for Model Driven Engineering

Figure 1 – A metaphor for Model Driven Engineering (MDE)


Model Driven Engineering (MDE) can be compared with the lower half of the picture. Based on some ideas on paper a model of a house is constructed. Once the model is complete it is put in a generator, et voila, the end result can be generated automatically.

When a Model Driven Engineering approach is used for developing software the main effort moves from programming to modeling. Based on functional requirements a model has to be developed. This model can be automatically converted into working software with a tool generating code from the model or by interpreting the model with a runtime environment (a.k.a. engine, virtual machine).

Based on this simple metaphor we can create an overview of the elements of Model Driven Engineering. We need:

  • an executable model. This can be accomplished by using Domain-Specific Languages (DSL) to specify the model. DSLs can vary in structure and in most cases we need more than one DSL to keep them small and specific.
  • a methodology to come from functional requirements, documentation, or something like that to the model. A first step into the direction of a methodology is this description of a framework for Model-Driven SOA.
  • tools to define the DSLs and to specify the model. We also need tools to ensure the quality of the model.
  • a generator or interpreter for making the model executable.
  • an architecture describing the type of applications delivered by the model driven approach. There is quite a difference between a house and a software application, but also within software there are lots of differences.

What is your favorite metaphor for explaining Model Driven Engineering?

11 Comments Added

Join Discussion
  1. Giovanni Tirloni August 9, 2009 | Reply

    Thanks for the post. At work we are seeing more and more the adoption of modeling tools which makes me optimistic. The developers seem like that too.

  2. Luis Bender August 14, 2009 | Reply

    I see programming and modelling both as the “planning activity” of the “building a house” process. They just use different representations for the blueprint: programming uses source code and modelling uses models.
    After programming or modelling, you get the house automatically in both ways, too. You may execute the source code (compile & execute or interpret it as you like) or execute the model (interpreting or generating code & compiling).

  3. Johan den Haan August 15, 2009 | Reply

    Hi Luis,
    That’s another way of looking at the metaphor. I agree with you that source code is a model too, albeit a lower level one.
    However, to explain MDE I still like my own version of the metaphor because it shows the difference between the level of abstraction and the level of automation.

  4. marchal claude August 15, 2009 | Reply

    Hi Johan
    You are an evangelist of DSL which is according to me not strictly necessary for MDE, SOA context or not. I tell you that because your metaphor is more widely applicable.
    There is a small communication issue with your metaphor and mine: it seems that MDE can’t be used for first_of_a_kind project; what is false. But a topic on its own.
    I like the previous comment because I shoot me dead by telling again and again to my developers that planning is designing.

  5. Johan den Haan August 15, 2009 | Reply

    Hi Marchal,
    > You are an evangelist of DSL which is according to me not strictly necessary for MDE, SOA context or not.
    I agree with you, it’s not necessary. The reason I like DSLs is because they can make the life of people who have to use the model-driven approach a lot easier.
    > There is a small communication issue with your metaphor and mine
    Can you explain what your metaphor is?

  6. henry August 24, 2009 | Reply

    I do with car industry and automotive in general
    they do models from years
    car are built by robots using models
    they have DSLs: car element templates, existing mechanical elements to use, mechanical constraints of components
    99% of the car are robot created from model, yet they have options for customisation (color, engine …)
    Manually built cars exist: ferrari for instance … for rich people only
    My robot built car is safer and more reliable from a maintenance standpoint: i do not need to do adjustement every month, i wont crash at speed 300 km/h because i am no formula 1 driver
    Nobody thinks that a robot do a worse job than a real people !!!!!!
    Productivity increase it there
    Decrease of car price is there
    Car are always more reliable because of that process
    Isn’t it what we are looking for ?

  7. Phil Runciman October 7, 2009 | Reply

    I love your example. However, I love it because there are suitable controls for the driver in a car.
    If I am using MDE to develop an ERP then the trick is to appreciate which processes are fully automated and which ones require some controls. MDE does not generate the driver too! Over time more and more processes move into the MDE domain as new DSLs emerge (e.g. for planning,and scheduling?). Consider steering the car along motorways equipped for automatic steering and speed control. (No more big pile ups in fog).

  8. henry October 8, 2009 | Reply

    Hi Phil, the driver is a must.
    The day the IT car goes on the road without driver is a day it is better stay home !!!!!
    Generating models is a factory, however you make good stuff out of good materials with a good recipe.
    But garbage in is … garbage out. Generation software does not solve from bad design, bad habit at operations and does not protect from bad processes.
    However it is possible to generate 100% percent of applications has I just proved at 4th MDA/EA forum.

  9. Phil Runciman October 8, 2009 | Reply

    Hi Henry,
    I totally agree with you.
    The embedded software folks have shown the way. Now we are developing better understanding of the human interaction processes we will develop even more advanced software using MDE and MDA/EA technologies.
    I have been waiting since 1982ish for these tools. Back then it was Texas Instruments’ IEF that generated whole green screen systems. It was a shame that PCs came along and ruined the party. Of course the ‘Net technologies have raised the bar again.
    We live in exciting times.
    OlivaNova also reaches 100% application for business information systems including the GUI.

  10. lowcoupling August 17, 2013 | Reply

    A very interesting post, thank you. I do hope you will find http://lowcoupling.com/dslengineering, and http://www.lowcoupling.com in general, the same interesting! I will follow your blog

  11. Pingback:

    […] a response to this the Model-Driven Development (MDD) community shifted focus to smaller, more specific languages (or should I say the community came […]

Leave a Reply