¿Utiliza MDA/MDD/MDSD, algún tipo de enfoque basado en modelos?¿Será el futuro?

https://stackoverflow.com/questions/21091

09-06-2019
|

Pregunta

Los lenguajes de programación tuvieron varios pasos (r)evolutivos en su historia.Algunas personas sostienen que los enfoques basados en modelos serán la próxima gran novedad.Existen herramientas como openArchitectureWare, AndroMDA, Sculptor/Fornax Platform, etc.que prometen increíbles aumentos de productividad.Sin embargo, tuve la experiencia de que al principio es bastante fácil comenzar, pero también quedarse atascado en algún momento cuando intentas algo inesperado o es bastante difícil encontrar suficiente información que te diga cómo comenzar tu proyecto porque puede haber muchas cosas a considerar.

Creo que una idea importante para sacar algo de algo basado en modelos es comprender que el modelo no es necesariamente un conjunto de imágenes bonitas, un modelo de árbol o UML, sino que también puede ser una descripción textual (por ejemplo,una máquina de estados, reglas de negocio, etc.).

¿Qué opinas y qué te dice tu experiencia?¿Existe futuro para el desarrollo basado en modelos (o como quiera llamarlo)?

Actualizar: No parece haber mucho interés en este tema.Avíseme si tiene alguna experiencia (buena o mala) con enfoques basados en modelos o por qué cree que no es nada interesante.

Solución

Creo que llevará tiempo hasta que las herramientas se refinen más y más personas adquieran experiencia con el TDM.De momento si quieres sacar algo de provecho de MDD tienes que invertir bastante, por lo que su uso sigue siendo limitado.

Mirando openArchitectureWare, por ejemplo:Si bien es bastante sólido y existe documentación básica, falta documentación sobre el funcionamiento interno y todavía hay problemas con la escalabilidad, que no están documentados; tal vez eso mejore cuando se reescriban Xtext y Xpand.

Pero a pesar de esas limitaciones, la generación en sí es bastante fácil con oAW, puedes navegar por tus modelos a las mil maravillas en Xtend y Xpand y, al combinar varios flujos de trabajo en flujos de trabajo más grandes, también puedes hacer cosas muy complejas.Si es necesario, puedes recurrir a Java, por lo que tienes una gran flexibilidad en lo que puedes hacer con tus modelos.Escribir tu propio DSL con Xtext en oAW también se hace rápidamente, pero obtienes tu metamodelo, un analizador y un editor muy bueno básicamente gratis.También puedes conseguir tus modelos básicamente desde cualquier lugar, p.e.un componente que puede convertir una base de datos en un metamodelo y los modelos correspondientes se pueden escribir sin gran esfuerzo.

Entonces yo diría que MDD todavía se está desarrollando, a medida que aumentan las herramientas y la experiencia con él.Ya se puede utilizar con éxito si tiene la experiencia necesaria y está preparado para impulsarlo dentro de su empresa.Al final, creo que es algo muy bueno, porque se puede y se debe generar una gran cantidad de código adhesivo (también conocido como copiar y pegar).Hacer eso con MDD es una forma muy agradable y estructurada de hacerlo, que, en mi opinión, facilita la reutilización.

Otros consejos

Descargo de responsabilidad:Soy desarrollador de aplicaciones empresariales.La siguiente visión ciertamente está determinada por mis experiencias en las trincheras de TI empresarial.Soy consciente de que existen otros dominios del desarrollo de software.Especialmente en el desarrollo de sistemas industriales y/o integrados, el mundo podría verse diferente.

Creo que MDSD todavía está demasiado ligado a la generación de código.

La generación de código solo es útil cuando su código contiene mucho ruido y/o es muy repetitivo.En otras palabras, cuando su código no puede centrarse principalmente en la complejidad esencial, sino que está contaminado con una complejidad accidental.

En mi opinión, la tendencia en las plataformas y marcos actuales es exactamente eliminar la complejidad accidental y dejar que el código de la aplicación se centre en la complejidad esencial.

Así que estas nuevas plataformas/marcos quitan mucho viento a las velas del movimiento MDSD.

Los DSL (textuales) son otra tendencia que intenta permitir centrarse únicamente en la complejidad esencial.Si bien los DSL se pueden utilizar como fuente para la generación de código, no están vinculados principalmente a la generación de código.Los DSL (especialmente los DSL internos) básicamente permiten que se abra para ser interpretado/ejecutado en tiempo de ejecución.[La generación de código de tiempo de ejecución está en algún punto intermedio].

