¿Por qué todavía no estamos haciendo un desarrollo basado en modelos? [cerrado]

Soy un verdadero creyente en Model Driven Development, creo que tiene la posibilidad de aumentar la productividad, la calidad y la previsibilidad. Al mirar MetaEdit, los resultados son sorprendentes. Mendix en los Países Bajos está creciendo muy muy rápido y tiene excelentes resultados.

También sé que hay muchos problemas.

• versionado de generadores, plantillas y framework
• proyectos que simplemente no son adecuados para el desarrollo impulsado por modelos (no hay suficiente repetición)
• riesgos más altos (cuando el primer proyecto falla, tiene menos resultados de los que tendría con un desarrollo más tradicional)
• etc.

Pero aún así, estos problemas parecen solucionables y los beneficios deberían superar el esfuerzo necesario.

Pregunta : ¿Cuáles considera que son los mayores problemas que hacen que ni siquiera considere el desarrollo basado en modelos?

Quiero usar estas respuestas no solo para mi propia comprensión, sino también como una posible fuente para una serie de artículos internos que planeo escribir.

No hay un martillo dorado. Lo que funciona bien en un dominio es bastante inútil en otro. Existe cierta complejidad inherente en el desarrollo de software, y ninguna herramienta mágica lo eliminará.

También se podría argumentar que la generación de código solo es útil si el lenguaje en sí (o el marco) no es lo suficientemente alto como para permitir poderosas abstracciones que harían MDD relativamente inútil.

¡Interesante pregunta! Admito que no soy un fanático, pero luego intenté usar el desarrollo impulsado por modelos varias veces en proyectos que se ajustan a algunos de los problemas que acaba de plantear.

Aquí está mi lista de razones:

• curva de aprendizaje: las herramientas de modelado han evolucionado tan rápidamente que me cuesta encontrar ingenieros que comprendan profundamente la herramienta. Todavía encuentro que eres tan bueno como tu herramienta de modelado. Es cierto que muchos de los problemas a continuación podrían rastrearse hasta este problema: siempre que piense que una herramienta es demasiado limitante, es posible que no la conozca lo suficientemente bien.
• Demasiado estructurado: personalmente, he estado en situaciones en las que descubrí que la herramienta de modelado simplemente estaba demasiado estructurada para permitirme describir todo lo que necesitaba describir. Y una vez que cambio a dibujar algunas partes del modelo fuera de la herramienta, las cosas se deterioran rápidamente a medida que las personas comienzan a desplazarse fuera de la herramienta para encontrar la información.
• Costo de ajustar la herramienta: cada vez que he intentado autogenerar código, terminé reelaborando manualmente el código una vez que veo lo que la herramienta pensaba que era correcto. Sé que después de algunas vueltas, este problema disminuye, pero eso significa que tienes que sobrevivir a las primeras rondas. En general, he sentido que estábamos jugando Whack a mole - hacer modelo -> generar código -> corregir código -> actualizar modelo -> corregir modelo, enjuagar y repetir.
• Gestión de la configuración del modelo: dado que el modelo describe grandes partes del proyecto, en algún nivel el modelo CM será más transversal que el código construido. La compartimentación de los archivos de modelado es un arte en sí mismo: hazlo mal y a menudo terminas con un punto muerto del desarrollador o modelos obsoletos a medida que la gente se da por vencida y sigue el código.
• tiempo de comercialización: he experimentado problemas definitivos en una situación en la que la necesidad de un software operativo era urgente. Si el proyecto y el equipo son lo suficientemente pequeños, no veo ninguna razón para perder el tiempo en una herramienta de modelado cuando se puede pasar el tiempo codificando y probando. No todos los proyectos son lo suficientemente grandes como para requerir tal inversión.
• Costo de la falla: cuando he visto que los proyectos se escapan de las herramientas de modelado, es debido al alto costo de la falla: para usar las herramientas, necesita que todos los desarrolladores se involucren. Esa es una gran inversión en capacitación y aprendizaje práctico, y un error muy costoso si alguien ha configurado mal el modelo. Mi experiencia es que puede tomar dos o tres lanzamientos para obtener el modelo correcto, por lo que muchos proyectos no sobreviven a los errores de modelado lo suficiente como para darse cuenta de los beneficios.

Ya se ha citado, pero No Silver Bullet aborda el punto bastante bien:

