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?