¿Estás haciendo MDA (Model Driven Architecture) en este momento? Si es así, ¿qué herramientas usa y cómo funciona?

Question

Model Driven Architecture es la idea de que cree modelos que expresen el problema que necesita resolver de una manera que esté libre de cualquier (o al menos la mayoría) de las tecnologías de implementación, y luego genere la implementación para una o más plataformas específicas. La afirmación es que trabajar a un nivel más alto de abstracción es mucho más poderoso y productivo. Además, sus modelos superan las tecnologías (por lo que aún tiene algo cuando su primer idioma/plataforma se vuelve obsoleta y puede usarla para su solución de próxima generación). Otra ventaja clave alegada es que gran parte de la repetición y el "trabajo gruñido" pueden generarse. Una vez que la computadora entiende la semántica de su situación, puede ayudarlo más.

Algunos afirman que este enfoque es 10 veces más productivo, y que es del modo todos construiremos el software en 10 años.

Sin embargo, esto es solo teoría. Me pregunto cuáles son los resultados cuando la goma se encuentra con la carretera. Además, la versión "oficial" de MDA es del OMG, y parece muy pesada. Se basa en gran medida en UML, que puede considerarse bueno o malo dependiendo de a quién le preguntes (me inclino por "malo").

Pero, a pesar de estas preocupaciones, es difícil discutir la idea de trabajar en un nivel más alto de abstracción y "enseñar" a la computadora a entender la semántica de su problema y solución. Imagínese una serie de modelos ER que simplemente expresan la verdad, y luego imagine usarlos para generar una porción significativa de su solución, primero en un conjunto de tecnologías y luego en otro conjunto de tecnologías.

Entonces, Me encantaría saber de personas que realmente están haciendo MDA en este momento ("oficial" o no). ¿Qué herramientas Estas usando? ¿Cómo está funcionando? ¿Cuánta promesa teórica ha logrado capturar? ¿Ves un verdadero aumento de efectividad de 10 veces?

Answer 1

Lo intenté una vez. Aproximadamente a la mitad del proyecto, me di cuenta de que mis modelos estaban irremediablemente desfasados ​​de mi código y eran tan complejas que mantenerlas al día era prohibitivo y me ralentizaba.

El problema es que el software está lleno de casos extremos. Los modelos son excelentes para capturar una imagen más grande, pero una vez que comienzas a codificar realmente la implementación, sigues encontrando todos esos casos extremos y en poco tiempo te das cuenta de que el modelo es demasiado granular y tienes que elegir entre mantener el modelo u obtener algún código escrito. Tal vez la generación repetitiva sea un beneficio para comenzar pero luego los beneficios desaparecen rápidamente y descubrí que tuve una caída drástica en la productividad. Los modelos finalmente desaparecieron de ese proyecto.

Answer 2

La falta de respuesta a esta pregunta es algo siniestra ... tal vez voy a dejar que Dijkstra lo coloque.

... Porque las computadoras aparecieron en una década cuando la fe en el progreso y salubridad de la ciencia y la tecnología era prácticamente ilimitada, que podría ser conveniente recordar que, en vista de sus objetivos originales, los esfuerzos científicos de la humanidad sobre, por ejemplo, el últimos cinco siglos han sido una falla espectacular .

Como todos ustedes recuerdan, la primera y principal objetivo fue el desarrollo del elixir que le daría el que bebió la eterna juventud. Pero desde no hay mucho sentido en la pobreza eterna , el mundo de la ciencia rápidamente se embarcó en su segundo proyecto, a saber. la piedra filosofal que le permite hacer la mayor cantidad de oro que necesita.

...

La Búsqueda del lenguaje de programación ideales y el ideal hombre-máquina interfaz que haría que la crisis del software derrite como la nieve al sol tenido -y todavía tiene!- todas las características de la búsqueda del Elixir y la piedra. Esta búsqueda recibe un fuerte apoyo de dos lados, en primer lugar, del hecho de que el realización de milagros es lo mínimo que se puede esperar de computadoras, y en segundo lugar de la respaldo financiero y político de una sociedad que tenían siempre pidió el Elixir y la Piedra en primer lugar.

Dos grandes flujos pueden ser distinguidos, la búsqueda de la Piedra y la búsqueda del Elixir.