Entonces, incluso si los DSL se mencionan a menudo junto con MDSD, creo que son realmente una alternativa a MDSD.Y dado el revuelo actual, también le quitan impulso al movimiento MDSD.

Si ha alcanzado el objetivo de eliminar en última instancia la complejidad accidental de su código (sé que esto es ficticio), entonces ha llegado a un modelo textual de su problema empresarial.¡Esto no se puede simplificar más!

¡Los bonitos cuadros y diagramas no ofrecen otra simplificación o elevación del nivel de abstracción!Puede que sean buenos para la visualización, pero incluso eso es cuestionable.¡Una imagen no siempre es la mejor representación para captar la complejidad!

Además, el estado actual de las herramientas involucradas en MDSD agrega otro nivel de complejidad accidental (piense:sincronización, diferenciación/fusión, refactorización...) lo que básicamente anula el objetivo final de la simplificación.

Mire el siguiente modelo de ActiveRecord, como ilustración de mi teoría:

class Firm < ActiveRecord::Base
   has_many   :clients
   has_one    :account
   belongs_to :conglomorate
end

No creo que esto pueda simplificarse más.Además, cualquier representación gráfica con cuadros y líneas no sería una simplificación y no ofrecería más comodidad (piense en diseñar, refactorizar, buscar, diferenciar...).

El desarrollo basado en modelos existe desde hace mucho tiempo.

El más exitoso de los primeros intentos fue James Martins Integrated Engineering Facility, que todavía existe y lo comercializa CA bajo la marca "Coolgen", que no está nada de moda.

Entonces, ¿por qué no se apoderó del mundo si era tan bueno?

Bueno, estas herramientas son buenas para simplificar las cosas simples, pero no hacen las cosas difíciles más fáciles y, en muchos casos, ¡hacen las cosas difíciles más difíciles!

Puedes pasar horas tratando de persuadir a un lenguaje de modelado gráfico 4GL para que "haga lo correcto" cuando sabes que codificar lo correcto en Java/C/SQL o lo que sea sería trivial.

Creo que tal vez no haya una respuesta definitiva, de ahí la falta de "interés" en esta pregunta.

Pero personalmente he tenido experiencias mixtas con la MDA.La única vez que fue una buena experiencia fue con excelentes herramientas: solía usar TogetherSoft (creo que de alguna manera terminaron en borland). Fueron uno de los primeros en introducir la edición, que no era "generación de código", sino editar el código. modelo directamente (para que pudieras editar el código, o el modelo, era todo uno).También tuvieron refactorización (que fue la primera vez que lo recuerdo después de entornos de charlas triviales).

Desde entonces no he visto a la MDA crecer más en popularidad, al menos en la corriente principal, por lo que en términos de popularidad no parece ser el futuro (así que eso es la respuesta).

Por supuesto, la popularidad no lo es todo, y las cosas tienden a volver, pero por el momento creo que muchos consideran que las herramientas MDA+ son herramientas de "generación de código basada en asistentes" (independientemente de lo que realmente sean), así que Creo que pasará algún tiempo o tal vez nunca antes de que realmente despegue.

Uno de los problemas de MDD es que, dado que funciona en un nivel de abstracción más alto, requiere desarrolladores que también puedan subir ese nivel de abstracción.Eso reduce en gran medida el universo de desarrolladores que pueden comprender y utilizar dichas metodologías.

Avíseme si tiene alguna experiencia (buena o mala) con enfoques basados en modelos o por qué cree que no es nada interesante.

Creo que los contribuyentes aquí son parte del campo "No Silver Bullet" (definitivamente lo soy).Si MDA funcionara (equivale a "enormes ahorros"), lo sabríamos, eso es seguro.La pregunta es:¿Hasta dónde puede llegar "meta" manteniendo su sistema manejable?Este fue el punto de inflexión en UML 2.0 cuando introdujeron un meta-meta-modelo más formal.Hasta ahora, no he visto un uso en el mundo real del poder de modelización de UML 2.0 (pero mi mundo es bastante limitado).Además, sólo tiene dos opciones con un enfoque basado en modelos:generar código o tener un tiempo de ejecución que explote su modelo.El generador de código sin restricciones definitivo se llama "humano", mientras que los tiempos de ejecución definitivos se encuentran en los 4GL (¿cuál es el número actual hoy en día?).Quizás eso explicaría la falta de entusiasmo.