La esencia de una entidad de software es una construcción de conceptos entrelazados: conjuntos de datos, relaciones entre elementos de datos, algoritmos e invocaciones de funciones. Esta esencia es abstracta en el sentido de que tal construcción conceptual es la misma en muchas representaciones diferentes. Sin embargo, es muy preciso y rico en detalles.

Creo que la parte difícil de crear software es la especificación, el diseño y la prueba de esta construcción conceptual, no el trabajo de representarlo y probar la fidelidad de la representación. Todavía cometemos errores de sintaxis, para estar seguros; pero son difusos en comparación con los errores conceptuales en la mayoría de los sistemas.

Si esto es cierto, crear software siempre será difícil. Inherentemente no hay bala de plata.

Más tarde, Brooks señala lo siguiente sobre el concepto de "programación automática":

Durante casi 40 años, las personas han estado anticipando y escribiendo sobre "programación automática" o la generación de un programa para resolver un problema a partir de una declaración de las especificaciones del problema. Algunos escriben hoy como si esperaran que esta tecnología proporcione el próximo avance.

Parnas implica que el término se usa para glamour, no para contenido semántico, afirmando: "En resumen, la programación automática siempre ha sido un eufemismo para programar con un lenguaje de nivel superior al que estaba disponible actualmente para el programador".

Argumenta, en esencia, que en la mayoría de los casos es el método de solución, no el problema, cuya especificación debe ser dada.

Básicamente, argumentaría que MDD es solo otro eufemismo para programar con un lenguaje de nivel superior al que estaba disponible anteriormente.

Eso no quiere decir que la programación en un lenguaje de nivel superior no pueda ayudar, de hecho a menudo sí puede. Pero la esencia del problema sigue siendo el mismo: no importa cuán grande o herramienta de una forma en la lengua de un bien que se están utilizando, al final del día se necesita pensar a través de todos los problemas y resolver los problemas. Lo mejor que puede hacer cualquier herramienta o proceso es eliminar el "fuzz" para que pueda centrarse en el tema importante, que es, como dijo Brooks, "la especificación , diseño y prueba de esta construcción conceptual ".

Porque no toda la programación está orientada a objetos, lo que todas las herramientas MDD parecen esperar. UML en sí mismo se basa en la presunción de objetos. Claro que puede usar diagramas de secuencia para modelar funciones, pero muchas veces eso es torpe.

Porque hay programadores como yo que obtienen más progreso y resultados de TDD que MDD.

¡Porque Modelado! = Programación.

Porque el costo / beneficio era demasiado alto en el lado del costo y no suficiente en el lado del beneficio. Esto probablemente ha cambiado desde la última vez que vi MDD, en ese entonces se le exigiría que pagara $ 6000 / asiento (USD) por una herramienta que sería moderadamente capaz de MDD.

Porque un modelo que describe suficientemente una función para generar el código ya no es útil como modelo.

Porque hay programadores como yo que solo usan modelos de alto nivel y luego resuelven los detalles con código. Usted ve las cosas de manera diferente en el código que en el software de modelado.

Esas son algunas de las razones por las que personalmente no hago MDD. He estado expuesto a él, pero nada ha sido capaz de convertirme. Quizás soy demasiado vieja escuela. Quizás soy una escuela demasiado nueva (sea lo que sea). Simplemente no es una herramienta que he podido hacer pagar por sí mismo.

Microsoft / Apple / Google no lo está presionando :)

