¿Qué es exactamente la ingeniería de software basada en modelos (MDSE)?

Me encontré con el acrónimo MDSE hoy en infoq , y la información que pude encontrar era bastante poco clara y la descripción estaba llena de palabras de moda:

MDSE se trata de permitir que los ingenieros de software trabajen en un nivel de abstracción donde los requisitos, la información de arquitectura y diseño se ordenan al máximo (en términos de "entropía" de información) y se conservan. (Llame a esto el "producto de trabajo de diseño"). Además, MDSE debe proporcionar a los ingenieros los medios para verificar y validar sus diseños, principalmente los términos de su "producto de trabajo de diseño"

Y aparentemente, todos lo están haciendo: (del artículo nuevamente)

Estamos al amanecer de la era de MDSE. En los próximos 5 a 10 años, veremos un cambio significativo hacia MDSE, en la medida en que creo que para el final de este período, tal vez 60 a 80% del software se diseñará utilizando técnicas basadas en modelos.

Me gustaría tener una descripción concreta y sin palabras de moda de lo que es MDSE. ¿Dibuja cajas UML y genera código con ellas, como hicieron en los años 90 con Rational Rose?

(mientras lo hacíamos, si alguien tiene un ejemplo de software generado usando esas técnicas, realmente me gustaría ver un ejemplo concreto).

La "ingeniería de software basada en modelos (MDSE)" es la promesa de marketing de los fabricantes de herramientas de software de que "pronto" se pueden generar partes significativas de software a partir de modelos de software.

El socio de la entrevista en el artículo al que se refiere , Robert Howe, es un fabricante de herramientas (consulte http://www.verum.com/ para más detalles)

Pero contra las promesas de los fabricantes de herramientas, mdse aún no se ha generalizado.

El sistema de tienda de internet hybris es un ejemplo de trabajo de "MDSE": usted como desarrollador de software mantiene archivos xml-model ("* -items.xml") y los generadores de código / intérpretes generan db-modell / java-code para persistencia / guis fuera de el. Si necesita un atributo adicional, simplemente agréguelo al modelo xml y después de que el generador / intérprete haya hecho su trabajo, puede usar el atributo para implementar la lógica de negocios.

En mi humilde opinión "modelo impulsado " es una gran exageración, especialmente cuando se utiliza en conjunción con palabras de moda como "diseño" o "ingeniería de software" (en lugar de "desarrollo"). Probablemente fue inventado por algunas personas que tienen la idea errónea de que el "diseño de software" se realiza dibujando algunos modelos en su mayoría gráficos con UML, como un arquitecto está dibujando un plano para una casa, y la "codificación" es como poner los ladrillos para la casa, siguiendo el plano. (Espero no tener que explicar aquí por qué esto está mal, si tiene una opinión diferente, lea primero "Code as Design" de Jack Reeves antes de rechazarme).

Este es un gran modelo mental para aquellas personas que se hacen llamar "arquitectos", "analistas de negocios", "diseñadores", "ingenieros de software", que han estudiado cinco años de informática, pero solo medio año de experiencia real en programación (como máximo ), y ahora busca un trabajo en la industria del software que incluye "diseñar software" sin codificación. Supongo que esta es la verdadera razón por la que estas palabras de moda "basadas en modelos" son tan populares.

No me malinterpreten, soy un gran admirador de los modelos y generadores de código para reducir la necesidad de escribir código repetitivo manualmente. En algunas áreas restringidas como, por ejemplo, las bases de datos, los modelos (de datos) pueden ser un buen instrumento para comunicarse con las personas del dominio. Dibujar el flujo de datos entre componentes por modelos es, en mi humilde opinión, una de las técnicas más importantes para incorporar la estructura a un sistema de software (desafortunadamente, las personas de UML olvidaron negarse a incluir diagramas de flujo de datos en su notación; en cambio, agregaron un montón de cosas innecesarias y redundantes que nadie usa en la práctica).

Pero yo llamaría a esto " desarrollo de software compatible con modelos ", no " ingeniería de software basada en modelos ", lo que deja claro que el modelado solo respalda las actividades principales en el desarrollo, en lugar de ser la actividad principal en sí misma.

Esto me recuerda a muchos modelos Fat, concepto de controladores flacos .
La idea principal de este concepto es poner la mayor cantidad posible de lógica de negocios en el modelo y mantener el controlador y una vista muy simplista.
Personalmente, me parece una idea muy interesante, aunque no he tenido la oportunidad de usarla.
Sorprendentemente, 8 de cada 10 enlaces principales en la búsqueda de Google hablan en contra.
Pero, si piensa en un modelo no como una sola clase, sino como una fachada de múltiples clases internas, tiene mucho sentido mantener la lógica empresarial en el modelo.