Nosotros, en itemis (www.itemis.com), utilizamos mucho el desarrollo de software basado en modelos.Hasta ahora hemos tenido muy buenas experiencias.Shu, no es una solución milagrosa, pero ayuda a mejorar la calidad del software y, por lo tanto, a un mayor uso para nuestros clientes.

El desarrollo impulsado por modelos será el futuro si y sólo si los modelos que utiliza pueden ser tan flexibles como escribir el código que se supone debe generar.Creo que la razón por la que no está funcionando tan bien en este momento es que es difícil hacer el mismo "viaje de ida y vuelta" que los lenguajes de programación basados en texto han estado haciendo durante décadas.

Con los lenguajes de programación basados en texto, cambiar el modelo es tan sencillo como cambiar unas pocas líneas de código.Con un lenguaje de programación gráfico (también conocido como diagrama MDD como UML), tienes que encontrar una manera de traducir ese modelo hasta su equivalente basado en texto (que ya era expresivamente eficiente en primer lugar) y puede ser muy, muy desordenado.

En mi humilde opinión, la única forma en que MDD puede ser útil si se construye desde cero para ser tan expresivo y flexible como su contraparte basada en texto.Intentar utilizar lenguajes de diseño gráfico de arriba hacia abajo (como UML) existentes para herramientas que se construyen inherentemente de abajo hacia arriba utilizando abstracciones en capas (como los lenguajes de programación) plantea una enorme falta de coincidencia de impedancia.No puedo identificarlo, pero todavía falta algo en MDD que lo haría tan útil como la gente dice que es...

Esta es una respuesta muy tardía, pero actualmente estoy buscando herramientas MDD para reemplazar a Rose RT, que lamentablemente está siendo reemplazada por Rhapsody.Estamos en el espacio C++ integrado y distribuido en tiempo real y sacamos MUCHO provecho de MDD.Estamos intentando pasar a una herramienta mejor y lograr un uso más generalizado de la misma en nuestra gran empresa.Es una batalla cuesta arriba por algunas de las buenas razones mencionadas aquí.

Pienso en MDD como sólo un nivel por encima del compilador, al igual que el compilador está por encima del ensamblador.Quiero una herramienta que me permita, como arquitecto, desarrollar el marco de la aplicación y editar ampliamente la generación de código (scripts) para usar ese marco y cualquier middleware que estemos usando para pasar mensajes.Quiero que los desarrolladores creen clases UML completas y diagramas de estado que incluyan todo el código necesario para generar la aplicación y/o biblioteca.

Es cierto que puedes hacer cualquier cosa con código, pero resumiría a grandes rasgos los beneficios de MDD así:

Algunas personas crean el marco de la aplicación, los adaptadores de middleware y los pegan a la herramienta MDD.Ellos construyen la "casa".
Otras personas crean clases completas, diagramas y códigos de transición de máquinas de estados.Esto les permite centrarse en la aplicación en lugar de en la "casa".
Es fácil ver cuando la gente tiene un diseño extraño ya que el diagrama es el código.No tenemos todos los desarrolladores expertos y es bueno formar gente joven de esta manera.
Principalmente es el código de máquina de estado desagradable que puede ocurrir en algo así como un proyecto de robótica móvil.Quiero gente que haga diagramas de estado que pueda entender, criticar y trabajar en ellos.
También puede realizar una buena refactorización, como arrastrar operaciones y atributos hacia cadenas de herencia o hacia otras clases, etc.Me gusta más eso que buscar en archivos.

Mientras escribo esto me doy cuenta de que puedes hacer todo en código.Me gusta una herramienta delgada justo encima del código para imponer la uniformidad, documentar el diseño y permitir una refactorización un poco más fácil.

El principal problema que encuentro y para el que no tengo una buena respuesta es que no existe un conjunto estándar de funcionalidades y formatos de archivo para dichos modelos.A la gente le preocupa que el proveedor se vaya y luego se quede estancado.(Básicamente nos pasó eso con Rose RT). Eso no ocurre con el código fuente.Sin embargo, tendrá la última versión de la herramienta y el código del curso que generó por última vez :).Estoy dispuesto a apostar que el beneficio supera el riesgo.

Todavía tengo que encontrar una herramienta como esta, pero estoy tratando de que algunos proveedores me escuchen y tal vez acepten dinero para que esto suceda.

Licenciado bajo: CC-BY-SA con atribución

No afiliado a StackOverflow