Algunos peligros del MDD

El MDD (Model Driven Development), o términos similares como MDA (Model-Driven Architecture), es una estrategia de desarrollo software que persigue la generación automática del código desde especificaciones de alto nivel, uno de los objetivos más antiguos de la investigación en ingeniería y desarrollo software. Poder implementar software “automáticamente” desde lenguajes que especifican las funcionalidades (llamados en este contexto domain-specific languages o DSLs).
Aunque al MDD le queda mucho por avanzar, en los últimos años ha evolucionado bastante, y se ha incrementado su popularidad, por lo que se empiezan a escuchar proyectos que se plantean su uso.
Y leyendo sobre las diferencias entre un proyecto MDD y un desarrollo software tradicional, llegue a esta entrada del blog “the Enterprise architect”, que comenta algunos peligros que plantean los proyectos de desarrollo basados en MDD:
– MDD introduce mucha rigidez. El objetivo del MDD es “programar” a un alto nivel de abstracción. Esto implica que tienes que especificar menos y generar más. Lo que implica que no puedes cambiar pequeños detalles.
– Los modelos son solo flexibles donde la flexibilidad ha sido diseñada. Y esta flexibilidad depende de la herramienta utilizada y de las partes que ha cubierto el DSL.
– Los roles de los miembros del proyecto son muy diferentes. El software lo realizan los llamados “ingenieros de negocio”, en vez de los programadores, que necesitan conocer el negocio y saber especificarlo en un modelo formal.
– Los entornos de modelado no siempre soportan control de versiones. Las herramientas de control de versiones trabajan bien con “programas textuales”, pero con modelos gráficos la cosa no está tan clara.
– La herramienta de modelado está “casi” terminada. Si la herramienta no está totalmente terminada y suficientemente probada antes de comenzar el proyecto puedes tener un serio problema.
– El equipo necesita comprender qué está permitido y qué no. Un punto peligroso aparece cuando la gente que habla con el cliente no comprende las limitaciones del MDD y de sus herramientas.
– El equipo no tiene experiencia. Por la poca experiencia de MDD en el mercado, existe el riesgo de lanzar un proyecto de MDD con un equipo sin experiencia, lo que puede meternos en serios problemas.
– Las distracciones de la innovación. La gente tiende a centrarse en las herramientas, y se pasa por alto la gestión del proyecto y otros aspectos más allá de la herramienta.

