Una discusión en LinkedIn sobre el alcance de MDD/MDA

Algunos días atrás se mencionó aquí una discusión en LinkedIn sobre MDD, que criticaba el valor del concepto. Algunos de los cuestionamientos no parecían estar adecuadamente orientados. Sin embargo, las respuestas generadas sí aportan elementos importantes sobre la relevancia del desarrollo basado en modelos, sea que se hable de modelos genéricos o modelos específicos de dominio. En términos generales, lo que sigue es lo más relevante de la conversación:

Cuestionamiento de la portabilidad de los modelos:

(...) until recently the only choices for these modelling languages were proprietary. So by using MDD not only were you choosing to use an obscure programming language with no published standard, you were locking yourself into the only proprietary tool that implemented it. These days its not so bad; there are open source MDD tools. But as far as I know there is no formal standard for the modelling language, which makes the portability of your model between tools effectively zero. This is ironic, given that portability is supposed to be one of the big advantages of MDD.

Este punto es particularmente observable, ya que MDD (y aún DSM) están lejos de ser cerrados, aún tratándose de lenguajes de modelado propietarios. Si sobre algo se ha trabajado en años recientes, es sobre interoperabilidad y metamodelos. Pensando en su visión enfocada en DSLs, Juha-Pekka Tolvanen contesta:

Based on my experience in hundreds of cases, MDD makes always sense when we can raise the level of abstraction with models above the code. In other words, the use of class diagram to represent a class with a rectangle symbol in order to generate a class in file makes very little sense! People who have tried this - usually with some UML tools - are obviously disappointed.
In order to raise the level of abstraction we usually need domain-specific concepts - often implemented into a language and supported by some tool. Luckily the metamodel-based tools that allow to define own languages are always ‘open’ in that respect that while they allow to define code generators (or have API, XML format etc for interchange) they always allow you to move your models to other similar tools too. So there is no locking as you described and there are even published bridges among metatools. IMHO: (and I work for a tool vendor) you should always choose a tool that allows you to move your data (models and metamodels) to other tools - if you don’t do that you have the lock problem you mentioned.

Cuestionamiento a la productividad:

First, to those who point to practical experience [...]: a "successful" project, at best, just means it it was delivered within the estimated budget and timescale (at worst it means a failure that was declared a success for political reasons). The real question is: does MDD deliver projects that cost less and take less time than any of the alternatives. I can have a successful project using assembler, provided I have the budget and time. So: do you have evidence comparing like-for-like that MDD costs less, and if so by how much?
I have only seen one study for MDD (which I can't locate right now) that found MDD development was 40% cheaper than conventional development. However that only compared two development teams, and so could easily have been due to random variation. Furthermore just using a higher level language can give even bigger savings. A study by Lutz Prechelt http://page.mi.fu-berlin.de/prechelt/Biblio//jccpprtTR.pdf gives a clear view of the range available both in developer ability and programming language. Ulf Wiger found that Erlang quadrupled productivity over C++, and the sparse evidence available suggests that Haskell is even more productive.

A este respecto, Juha-Pekka Tolvanen, con gran experiencia en lenguajes específicos de dominio, responde acudiendo a experiencias bien conocidas:

[Acerca de la observación sobre productividad] (“does MDD projects cost less and take less time”) is obviously difficult to answer in general since there are so many modeling languages and programming languages to compare. Ultimately it depends on how well the languages compared fit to the particular problem to be solved.
Since evaluating even two alternatives takes a lot of resources with a proper research method, companies usually don’t make detailed evaluation or at least do not publish them. Fortunately, some do. For example, Panasonic implemented the same system twice and reported 500% productivity improvement when comparing "MDD" to traditional manual coding in C (see http://www.dsmforum.org/events/DSM07/papers/safa.pdf). Polar arranged a laboratory study and a pilot project measuring at least 750% productivity (see http://www.dsmforum.org/events/DSM09/Papers/Karna.pdf). Similar significantly gains are reported by companies like Nokia, Lucent, EADS and Siemens which have defined their own domain-specific modeling languages along with code generators. You can check cases on using Domain-Specific Modeling from http://www.dsmforum.org/cases.html and if you want to see example languages on various domains, check http://www.metacase.com/cases/dsm_examples.html.
These above mentioned productivity figures are quite different than 40% mentioned. I would guess that they used a modeling language that only slightly raises the level of abstraction. Paul, can you find the reference for that case? We have been trying to collect reported cases over the years and this would be valuable addition.

Y Mark Dalgarno, basándose en las experiencias volcadas en las conferencias de Code Generation, responde:

The Code Generation conference has documented MDD success stories in the following domains:

Financial trading platforms
Administrative enterprise applications
Grid & Cloud applications
JEE enterprise applications
Control & Data acquistion systems
Simulation & Training systems
User interface generation
Mobile device applications
Insurance applications
Telecomms applications
Home automation systems
Business and organisational workflow applications
Technology platform migration
Security policy management
Legacy application modernization
Defence systems
Web applications
Hiding framework complexity, handling multiple frameworks
Middleware applications
Sensor Systems

This is by no means the limit of MDD potential.

HLLs (including the ones you list) only allow you to raise your abstraction level so far and it still seems that where MDD is applicable it can outperform HLL by an order of magnitude in terms of productivity depending on the problem domain.

(Se podría agregar a la contestación de Mark, que, más aún, sería indudablemente posible crear modelos que generasen código con los lenguajes de alto nivel sugeridos como "reemplazo" de los modeladores). Este punto particularmente muestra que el cuestionamiento parte de una base errónea.

Finalmente, dos aspectos defendidos por dos de los participantes merecen destacarse:
Rui Curado afirma:

MDD, with proper tool support, gives you additional benefits like traceability, automation, collective knowledge sharing.

Andrea Rocchini pone en el centro de la discusión lo mejor de MDD:

The real advantage of MDD is defining a problem/application with semantic rather than procedural flow.
A model contain all and only the relevant information about problem; it's totally decoupled from implementing technology.
A model can be transformed/interpreted with many tools and many patterns, now and in the future.
From a model we can produce many kind of entity: applications (for many platform), documentation, simulation processes, ...
A model could be designed by an expert of the domain problem rather than a programmer (an expert of IT technology ...)

A procedural flow in a programming language instead is a monolithic object; it's not much recyclable, is strongly technology dependant, conceptual design and implementation are mixed.
The necessary knowledge to have for developing a modern application is all-changing and every day growing.
All that is very frustrating.

Naturally the MDD approach is less free and result depend on quality of tool/interpreter.

Para quienes sean miembros de LinkedIn, la dirección de la discusión, aquí.