El tipo de desarrollo que se populariza tiene mucho que ver con las herramientas, el respaldo y la evangelización. Es muy difícil romper con algo sin tener un gran respaldo (Ruby on rails quizás sea la excepción, pero aún es pequeño en comparación con Java / C # / Python)

Debido a una ley simple que afectó a todas estas herramientas de modelado, ya sabes, CASE, UML y demás:

Entrar entre un programador y su código es muy costoso.

Si lo hace, debe crear un compilador / intérprete adecuado, los generadores de código resultan en un flujo de trabajo terrible y una retroalimentación terrible para el programador (mensajes de error y tal).

Una de las grandes ideas del diseño impulsado por dominio es que los modelos deben estar en código, no en algo externo al código.

En última instancia, la pregunta es: ¿por qué sus modelos no se ajustan al código? Si está realizando un desarrollo integrado y está atascado con C o necesita generar código para diferentes plataformas, la generación de código puede valer la pena. Para todos los demás, un lenguaje de programación más potente y un mejor diseño de código suelen ser mejores que diseñar el código en algo distinto del código.

• Parece una molestia gigantesca para muy poco beneficio.
• Siempre parezco estar cenando con casos extremos y cosas extrañas, las cosas mágicas nunca parecen funcionar bien.
• OO no es una bala de plata; agregar una metodología de generación de software a OO no lo hace plateado.

Pero no me gustan las soluciones empresariales en general.

Tuve la discusión y me encantaría hacer MDA, pero el mayor inconveniente es el soporte de herramientas por ahora. Estoy usando una derivación de MDA que me gusta llamar "Evaluación del modelo de tiempo de ejecución", pero más sobre eso más adelante.

Los inconvenientes de la MDA son, como sé:

• Falta de soporte de refactorización: supongamos que quiero modelar las entidades de mi modelo de datos con MDA (caso de uso típico No. 1). Si tengo mi modelo, digamos, un diagrama UML, y lo cambio, nada de mi código cambia con él (al menos las clases generadas), y en lugar de tener una aplicación que funcione con atributos mejor nombrados, obtengo un Muchos errores tengo que corregir manualmente.
• Falta el soporte de depuración: por lo general, las traducciones del modelo al código se realizan teniendo a mano un lenguaje de transformación. Por lo general, esto no sería un problema, pero cuando depuramos, de manera óptima no deberíamos preocuparnos por el código que generamos, y un depurador debería ingresar al modelo de transformación. En cambio, entra en el código generado y, como todos sabemos, las transformaciones deberían verse bien, no el código generado. Okey, podemos imprimirlo bastante, pero en un mundo óptimo el código generado es un artefacto compilador, y nunca debería tener que abrirse en un editor para una sesión de depuración (podría vivir con él, y este argumento es un poco teórico, pero es una razón contra MDA)
• Los modelos codificados son fáciles: en otros ejemplos, el modelo podría modelar algún aspecto de dominio y luego se compila en código. Sí, es MDA, pero la mayoría de los modelos MDA son solo archivos de configuración sofisticados, que podrían manejarse fácilmente en tiempo de ejecución.
• Las transformaciones son difíciles de probar: si utiliza transformaciones en un IDE especializado, las realiza el "compilador" de IDE. Pero las transformaciones deben verse como parte del código de la aplicación y, como tal, también deben someterse a los requisitos de prueba y cobertura de código de la aplicación.

Lo que prefiero actualmente es la "Evaluación del modelo de tiempo de ejecución" (si alguien conoce un nombre aceptado para esto, por favor, ilumíneme). Mis entidades se almacenan en clases Java normales, y todo lo que necesito para "modelar" se realiza mediante anotaciones que leí al inicio de la aplicación. No se necesitan transformaciones, fue un poco difícil obtener mi metamodelo correcto.

Todo lo demás se hace con archivos de propiedades o XML para datos jerárquicos. Si tiene un modelo, siempre es jerárquico, por lo que no hay nada que pueda modelar que no pueda expresar con XML. Y si necesita un editor de modelos especial, que probablemente también tendrá que escribir, también puede crear un editor que incluso funcione en el tiempo de ejecución de la aplicación y haga que la aplicación sea más configurable que todo lo que podría modelar.

Siento que la mayoría de las personas que usan No Silver Bullet de Fred Brooks para explicar por qué las personas no están haciendo MDD están perdiendo el punto que Brooks hace. Claro, la conclusión final es que la complejidad intrínseca real en el desarrollo de software nunca desaparecerá, por lo que MDD no resolverá esto.

Pero una razón por la que Brooks incluso discute esta complejidad intrínseca es para compararla con la gran cantidad de tiempo que normalmente pasamos peleando con idiomas, bibliotecas y herramientas, es decir, no lidiar con la complejidad intrínseca del problema que estamos tratando de resolver. Entonces, aquí es exactamente donde MDD brilla: cortando toda la confusión y creando un lenguaje, modelo u otro formalismo a medida para lidiar con la complejidad real en cuestión.

Desde esta perspectiva, No Silver Bullet es una excelente razón para invertir en MDD. Es decir, si no fuera por el problema que creo obstaculiza la adopción de MDD: el desarrollo real de un entorno basado en modelos que le permita concentrarse por completo en la complejidad intrínseca del problema que está tratando de resolver es mucho más difícil que solo resolviendo el problema en un lenguaje de propósito general directamente. Principalmente porque las herramientas MDD existentes son extremadamente complejas.

Compárelo así: es mucho más fácil escribir un programa en C que escribir un compilador de C. En lugar de simplemente resolver un problema y tratar el problema en un lenguaje de propósito general, crear un entorno MDD para otros desarrolladores requiere que básicamente escriba un programa que resuelva todos los posibles problemas relacionados con el problema en el espacio del problema por adelantado. Eso es bastante desafiante.

Que yo sepa, MDE y MDA no abordan suficientemente las necesidades del desarrollador del controlador incorporado. Ciertamente, los modelos se pueden usar para describir un sistema, pero no creo que el desarrollador integrado esté listo para confiar en el modelo para ofrecer el mejor código fuente, o incluso el correcto.

Existen varios complementos para Eclipse que permiten a un desarrollador usar el modelo para crear / actualizar el código Java o el código Java para crear / actualizar el modelo. Esto parece una herramienta útil. Desafortunadamente, todo mi desarrollo se realiza en ANSI / ISO C, y no hay complementos, que yo sepa, que me permitan hacer lo mismo.

Además, ¿cómo puede un desarrollador instruir al modelo para que implemente el código como un HSM controlado por eventos, o algún otro patrón de diseño, sobre cualquier otro patrón de diseño (o antipatrón)? Si el código se actualiza manualmente para usar un patrón de diseño desconocido, ¿puede el modelo representarlo con precisión?

¿Cómo implementas esas funciones que no encajan en un modelo?

Respuesta corta ... porque el modelo dirigido a menudo está relacionado con la generación de código y el código es frágil; lo que necesitamos es la eliminación de código y el modelo impulsado es seguramente el camino a seguir.

Algunos han rechazado la pregunta argumentando que no hay un martillo dorado y que el desarrollo de software es intrínsecamente complejo.

Estoy totalmente de acuerdo con ellos en que no hay un martillo dorado, ¡pero no creo que el modelo conducido sea una búsqueda de martillos dorados o balas de plata!

Me gustaría ir más allá con la complejidad; Hay dos tipos de complejidad, uno que llamo complejidad orgánica o natural, complejidad que es inherente al negocio y sus procesos, pero también tenemos complejidad ceremonial.

Complejidad que se desliza en el sistema instrucción por instrucción, día tras día. La complejidad ceremonial (complejidad innecesaria) surge esencialmente de la manipulación incontrolada del código técnico con el código orientado a los negocios, pero también de la falta de estructura y uniformidad en el sistema.

Hoy, toda la complejidad que obsesiona el desarrollo de sistemas de información y causa fallas y cintura es una complejidad ceremonial; complejidad que puede ser eliminada.

La complejidad ceremonial es desperdicio, desperdicio causado por el código, menos valor, cambio de código adverso e invariante; código que debe reducirse a su mínimo estricto.

¿Como hacer eso? ¡Fácil, simplemente no lo escriba, y no lo genere, en primer lugar!

Código técnico necesario e invariable; código que se usa para leer / escribir, mostrar, comunicar ... Ahí es donde entran los modelos, al describir la estructura lógica de los datos, agregaría de una manera relacional, los modelos pueden permitir el manejo genérico de la lectura / escritura estándar, la visualización y la comunicación de datos.

Es como un sistema operativo, no lo reescribe para cada proyecto que utilizas. Entonces, lo que se necesita es un motor técnico que maneje aspectos invariables del software dado un modelo. Lo llamo un motor AaaS (Arquitectura como servicio).

En cuanto al código innecesario, bueno, es un código innecesario, por lo que podría dejarlo sin escribir.

Eso nos deja con el código necesario orientado al negocio que debe escribirse, los datos necesarios orientados al negocio que deben diseñarse y la interfaz de usuario necesaria y la experiencia que deben diseñarse e imaginarse.

Al eliminar el código frágil, podemos adoptar Arquitectura como servicio, un nuevo paradigma para el desarrollo de software basado mucho más en el modelado y el diseño que en el código.

Creo que hay varias razones, pero una es segura de que MDD no está en el plan de estudios de las universidades. Normalmente, el más cercano es un curso que enseña modelado y allí los modelos permanecen como bocetos (sin verificación, generación de código, depuración a nivel de modelo). Este curso de "modelado" a menudo también presenta UML y los estudiantes están desconcertados por qué aprender una notación tan grande y compleja cuando el valor de los modelos creados es bajo.

Compare esto con otro campo de la ingeniería, como los desarrolladores de hardware integrado o los ingenieros de control, donde los estudiantes obtienen una experiencia bastante diferente. Con herramientas como Simulink o Labview, los estudiantes pueden dibujar un modelo y luego te genera el código, o al menos puedes ejecutarlo en simulación.

En el pasado, las universidades enseñaban compiladores y analizadores, pero ahora deberían enseñar cómo hacer generadores, implementar DSL, etc.

El desarrollo dirigido por modelos no tiene sentido porque es un enfoque de arriba hacia abajo para codificar. ¡Es imposible crear una aplicación en ejecución completa solo desde un modelo y, por lo tanto, MDD es inútil!

Lo que hago es usar solo UML en un nivel más alto de abstracción para crear el esqueleto de mi aplicación. Me refiero a crear paquetes, clases, etc., luego comenzar a codificar inmediatamente en lenguaje Java.

Descubrí que la sincronización en vivo con herramientas como Togethersoft, Omondo fue realmente útil cuando comencé a modelar por primera vez en 2004. Omondo introdujo recientemente una nueva etapa que es un tipo de mapeo entre Java, modelo e ID de base de datos. Realmente poderoso y funciona bien en mis proyectos.

Mis diagramas UML me ayudan ahora a acelerar mi proyecto y ya no son inútiles :-)