La búsqueda de la Piedra se basa en suponiendo que nuestras "herramientas de programación " son demasiado débiles. Un ejemplo es , la creencia de que los lenguajes de programación actuales carecen de las "características" que necesitamos. PL/I fue uno de los más espectaculares posibles piedras producidas. Todavía recuerdo la anuncio en Datamation de 1968, en la que un sonriente Susie Mayer anuncia en color que ha resuelto todos sus problemas de programación por el cambio a PL/I. Era demasiado previsible que, unos años más tarde, la pobre Susie Mayer ya no sonreiría. No hace falta decir decir, la búsqueda continuó y en el momento oportuno vez una piedra futura era producida en forma de Ada (detrás de la Cortina de Hierro se refiere perceptivamente como PL/II). Incluso la astrología más elemental para principiantes es suficiente para predecir que Ada no será la última piedra de este tipo.

...

Otra serie de piedras en forma de "herramientas de programación" se produce bajo la bandera de "software la ingeniería", que, al pasar el tiempo, ha tratado de sustituir intelectual disciplina por disciplina de gestión a en la medida en que ahora ha aceptado como su carta "Cómo programar si usted no puede".

Answer 3

Estoy haciendo mi propia investigación independiente en el área de Desarrollo de Software Basado en Modelos desde 1999. Finalmente, desarrollé una metodología de modelado genérico en 2006 que etiqueté ABSE (Atom-Based Software Engineering).

Así, ABSE se acumula en dos aspectos fundamentales:

• programación se trata de la descomposición problema
• Todo se puede representar en un árbol

Algunos ABSE características:

• Puede soportar todas las demás formas de ingeniería de software, desde el tradi tional métodos orientados a archivos hasta desarrollo basado en componentes, programación orientada a aspectos, modelado específico de dominio, líneas de productos de software y fábricas de software.

• Es lo suficientemente genérico como para aplicarse a software empresarial, integrado, juegos, aviónica, internet, cualquier dominio de hecho.

• No es necesario ser un científico espacial para utilizarlo de forma efectiva. ABSE es accesible para el "mero desarrollador mortal". No hay complejidad como la que se encuentra en las cadenas de herramientas oAW/MDA/XMI/GMF/etc.

• Su metamodelo está diseñado para admitir la generación de código 100% del modelo. No es necesario un viaje de ida y vuelta. La mezcla de código personalizado/generado es directamente compatible con el metamodelo.

• El modelo se puede manipular al mismo tiempo. Se pueden aplicar flujos de trabajo y control de versiones (se necesita soporte de herramientas).

Puede sonar como si fuera en el lado utópico, pero en realidad me salió de la fase de investigación y ahora estoy en la fase de ejecución de un IDE que pone todo lo anterior en la práctica. Creo que tendré un prototipo básico listo en unas pocas semanas (hacia finales de abril). El IDE (llamado AtomWeaver) se está construyendo a través de ABSE, por lo que AtomWeaver será la primera prueba de concepto de la metodología ABSE.

Por lo tanto, esto no es MDA (afortunadamente!), Pero al menos es un enfoque muy manejable. Como el inventor de ABSE, comprensiblemente me entusiasma, pero estoy seguro de que el desarrollo de software impulsado por modelos recibirá un impulso en 2009.

Estén atentos ...

Answer 4

Software Development Model-Driven sigue siendo un área de nicho, pero hay casos de estudio publicados y un creciente cuerpo de otra literatura que muestra el éxito sobre los métodos de codificación manual.

La MDA de OMG es solo un enfoque, otras personas muestran éxito utilizando lenguajes específicos de dominio (que no usan UML para modelar).

La clave es generar código a partir de los modelos y actualizar su generador si no está generando lo que desea, no modificar su código. Las herramientas especializadas para ayudarlo a hacer esto han existido durante años, pero el interés en este enfoque ha crecido durante los últimos cinco años más o menos debido al avance de Microsoft en esta área y a través de proyectos de código abierto como openArchitectureWare en el mundo de Eclipse.

Ejecuto un par de sitios: www.modeldrivensoftware.net y www.codegeneration.net donde puede obtener más debates, entrevistas, artículos y opciones de herramientas sobre estos temas.