MDD = Model-Driven Drama

Introduction

There is new trend towards using models as a strong basis for software development. This approach is intended to become the next generation standard in the software industry. But it fails to undoubtedly prove its applicability and then be widely adopted. Why?

Code Generation is an Additional Means, Not a Target

MDD (Model-Driven Development) is a false good idea. It is intended to use code generation as an end, and not a means. The real end is a useful, stable and maintainable software. Code generation is just an additional way to achieve that end in addition to inheritance, polymorphism, generics, aspects and interpretation/introspection. All these solutions aim at one ultimate target: REUSE, avoid duplication of any piece of logic in the code.

Do we constrain ourselves to use generics or aspects in every class, every method even before having started coding? No!!! We should behave the same with code generation and keep in mind that code generation is the last option since we lose the compiler/editor instant validation or assistance and we increase the development environment complexity (generative build system, generated code manual change management, model maintenance/migration, ...).

Communication Models are not Coding Models

Models (graphical or textual) can be used to conceptualize, and communicate. They are indeed formal diagrams. Models can also be used to produce the source code in a generative way. They are then high-level programming languages. Inevitably, there will always be a big difference between these concept-oriented models and code-oriented models just because the goal is not the same. In the former case, we want the model to be communicative, thus simple and clear (less is more). In the latter case, we want the model to be complete, perfectly detailed so that its complexity reflects the logical complexity of the application. That is why the methodologies that prone that user requirements can be enforced using transformation and code generation (e.g. MDA: PIM -> PSM) are misleading.

Then, What To Do?

The problem is not code generation itself but rather the MDD (Model Driven Development) methodologies that tend to use anarchically models and code generation just because it sounds good. On the other hand, code generation is underused and too many of today's software are cluttered with duplicated pieces of logic that harden the development/maintenance and lead to continuously reinventing the wheel for each project (best practices, design patterns, ...).

Code generation should be used as a last resort for project parts as small as possible that need but cannot be factorized in a more traditional way.

How To do?

The correct way of handling MDD is to consider it as a tool/technology but not as a method. All the other well-known methods can use MDD by following these rules:

The DSL is nothing more than the formalization of differences between many similar bunches of code. Then always start by manual coding and then instead of copying/pasting a code, use the differences to create the DSL. Starting the DSL from scratch would be painful and sometimes without a real value added.
Prefer OO facilities to DSLs whenever it is possible.
Use the existing code to create the templates (code generation) or the engine (model interpretation).
Instead of continuously growing the DSL for very specific needs, allow to add hand-coded customized features (by specifying a class, a script, …).
Do not hesitate to create multiple DSLs for the same application as fewer as possible and then optimally reusable.

Now let's create a shell script DSL from the 2 following scripts by following the previous rules.

vsleep.sh

#! /bin/bash

usage ()
{
     echo "vsleep: sleep for some seconds by display a countdown timer"
     echo "usage: vsleep countdown
     echo "- countdown: the time to sleep in seconds"
}

if [ $# != 1 ]
then
    usage
    exit
fi

countdown=$1

while :
do
    echo "${countdown:-0}       
\c"
    if [ "$countdown" -gt 0 ]
    then countdown=`expr $countdown - 1`
    else exit 0
    fi
    sleep 1
done

timestamps.sh

#! /bin/ksh

usage ()
{
     echo "timestamps: periodically writes the current timestamp"
     echo "usage: timestamps interval
     echo "- interval: interval time in seconds"
}

if [ $# != 1 ]
then
    usage
    exit
fi

interval=$1

case "$interval" in
    [0-9][0-9]*)
	;;				# correct
    *)
	usage
	exit 1
esac

while true
do
    echo "--------------------------------(`date`)------"
    sleep $interval
done

By examining the 2 file differences, we infer the following structure:

And then the following DSL:

(DSL and template created with GenerateXY.)

Successful MDD

We all have used more or less often Model-Driven Factories maybe without noticing it:

JMX: model driven factory of management consoles that interprets code-based models
EAIs/ESBs (MuleESB, Tibco BusinessWorks, ...) that interpret XML-based models (designed graphically or not)
ETLs (Talend Open Studio, DataStage, Informatica, ...): The models are interpreted except for Talend Open Studio that generates the code and runs it.
CMS (joomla, wordpress, ...): They are indeed model driven factories that interpret DB-based models
... These are successful applications of MDD.

All these successful MDD factories are bound to recurrent applicative requirements (administration console, integration, ...) and NONE of these tools can be used alone to create a full application, only parts. These tools also allow to plug in manual code for advanced customization (Joomla components, Tibco BW Java methods, ...).

Conclusion

In the near future, DSLs will be systematically used in the software industry. As mentioned above, there are already a lot of DSLs that have been adopted. But definitely, models must not DRIVE a development, but rather be used as tools to simplify it.