MDD agrega otro paso al proceso de desarrollo, que es una desventaja en situaciones donde no hay un buen modelo y la primera solución parcial impredecible o casi rota del mercado podría ganar la mayoría de las canicas.

Ha sido muy acertado tener modelos de procesos de negocio ejecutables. En teoría, no necesitarías programadores para eso. La práctica muestra que con MDE, hacer que el modelo real funcione es tan complicado como escribir código.

Diría que para un desarrollador experimentado sería mucho más fácil completar las clases generadas a partir de UML, que molestarse con, por ejemplo, ExecutableUML. Por otro lado, para ExecutableUML necesita una gran cantidad de conocimiento de informática, por lo que no puede contar con que el gerente de negocios lo cree por sí mismo. En teoría, él simplemente combinaría bloques listos (clases), pero en realidad el "pegamento" es lo que causa problemas.

Además, la utilidad de MDE se limita a los sistemas con gran cantidad de reutilización de componentes.

MBSE - Ingeniería de software basada en modelos es el término más pertinente.

Poniendo el tema de las diversas herramientas que son en efecto soluciones puntuales, MBSE requiere un flujo de trabajo de proyecto diferente. El DSML (lenguaje de modelado específico del dominio) debe estar en el nivel de abstracción requerido para comunicar de manera efectiva los requisitos para su revisión con las partes interesadas. Entonces necesita transformar el modelo a través de niveles cada vez mayores de refinamiento para eventualmente generar código.

Cuando tiene el DSML y los procesos de transformación / generación implementados completa y correctamente, la generación de artefactos tiene un costo muy bajo. Pero hasta que llegue a esa etapa de herramientas depuradas, es muy doloroso.

La mayoría de las historias de éxito de MDD están en el área de Ingeniería de línea de productos (PLE), donde se genera una sucesión de productos similares utilizando herramientas establecidas. Por supuesto, muchos de los generadores de código Java son versiones realmente simplificadas de MDD. Algo de XML y código generado.

Tu escribiste:

También sé que hay muchos problemas ... proyectos que simplemente no son adecuados para el desarrollo impulsado por modelos (no hay suficiente repetición)

Si su código es repetitivo, entonces ha elegido un lenguaje de programación pobre o lo está usando mal. Con mejores idiomas, no hay necesidad de repetir. Considere la biblioteca Ruby Active Record. Las tablas de la base de datos se crean escribiendo migraciones. No es necesario repetir la definición del esquema en ningún otro lugar. No tiene que definir una clase con miembros de datos correspondientes a las columnas de la tabla. Una sola línea de código conecta una clase a una tabla.

Veo el desarrollo impulsado por modelos como una solución compleja e ineficiente para lenguajes de programación débiles.