0 comentarios en “Algunos peligros del MDD”

  1. Pingback: Bitacoras.com

  2. En cuanto a lo del control de versiones, con MDD creo que pueden existir muchas limitaciones. No veo la manera de comparar dos versiones con poco esfuerzo y de ahí que sea muy dificil detectar qué has podido tocar cuando has provocado un fallo en la aplicación que antes no existía…
    Un saludo.

  3. Como todo enfoque tecnologico o metodologico, puede ser usada para bien o para mal.
    Los peligros se derivan de su uso incorrecto o abuso, pero bien entendida y aplicada aporta muchos beneficios, que tambien los tiene.
    Un practicante de MDD.
    Un saludo.

  4. Totalmente de acuerdo en lo que se comenta en el Post.
    Aquí, en la Comunidad Valenciana, hubo una experiencia a la que se le dio muchñisimo bombo y publicidad, llamada «la máquina de programar» (love machine en nuesta forma de hacer humor ;))).
    Se vendía como una panacea y resultó ser un absoluto fracaso precisamente por los riesgos que mencionas en el post. Falta muchísimo qeu avanzar (y no solo en aspectos técnicos) para que estas iniciativas puedan ser una realudad en entornos «de verdad», complejos, cambiantes, muchas veces singulares.
    Y ¿qué pasa con los desarrolladores de verdad?. Haciendo un simil… podríamos estar ante una situación parecida a los programas que «mueven fichas de ajedrez»…

  5. I’m sorry but my Spanish is not good enough for commenting in so I hope you don’t mind my using English.
    Interesting and very valid points! Yes, I do represent a tool provider but I really believe a lot depends not only on what you use it for and how but also what tools you use. There are some more or less fortunate paradigm choices involved in every tool development. Importent differnces in this respect are e.g. whether the models created can handle your custom code alongside with the abstractions so that it can all be in the generated code. As far as verions, there is also a major divide viz. between generating code based on model evolution rather than model state.
    Regards,
    Joar

  6. Que bueno, un debate sobre MDD en español, hacia tiempo que no veía uno. Esto se anima como dice Javier.
    Quisiera recalcar que MDA!=MDD.
    MDA esta incluido en MDD (es una forma de hacer, usando UML y sus mecanismos de extension preescritos por la OMG) Pero hay mas, ha gente que hace MDD fuera de MDA, empleado DSL, por ejemplo.
    Lo comento porque algunas de las pegas esgrimidas lo son más de las herramientas MDA/UML y el rigido formato en el que se mueven.
    @jenriquez
    Si se emplea MDD de forma organizada y tus modelos tienen una representación textual (ficheros de texto no binarios, estoy pensando en DSLs, XML sirve también como representación primaria) las herramientas que tengas de control de versiones te sirven tal y como las usas. Git, Mercurial, TFS, Clear Case, etc. son totalmente funcionales, para código o para modelos ¿cual es la diferencia? Yo los uso perfectamente y no tengo problemas.
    Para ver diferencias entre versiones tienes herramientas de tipo diff, de texto y visuales, las hay gratuitas (p.e. Winmerge) y comerciales.
    Otro tema es que intentar ver diferencias en ficheros binarios. Aquí hará falta versionado desde la propia herramienta: y es mas complejo, claro: aqui si que esta un poco verde el tema.
    @ajimenez Comentas un caso que conozco muy bien. Participe directamente durante cinco años desde su concepción en la ingeniería del producto que citas. Mi visión desde dentro en aquellos días es otra: hubo bastantes más fallos de marketing y de estrategia de producto que de ingeniería. Una cosa es saber fabricar el producto y otra diferente saber venderlo.
    Es cierto que se le dio mucho bombo, mucho pero mal. No hay nada peor que un comercial que alardea de lo que no sabe junto con un periodista que amplifica las barbaridades que escucha y no conoce.
    El resultado desastroso: quieres leer un articulo en prensa que se supone alaba la I+D que se hace en este país, y de cual como trabajador te sientes orgulloso, y cuando acabas de leerlo te avergüenzas de la pseudociencia que allí se cuenta por lo mal que se ha explicado, por exageración y/o por ignorancia.
    Animo a dejar prejuicios a un lado sobre MDD. Desde mi punto de vista es inevitable. Las herramientas están madurando muy rápido y serán una herramienta de productividad indispensable del mismo modo que el COBOL liquidó el desarrollo en ensamblador. Es simplemente una capa mas de abstracción sobre la que trabajar. Como en todas las épocas habrá buenos y malos programadores usando COBOL o la herramienta que tengamos a bien emplear.
    Si os interesa el tema os animo a seguir el próximo Code Generation 2011 donde se presenta el estado del arte en MDD. http://www.codegeneration.net/cg2011/index.php
    Por allí estaremos presentando Johan de Haan (que se dedica a esto del MDD en la compañia para la que trabaja Mendix.com), Angelo Hulshout, Markus Voelter y un servidor entre otros debatiendo sobre MDD / MDSD.
    ¿@Jordi Cabot te animas a venir este año al CG2011?

  7. Ya pedro, pero Mdd vende trabajar graficamente – semanticamente, obviamente que si utilizas ficheros ascii puedes versionar como toda la vida pero dudo que ese formato tenga la semantica que pide un mdd

  8. Discrepo @fran.
    GMF, MS DSL Tools son ejemplos de herramientas que permiten modelar de modo gráfico pero almacenan sus datos en formatos de texto XML que son versionables y comparables con herramientas de texto.
    Otra tema es que algún fabricante esté pensando en hacer un comparación gráfica y lo logre con mejor o peor éxito.
    Ademas existen otras herramientas de MDD como XText, TextUML, Spoofax por citar algunas basadas en DSLs donde se trabaja a nivel de texto (sin gráficos y no deja de ser MDD) sin por ello renunciar a la semántica.
    Una cosa es la el modo de representación: texto o gráfico, otro aspecto es como se almacenan los modelos.
    Como muestra un botón:
    http://yuml.me/diagram/scruffy/class/%5BModelo%5D+1-*%5BRepresentación%5D
    ¿Lo importante aquí que es? ¿El dibujo, la URL o los conceptos?
    No he encontrado ningún dibujo que no se pueda representar como un grafo a texto o XML.
    Según el tipo de información a adquirir o presentar sera mas adecuada una representación gráfica (ejemplo diagrama de estado), textual (algoritmia), tabular (casos de prueba) etc. pero la semántica es la misma, lo pintemos como lo pintemos. La semántica esta en el modelo, no en el modo de representación.

  9. El escepticismo que despierta el MDD puede deberse a que generalmente se ha identificado con objetivos demasiado ambiciosos. La idea de definir unos cuantos modelos, darle a un botoncito y generar una macro-aplicación completa desde cero, no parece factible (al menos a día de hoy). Ahora bien, la idea si se ha demostrado útil para dominios más «cerrados». Por ejemplo, el MDD se aplica en el desarrollo de líneas de producto, donde las aplicaciones generadas comparten gran cantidad de código y los puntos de variabilidad están identificados a priori. De hecho, prácticamente todos en un momento u otro hemos usado una herramienta que sigue los principios del MDD. Cuando usamos XML Spy para definir (en realidad modelar) un XSD o cualquier herramienta de diseño de BBDD para definir (de nuevo, modelar) el esquema de nuestra BBDD estamos aplicando los principios del MDD. Lo que se está haciendo en los últimos años es tratar de llevar la idea un paso más allá …

  10. Parece que el debate está muy interesante 🙂
    @Pedro J. Molina
    A lo que me referia es a la comparación de dos versiones de ficheros binarios, es decir, a la comparación del modelo como tal y no su representación textual.
    Cuando el modelo sea complejo, quizás su representación textual no sea demasiado intuitiva y de ahí las limitaciones en este aspecto que yo le veo.
    Sería muy interesante poder ver las diferencias de dos modelos de manera gráfica… ¿existe alguna herramienta que permita esto? Yo personalmente la desconozco.
    Un saludo.

  11. También estoy familiarizado con la herramienta valenciana tan criticada, y estoy al 100% de acuerdo con el comentario de Pedro J. al respecto, en cuanto a sus fallos, marketing sobre todo, pero también en que ha tenido muchísimas cosas positivas.
    Entre éstas, es una herramienta que funciona, y lo que hace lo hace muy bien, aunque hay que saber usarla. También ha dado respuesta a varios de los problemas descritos, con herramientas adecuadas, es decir:
    – Gestión de versiones de modelos.
    – Gestión de cambios sobre código generado.
    Dando soluciones, sino óptimas, bastante utilizables y útiles manejándolas bien…
    Y mi experiencia es que bien usadas la productividad para la aplicación típica se dispara, tema aparte la «publicidad magufa»…
    Ya hace tiempo que no estoy usándola, pero sigo otras que hay en el mercado, y cada vez soy más de la opinión que si MDD no está más extendido es porque «los grandes», MS, IBM, Oracle, etc…, no están interesados, y promocionan otras plataformas de desarrollo, ADF JDev SOA, BPM,etc.., el Visual Studio, etc.., para los que cada vez se necesita más personal y no menos…, la gracias es facturar…
    Saludos

  12. Es cierto, llueve sobre mojado desde los 80: CASE, generación de código como bala de plata ha producido mucho rechazo en el mercado por extenuación de promesas incumplidas.
    Pero mas allá del humo, hay mucha vida bajo MDD y tecnología bien interesante.
    Por ello abogo por evaluar y criticar cada herramienta concreta, cada producto en su contexto con sus pros y contras, mas allá de generalizar y etiquetar MDD.
    @Juan M. Vara, desde mi experiencia: de partida yo no renuncio a ese objetivo como utopía: «Dibuja cuatro modelos y pulso un botoncito que genera la aplicación.»
    Desde el punto de vista practico, hay que acotarlo al dominio particular (ver si es viable y echar cuentas: análisis coste/beneficio): A veces no merece la pena porque no es rentable, otras veces si (porque el dominio esta acotado y hay mucho volumen, por ejemplo en Banca). Otras veces, una aproximación de 80% (generado) – 20% (a mano) es mas que suficiente y justifica el ROI para aplicar MDD.
    La utopía de generar el 100% esta bien como ideal, pero si en el dominio particular no se llega porque es técnicamente imposible o no es viable económicamente, y se alcanza por contra un 70% de código generado es perfectamente asumible: el equipo de desarrollo podrá centrarse el 30% faltante y aun asi les hemos ahorrado mucho trabajo de «fontanería» repetitiva.

  13. @jenriquez: no se si EMFCompare podría ser una respuesta. Te permite mostrar gráficamente las diferencias entre dos modelos, casi como si lo fueran entre dos ficheros. Entre sus ventajas desde el punto de vista del desarrollo dirigido por modelos, la posibilidad de exportar las diferencias a otro modelo, al que luego puedes «meter mano» con transformaciones, etc. Sobre la base de EMFCompare la gente desarrolla su herramienta de comparación de modelos ad-hoc …

  14. Tengo una posición intermedia en el uso de MDD: trabajo con un producto (Plex) ideado a fines de la época de CASE, con lo que tiene un pie en cada época. Sigo la evolución de MDD/MDA quizá desde sus propios orígenes, y, conociendo las líneas de desarrollo existentes, confío plenamente en su capacidad para lograr sus objetivos, tanto en lo que ya es posible, como en cuanto a las líneas de desarrollo en curso. Si hablara por lo que uso, diría que me siento confortable, y que, aunque espero que mejore, con lo que tengo disponible puedo cubrir algunas de las áreas propuestas (independencia de plataforma, capacidad para describir un modelo, posibilidad de versionar, capacidad de expresar una lógica, integridad del modelo).
    Por lo demás, luego de una época en que MDD fuera casi sinónimo de MDA Y UML, se ha llegado a un estado de desarrollo y deliberación en que múltiples soluciones colaboran a mejorar sus posibilidades (A mi juicio, las herramientas orientadas a DSL de ninguna manera son divergentes, sino complementarias de MDD). Por mi situación, no estoy en condiciones de argumentar estrictamente por las técnicas y sustrato teórico que las corrientes principales de MDD sostienen. Sin embargo, basado en mi experiencia, y en lo que conozco del trabajo de distintas corrientes, puedo sostener algunas afirmaciones:
    # que elaborar el software en una capa de abstracción despegada de la codificación directa es una verdadera ventaja.
    # y que esto lo es especialmente por la posibilidad de elaborar un modelo independiente de la plataforma a la que va destinado. No es un sueño tener una lógica que con cambios menores sea aplicable a un entorno Unix/Windows/iSeries, alternativamente, o combinados.
    # que, considerando la explosión de arquitecturas, y la complejidad de interrelaciones entre aplicaciones, MDD representa una posibilidad racional de abordar esta exuberancia
    # que un modelo no tiene por qué ser sólo estático, como quizá en un primer estadio lo fueran. Bajo distintas variantes, es posible expresar la lógica, la conducta del modelo
    # que es posible (tiene que ser posible) versionar un modelo. En mi caso, lo es.

  15. @Jorge Ubeda: Lo lamento…apostillé una frase de Pedro de tal forma que quedó invisible. Repito lo que falta al comienzo de mi comentario anterior:
    dice Pedro y comparto: «Por ello abogo por evaluar y criticar cada herramienta concreta, cada producto en su contexto con sus pros y contras, mas allá de generalizar y etiquetar MDD.»

  16. Hola amigos.
    Interesante el debate. Por experiencias puedo contarles que vengo entrandole al MDD desde hace rato, al principio nos vendieron la idea que era como la Octava Maravilla del Mundo, lo evaluamos para algunos proyectos e hicimos algunas demos y pruebas y uffff fracazo total…. No era lo que esperabamos… eran los principios y puedo comentar que nos paso esto:
    1. Nuestro equipo tenia mucha resistencia al cambio y exceptisismo a lo que nos querian vender.
    2. Nuestro consultor era un vendedor que no sabia nada de arquitectura de sw.
    3. Nuestro consultor no tenia experiencia en proyectos y tenia otro consultar que conocia la herramienta, pero que tampoco tenia experiencia en proyectos.
    Con estas tres cositas, el fracazo era obvio…..
    Pero me quedo la espina como decimos en mi país, de que esas teorias que no funcionaron hace 10 años, tenian buena pinta…. era de esperar que evolucionaran mas.
    10 Años despues, han super mejorado….
    No lo dudo, estamos iniciando el futuro…. con estas nuevas herramientas.
    Una Pregunta. estan listas estas herramientas para afrontar proyectos serios? Totalmente SI.
    Estamos listos nosotros? Algunos si.
    Pero amedita un cambio de pensamiento, significa obtener los mismos resultados (programas), pero de forma diferente, por ende con herramientas diferentes y metodos diferentes.
    Control de versiones? Si se puede, hay que saber como.
    Por el momento no puedes hacer todo con MDD, pero puedes hacer una muy buena parte, el resto es de hacer la combinación entre tu metodo actual y tu metodo MDD… y obtendras maravillas….
    La naturaleza es asi, Hombre/Mujer hacen la maravilla de la vida….
    Metodo Tradicional/MDD hacen una maravilla….
    Saludos

  17. En un punto, algún tipo de abstracción de más alto nivel es inevitable, basta ver la evolución del software, y el modo en el cual vaya a seleccionarse la herramienta, no será más que por evolución, que es la forma en la que se seleccionaron las tecnologías que hoy usamos.
    También me gustó leer sobre estos temas en español.
    Les dejo algo sobre lenguajes http://sourcenotas.blogspot.com.ar/2013/02/lenguajes.html
    Saludos!

Deja un comentario

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *

Share This
Ir arriba