Críticas a MDD desde dentro: Rigidez del código, parte II

Tratando de completar las ideas que el primer punto de Johan sugiere, quisiera volver sobre el carácter abstracto de MDD (The goal of MDD is to ‘program' on a higher level of abstraction. This means that you have to specify less and generate more. However, this also means that you can't change every little detail you want).
Muchas de las objeciones atribuidas primero a MDA, pero luego extensibles a MDD (la visión ampliada y variada del diseño basado en modelos), están aquí. El primer acusado es UML, el estándar definido por OMG primero como herramienta de modelado, y luego como soporte para expresar modelos traducibles a código. ¿Es suficiente UML para expresar de manera abstracta toda la lógica de un sistema? ¿Es posible bajar en el nivel de detalle de un sistema recurriendo sólo a las herramientas propias de UML (vistas de diagramas y OCL)? Estas objeciones provienen especialmente de quienes usan o discuten MDA; sin embargo, no escapan a estas preguntas las variadas alternativas de solución ajenas a MDA (Johan describe algunas de estas variantes).
MDD, en sus distintas vertientes, probablemente esté atravesando un período parecido al que atravesara UML en la década de los 90: distintas notaciones se fueron forjando para expresar el diseño orientado a objetos, convergiendo en un esquema consensuado y no propietario, suficientemente potente como para responder a su tarea. El desarrollo de aplicaciones basado en modelos abstractos y generables, capaces de aplicarse a distintas plataformas y a distintas arquitecturas, mejorará sus herramientas y logrará mejores resultados. ¿El esquema de extensiones de Eclipse podría ser una respuesta a la apuntada "falta de flexibilidad"? ¿Alguna variante de DSLs aplicados en el espacio hoy llamado "rígido" podría aumentar la granularidad de los sistemas?
En el caso de Plex (mi herramienta de trabajo, para cualquiera que lo desconozca), este espacio está cubierto por el concepto de "diagramas de acción": llamémoslo un script abstracto, capaz de moverse en un meta nivel materializable en distintas encarnaciones, fuertemente restringido por los objetos a los que sirve (no es posible referirse a ningún objeto que no esté definido en el modelo, ni violar los tipos que manipula), que puede sin embargo ser detallado y minucioso. ¿Es una solución definitiva? No, porque globalmente podría llegar a expresar en un conjunto de diagramas algo contradictorio con el comportamiento esperado del modelo. No es sustituíble el trabajo del diseñador para expresar su modelo; un mal diseño también puede ser plasmado en un modelo escrito con UML.
En fin, digamos que el punto 1 de los ocho enumerados por Johan den Haan, pone el acento en un problema en discusión, que está en el laboratorio. Y que probablemente se refinará y quizá incluso desaparezca. Sin duda, en primer lugar, su objeción a la calidad de la interface gráfica.
En los próximos días seguiremos con otros puntos...