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).
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 DiscussionThanks 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.
Johan,
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).
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.
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.
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?
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 ?
Henry,
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).
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.
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.
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
[…] a response to this the Model-Driven Development (MDD) community shifted focus to smaller, more specific languages (or should I say the community came […]