Comentábamos el otro día, largo y tendido, el amigo @pmolinam y yo, con intervenciones de @jmvara, sobre pros y retos del diseño software. Básicamente, hablábamos, dentro de lo que nos permitían los 140 caracteres del twitter, del papel que ocupa, o debiera ocupar, el diseño.
Todo ello arrancó cuando @jmvara empezó argumentando que no coincidía con aquellos que dicen que el único diseño valido es el código (añado ahora, en aquella conversación twitter se me pasó hacerlo, que ese es, por cierto, un pensamiento muy agilista… «Don’t worry about design, if you listen to your code a good design will appear»).
Los comentarios a favor de tener un Diseño como pieza clave y fundamental del desarrollo, y claramente separado del código, argumentaban principalmente que esto permite observar el sistema a un nivel de abstracción mayor, y que si el lenguaje de descripción de ese diseño es lo suficientemente rico… el código puede generarse automáticamente, por lo que, en ese escenario, mantener el código como pieza clave del desarrollo no tiene tanto sentido, lo importante es mantener el diseño, ya que desde el mismo diseño se puede generar el código cuando se quiera.
Para los más introducidos en el tema, en esto se basa el MDD (Model Driven Development), estrategia que persigue la generación automática del código desde especificaciones de alto nivel o lenguajes (llamados domain-specific languages o DSLs).
Mis comentarios, más escépticos al respecto. Por un lado, mi experiencia, despues haber evaluado decenas de desarrollos software, me dice que estudiar un diseño no es algo que te de mucha seguridad, porque demasiadas veces este no coincide con el código, es decir, con lo que hay en producción. Por lo que si quieres saber de verdad cómo es el software tienes que mirar el código.
Comentaba Pedro, que lo anterior es cierto, pero porque se basa en que el diseño está en soporte papel. Pero que si el diseño está en una especificación formal, lo anterior puede verificarse, saber si hay diferencias entre el diseño y el código. En este caso, como él comentaba, el código es sólo un medio para ejecutar el diseño.
Yo tengo mis dudas al respecto. Porque en sistemas y desarrollos software con decenas de versiones y decenas de instalaciones en cliente, la anterior gestión no es trivial. Un “mapeo one to one” diseño código, como comentaba Pedro, requiere que cada vez que se cambie el diseño se actualice el código… y cada vez que alguien toque el código se actualice el diseño formal. De manera más general mis dudas vienen de cómo gestionar la trazabilidad bidireccional diseño – código y el control de versiones de ambos elementos.
Respecto al problema anterior, Pedro comentaba deberían evitarse, o prohibirse, prácticas como tocar el código sino es por medio de un cambio previo en el diseño. En mi opinión, en desarrollos grandes, empresas grandes, muchas versiones diferentes del mismo producto en producción, personal externo, etc., es demasiado riesgoso confiar en que nadie va a tocar el código, incluso podría pensar si no es incluso menos productivo el no poder hacerlo.
Y ahí lo dejamos. Por lo menos, aunque no arreglemos el mundo, el debate nos ha servido como excusa para continuarlo tomando un café.
Y vosotros ¿Qué opináis de este tema?
Primera vez que me tocó hacer una gestión Ágil en una empresa... año 2001. Desde entonces he trabajado en, o para, más de 90. Y he formado a más de 2000 alumnos.
También soy profe de la Universidad Rey Juan Carlos.
- Las 3 matrices de priorización Ágil - 19 octubre, 2023
- Etapas del Agile Product Management - 12 octubre, 2023
- Agile Product Management: DINÁMICA «Árbol Solución Oportunidad» + «Valores Esperados» - 5 octubre, 2023
Pingback: Bitacoras.com
hola
interesante debate. sin ser experto en el tema ¿creeis que se puede llegar a generar código desde un diseño? sí fuese así no habría que tener programadores no?
saludos
saludos
(sorry for replying in English, Espanol is at best a read-only language for me)
Instead of prohibiting direct handling of generated code, I think it works better if:
1) the generated code does not end up in the same location as hand coded code.
2) the generated code is not stored in the SCM (for Java/Maven-heads: ends up in the target directory)
3) the generated code is inaccessible (say, deleted after compiled), or non-trivial to access (say, packaged inside a zip file, so it is still readable but not modifiable)
On the general issue of code vs. design – I am all for MDD. But if MDD is not being adopted, I agree with the idea that the code is place where the design is described.
Igual no haría falta que el mapeo fuese bidireccional. Habría que separar el código generado de manera automática por el código que se ha tenido que implementar a mano (algoritmos específicos, optimizaciones, etc), por medio, por ejemplo, de librerías. Así cuando tocases el diseño, no sobreescribiría lo modificado a mano. Y también se podría asociar desde el diseño estas librerías para que lo generase con las librerías integradas.
Así, los cambios en estas librerías que serían de código solamente no impactarían tanto en el diseño.
La verdad es que así tiene buena pinta. Pero creo que estos generadores aún no existen. ¿No?
Si usas un nivel de especificación de diseño como comenta Pedro, en realidad estarías creando código, programando. Sólo que un lenguaje de programación más abstracto.
Luego el código es el diseño.
Esto pasa por ejemplo en los ESBs, pero en otros tipos de aplicaciones no he visto herramientas que lo permitan porque siempre hay que añadir algo que no trae la herramienta.
Quizá nos estamos fijando más en los síntomas que en la causa, es decir, descartamos el diseño porque en la práctica no lo estamos manteniendo. Tenemos versiones de código en producción y versiones de diseño en nuestros repositorios de documentación que no tienen correspondencia. Bueno, lo mismo nos pasa con los requisitos. ¿Debemos abandonar el mantenimiento tanto de un diseño como de los requisitos por ello? ¿El problema es de la propia naturaleza del diseño o del proceso de desarrollo guiado por un diseño?
No discuto que pueda haber prácticas válidas no dirigidas por el diseño, pero desde luego el tener una mala política de SCM (que se refleja en esos síntomas de los que hablamos) no me parece el razonamiento más correcto para descartar el concepto de diseño por entero. Y, por supuesto, lo mismo aplica para la gestión de requisitos.
Creo que partimos de una práctica muy extendida de no entender y, sobre todo, no implementar una política de SCM, no digo ya una «buena» política de SCM, digo una cualquiera.
Una buena trazabilidad nos lleva a tener ítems de configuración mantenibles y todo ello es parte de nuestra práctica de SCM.
Creo sinceramente que a nivel práctica, en el 90% ó más de los casos, la expresión «el diseño está en el código», esconde un tema más profundo, termina siendo una mera excusa.
A nivel teórico, y cuando digo teórico, me refiero a ciertas prácticas que no dudo que haya quien las lleve a cabo correctamente, no entro a discutir si puede ser válido no tener un diseño formal. Es más, estoy con Paul Clements y la gente del SEI en la práctica de documentar un arquitectura básica donde sólo se documenten los metapatrones como guías tanto para el desarrollador como para el que quiera entender el código. Pero creo que aquí la discusión iba por otros derroteros.
Saludos, hermanos sufridores…
Dos comentarios a vuela pluma, tiempo habrá de profundizar en el tema:
– La opción que Pedro defendía se basa en el uso de DSLs que sirven para generar el código de manera que cualquier cambio o refactorizaciones xo no se haga sobre el código sino sobre el modelo para luego regenerar y obtener el código que refleja el cambio. De hecho pedro ya ha dicho en alguna ocasión (y yo coincido en gran medida) que mantener la bi-direccionalidad modelo-código es muy poco factible. Si quieres cambiar el, producto, cambia el modelo y regenera.
– Efectivamente, en la mayoría de sistemas existentes apenas existen diseños o similares. En mi opinión esto va un poco en contra de las buenas practicas de IS quue entiendo que todo ingeniero deberíamos persiguir. Por otro lado, entiendo que la idea no es cambiar lo que hay, que creo que será muy complicado (o probablemente imposible) pero tratar de que lo que venga se haga mejor.
Bueno, seguimos.
Como siempre, gracias por el esfuerzo de mantener el blog Javier.
Un gustazo leerte y debatir … 🙂
Hola a todos:
Gracias Javier por darle difusión a nuestra improvisada tertulia en twitter. Esto permitirá agregar más opiniones al debate. Y mis disculpas porque me voy a extender un poco, pero creo que puede ser bueno para dar contexto y posicionar mi punto de vista.
Como bien comenta Javier, todos conocemos muchos proyectos donde el análisis si existe, no se parece al diseño de la aplicación, y este a su vez, si existe no se parece a la implementación final que encierra el código. Estos proyectos están como están, tienen la historia que tienen, y los mantenedores si no lo son, son héroes en su mayoría porque no pueden ser considerados de otro modo para luchar día a día contra la bestia e inmensa deuda técnica que heredaron.
Dicho esto, no está de menos en que nos paremos y repensemos como nos gustaría trabajar en los proyectos nuevos donde podamos sentar las bases para tener mejor calidad, todo controlado, el alcance de cambios acotado y podamos dar una mejor calidad: en definitiva aspiremos como ingenieros a vivir mejor, haciendo nuestro trabajo mejor al tiempo que más productivo.
Y en este contexto es donde mucha gente, pero todavía minoría, dentro del mundo de la ingeniera del Software aplicamos MDD (Model Driven Development) para que nuestras penas de desarrollo en el día a día sean menores. Hacemos las cosas de modo diferente, el proceso de desarrollo de software cambia, pero a cambio tiene sus beneficios. Paso a explicar en que consiste:
El objetivo es describir en modelos todo lo que tenga sentido con un mínimo de volumen (modelo de estructura conceptual, workflows, interfaz de usuario, etc.) y derivemos desde el todo lo que tenga sentido para la aplicación: en nuestra experiencia alcanzar un 50% – 80% del código es relativamente fácil para aplicaciones de gestión empresariales. Todo esto no implica que prescindamos de los programadores, al contrario queda un 50% – 20% de la aplicación que hay que seguir haciendo a mano, afinado de acceso a datos, integración con terceras aplicaciones, interfaces de usuario a medida, etc. que es donde los ingenieros aportan su saber hacer diferencial mientras la maquina se ha encargado de la morralla, de todo ese código repetitivo, de poco valor añadido, fuente frecuente de errores, que una maquina puede hacer mejor que nosotros: estoy hablando de: montar la estructura de la aplicación dada una arquitectura empresaria de referencia, generación de tablas, índices, capas de acceso a datos, objetos de negocio, DTOs, workflows, componentes para la interfaz de usuario incluyendo controladores, vistas y modelos.
El foco principal es que, con este enfoque no se intenta generar el 100% y eliminar el trabajo del programador, al contrario, aplicando un enfoque de coste/beneficio se automatiza la parte aburrida y tediosa liberándole de esta tarea. Pudiendo dedicar más tiempo y atención a aquellas partes que son más retadoras y al mismo tiempo motivantes para el desarrollador donde no va a ser rentable nunca crear un generador que remplace al desarrollador. Se trata simplemente de emplear mejores herramientas para la tarea adecuada cuando el coste/beneficio lo justifique, nada más.
La generación de código ha evolucionado mucho en los últimos treinta años y las herramientas y los métodos también.
Como ya comentábamos, y ha salido en los comentarios previos, no abogamos por sincronizar modelo y código en modo bidireccional, ya que la diferencia de abstracción entre niveles hace rápidamente impracticable la ingeniería inversa sin perder detalles. Al contrario, desde la experiencia prefiero un enfoque Forward Engineering donde el código se separa en dos bloques bien diferenciados que todo el equipo conoce, a saber: (A) el código que se puede derivar al 100% de un modelo y (B) el código que es manual, artesano, que extiende sobrescribe y/o usa al proporcionado en (A).
El modelo deriva el código de la parte incondicionalmente (A) ante cualquier cambio en el modelo (este código no se toca por los programadores). Mantenemos el modelo y regeneramos el código, ningún cambio al código es revertido al modelo. Por contra el código en (B) es responsabilidad del equipo y el generador lo respeta. A+B compila junto y pasa test de unidad, de regresión, etc. de modo conjunto.
A nivel personal, me parece un error las metodologías que renuncian al diseño, y se centran todo en el código o se enfocan en los test esperando que el diseño aparezca por si solo, como algo emergente. El diseño tiene valor por si mismo, antes de liarse la manta a la cabeza y ponerse a programar a ciegas, poder comunicarlo a un mayor nivel de abstracción en lugar de tener que ir a desentrañarlo desde el código tiene valor por si solo. En fin, esto es solo una opinión, con las que muchos seguro discreparán, pero es la que tengo. 😉
Lo bueno de este enfoque de Forward Engineering es que el modelo es en gran parte el código. Mirar el diseño no plantea dudas acerca de cuan verdad será frente a la implementación. La correspondencia es 1 a 1. La tranquilidad de que es correcto y conforme a la arquitectura sin errores no tiene precio, ni precedente. Entender lo que hace la aplicación viendo mas diseño y menos código ayuda a entender y mantener los sistemas a un mejor nivel de abstracción, con menos morralla despistándonos alrededor.
Este tipo de cosas existen, no son ciencia ficción, y si Javier me lo permite, ahora es cuando hare algo de publicidad. 😉 Para el que quiera saber más, os paso un enlace a mi blog sobre MDD: http://pjmolina.com/metalevel donde este tipo de enfoques se describen con más detalles. Una conferencia sobre generación de código industrial para que veais que esto se usa en entorno real y no solo es algo académico: http://www.codegeneration.net/cg2012/program.php
y finalmente a una herramienta como ejemplo de esté enfoque en la que trabajamos http://radarc.net por si queréis echar un vistazo a otra forma de enfrentarse al desarrollo de software.
Este cambio de filosofía ante el código pasa realmente por cambiar la concepción de ‘mi código es mi tesoro’ a ‘mi modelo (y mi código manual) es mi tesoro’ y claro esto es duro y difícil de suscribir para aquellos que piensan que el diseño es puramente emergente y que no aporta valor per se.
Un saludo, Pedro J.
Los desarrolladores siempre serán necesarios, pero según mi opinión, y con la estrategia MDD muchos tendran rol mas de integradores que de desarrollador.
En. MDD existen muchas herramientas funcionando. P.EJ Xtext
Les invito que van la presentación sobre MDD http://pgonyan.blogspot.com.es/2012/07/mdd.html
Y que lean a Markus Voelter y MDSD
Hay una herramienta que permite trabajar a nivel de DISEÑO y luego «genera» el codigo en funcion de esta especificacion de alto nivel.
Y ante, cambios en la Especificacion de Diseño, regenera nuevamente la base de datos, la migracion a la nueva version, y los programas correspondientes (en varios lenguajes, arquitecturas posibles, etc)
Esta producto se llama Genexus, den una mirada en http://www.genexus.com
Depende del entorno. Estuve un año en una aplicación de seguros con 150 personas donde usábamos una versión casera de AndroMDA a partir de un diseño en ArgoUML para generar CRUD, páginas incluidas. El diseño generaba el esqueleto, y cambiar el diseño implicaba cambiar el UML y regenerar el código. Esto fue (y creo que el proyecto sigue) java, hibernate, spring. O sea, una iteración más de la arquitectura más típica que puedes tener en Java.
Ahora voy por mi segunda empresa pequeña donde creamos un producto, y en la que tengo que hacer cosas que generalmente no tengo ni idea como hacer antes de empezar (estilo http://ninjasandrobots.com/you-need-some-experience). Creo que lo estoy reescribiendo todo *al menos* una vez.
Este es el otro extremo. Somos pocos, tenemos prisa, esto no es una API, y nadie documenta nada. Pero si conoces las convenciones, usas los nombres apropiados para indicar el uso de construcciones conocidas, puedes llegar muy lejos sin documentación ni diseño. No hablo de proceso, «el plan NO te salvará», hace falta cultura de desarrollo. Si un método no hace una única cosa y puedo hacerle un test de unidad sin esfuerzo, sé que es impresentable, y en cierto sentido estoy defraudando a la gente que trabaja conmigo. Cuando leía código que no entendía y no había comentarios era frustrante. Ahora sí me entero, y veo que los comentarios a veces ayudan y otras están de más.
Así que ambas cosas son posibles, o al menos yo las he visto en acción con buenos resultados. Depende del entorno.
Es un buen post, pero creo que la palabra Diseño (sin apellido) confunde el debate:
– Diseño de Alto Nivel: Normalmente denominado Arquitectura y creo que sí sería un topic de acalorada discusión usando el título del post
– el Diseño Detallado: sí que se puede hacer directo-inverso del código; pero en formato diferente del código aporta poco o vale sólo para cosas muy puntuales (i.e. un diagrama de clases puede ayudar a diseñar una refactorización)
– el Diseño Web: es medio broma, pero muchas veces se confunde también y tiene oros matices.
– el Diseño Industrial: en estos entornos el Diseño es lo que en Ingeniería de Software solemos llamar ‘Especificación de Requisitos’ y no hay traductores directos, salvo para cosas específicas (i.e. CAD).
Totalmente de acuerdo con la postura expresada por Pedro.
El enfoque MDD, a efectos prácticos y desde el punto de vista del desarrollador de código, nos permite focalizar el esfuerzo en lo que realmente aporta valor del desarrollo del producto: el código específico del contexto del problema (p.ej.: algoritmos eficientes, funciones innovadoras, el dominio de negocio del cliente), liberándonos de tener que re-programar cada vez el código de acceso a datos, las validaciones de interfaz, los estilos de navegación, el control de errores, etc.
Por otro lado, el trabajar con modelos en lugar de directamente con el código, nos permite ver más fácilmente «el bosque», y así identificar más rápidamente relaciones ocultas entre elementos, posibles incongruencias o debilidades del código. Para ello, recomiendo ver la ponencia de Eoin Woods sobre «Architecting in the Gaps» (http://www.infoq.com/presentations/Architecting-in-the-Gaps).
Sobre la trazabilidad modelocódigo, en la actualidad sólo se soporta una única dirección: Modelo->Código (no es bidireccional). Los cambios en el código no se trasladan al modelo, y si se cambia el modelo, se regenera el código. Para evitar la pérdida del código desarrollado manualmente, éste se separa del código generado automáticamente. Por ejemplo, en .NET esto se soporta fácilmente a través del uso de Clases Parciales, aunque también se puede soportar a través del uso de mecanismos como la herencia o el uso de interfaces.
Sin embargo, prototipos en fase de investigación (aunque posiblemente en determinadas empresas de cierto tamaño ya se están incorporando) permiten mantener la trazabilidad de forma bidireccional. Para ello utilizan metadatos en el código que lo vinculan con entidades del modelo, mientras que a su vez el modelo incluye también una serie de campos que recogen la información específica del código que no puede ser «pintada» en el modelo, pero que se usará para regenerar el código o integrarla en el nuevo código.
Y en lo que comentaba Javier Garzás sobre escenarios con decenas de versiones e instalaciones de un producto, sí que estoy de acuerdo en que en la actualidad (al menos hasta donde yo sé) las herramientas MDD existentes no están preparadas para ello. Sin embargo, en el sector académico sí que hay trabajos en dicha dirección, en lo que se conoce como las Líneas de Producto Software aplicadas a MDD, definiendo modelos que son capaces de recoger la variabilidad de distintas versiones de un mismo desarrollo y el código específico asociado a cada versión.
En resumen, ¿merece la pena MDD? Si contamos con herramientas maduras (lo que empieza ya a ser el caso), SÍ. Es cuestión de tiempo que empiece a ser una tecnología de rápida adopción.
Hombre, pero se supone que en un ideal, el objetivo que persigue un MDD es prácticamente reducir al muy máximo la figura del programador. La idea del MDD es que igual que hoy no hay mucho desarrollo en ensamblador porque hay lenguajes de alto nivel, que ocurra lo mismo con el lenguaje de dominio de alto nivel y el lenguaje de alto nivel…
Cristóbal,
Tu comentario coincide con la idea que yo tenía, que intentaré resumir en que si en la actualidad sólo se soporta una única dirección Modelo->Código y en inverso no es lo suficientemente robusto, y solo funciona en la teoría y en entornos controlados, el MDD puede funcionar, pero que como la realidad de miles de empresas es que hay decenas de personas tirando líneas «de aquella manera»… en esos casos y en la realidad es algo muy difícil de implantar.
Y en cualquier caso, o lo que viene a ser lo mismo que dije antes, y creo que lo comentaban también Pedro y Juanjo Olmedilla, si antes no hay un proceso de calidad, un minimo proceso o como cada quien quiera llamarlo…. no funciona.
O sea, que volvemos al problema de toda la vida… que necesitamos implantar procesos de calidad previos a cualquier mejora de alto nivel como MDD.
no?
Gracias por los interesantes comentarios.
Hola,
Dejo una pregunta, por si alguien ha tenido la experiencia, tiene opinión al respecto, etc.
¿Cómo funciona un MDD en un ciclo de vida iterativo e incremental con iteraciones cortas de apenas 4 semanas?
Me estoy refiriendo a como funciona en un cv ágil, donde el diseño está poco claro al principio, se va creando en iteraciones rápidas, normlmente se tira mucho de la refaztorización (entiendo que aquí sería de diseño no de código), etc.
Jack W. Reeves: The Code is the Design, fundamental.
Dicho esto: en Plastic tenemos docus de diseño… sirven para dos cosas:
a) Los suficientemente genéricos, para seguir explicando el sistema incluso 7 años después.
b) Los muy detallados: para amueblarte la cabeza mientras lo estás pensando, y poder dejar claro por qué hiciste esto o aquello… eso sí, no servirán (si eran muy, muy detallados) para explicar nada 1 año después, porque seguro que habrá cambiado. Pero los hacemos porque nos ayudan a pensar, a discutir sobre ello, etc, etc.
Y, sea dicho de paso, incluso nuestros diseños detallados son bastante cortos, muchos diagramas, muchos visios, pseudocógidos, y explicaciones a texto cuando la cosa se pone fea… 🙂
Totalmente de acuerdo.
En la ULL estamos trabajando con MDD para la generación de aplicaciones de administración electrónica, con muy buenos resultados. Tambien lo estamos trabajando con el enfoque SPL y software product line (reutilización estratégica)
Pueden ver
http://fap-devel.etsii.ull.es/home
En las desarrollos serios estamos muy lejos de poder trabajar a partir de código generado automáticamente a partir del diseño. Coincido bastante con lo publicado por Scott W. Ambler en http://www.agilemodeling.com/essays/agileDocumentation.htm
Tampoco encaja mucho el diseñar y obtener después el código si se hace TDD.
Buenas a todos,
estos debates me encantan, porque unen nuestros cerebros para potenciar ideas innovadoras y nos hacen frenar para pensar y concentrarnos en una única realidad, enhorabuena a J. Garzás.
Estoy de acuerdo con Pedro en prácticamente todo, excepto en:
– Entonces tendríamos dos maneras de «desarrollar» la aplicación:
· Reconfigurando la estructura MDD.
· Re-programanado o ampliando el código realizado a mano (50% – 20%)
Desde mi ignorancia, ¿no crees que trabajar con dos flancos en las empresas que generan nuevos desarrollos, se puede llegar a complicar la complejidad (interacción entre los miembros del equipo, documentación, análisis…)?
Por ejemplo, si usamos procesos iterativos-incrementales, tendríamos que realizar prototipos con un análisis x2 (uno para MDD y otro para el resto), al igual que en sucesivas versiones. Además, cada vez que viniera una petición de cambio (en mantenimiento), tendríamos que hacer un análisis de ambas plataformas.
Como en otras ocasiones pienso que esto no es una panacea (como a veces lo venden) y creo que puede ser una buena solución pero solo para desarrollos con unos requisitos en especial (aplicaciones CRUD, o que sean altamente programables con MDD usando IDL´s…)
Un saludo.
Hola David: no estoy para nada de acuerdo con tu afirmación sobre los «desarrollos serios», así que voy a intentar rebatirlo.
Como se ha comentado una y otra vez en software «There is no silver bullet» y MDD no es una excepción. No es una receta para todo. Pero en dominios reducidos, donde se construye software conforme a una arquitectura prestablecida (léase software empresarial, aeronautica, software embebido, bolsa, por ejemplo): acelera y bastante.
Os dejo algunos punteros a ejemplos de desarrollos ‘serios’ con MDD donde se genera código y mucho en algunos casos:
1.- Ira Baxter de Semantic Design video: http://www.youtube.com/watch?v=C-_dw9iEzhA
Como migrar de modo 100% automático todo el código del cazabombardero B2 en Jovial 1.2 millones de líneas de código en C. Ira es experto en ingeniería inversa.
2.- Algunas referencias de Metacase creando modelos y DSL a medida para algunos clientes: http://www.metacase.com/cases/detailed_cases.html y este http://www.codegeneration.net/cg2009/handouts/Tolvanen.pdf
3.- Itemis creando sistemas de trading en tiempo real para Deutsche Boerse AG aplicando generación de código. http://ewita.nordakademie.de/folien4.pdf
http://www.codegeneration.net/cg2009/sessioninfo.php?session=64
4.- Markus Voëlter y el proyecto mbeddr http://mbeddr.wordpress.com/ para extender el C embebido con modelos levantando el nivel de abstracción en un dominio donde los errores son especialmente caros y mejor cazar todos los que puedas antes de liberar versión.
5.- Proyecto AUTOSAR http://www.autosar.org/ (estandar de modelado para el Software en la industria automovilística para componentes) Ejemplo: http://www.bmwcar-it.de/common/pdf/2007/Elektronik_automotive_V010-final1.pdf
6.- Jetbrains que construye y vende Youtrack http://www.jetbrains.com/youtrack/ a partir de su modelado y programación desde MPS (Meta Programmign System) un Language Workbenches donde la frontera entre modelar y programar se diluye cada vez mas: http://www.jetbrains.com/mps/
7.- Axel Uhl sobre el proyecto MOIN o como SAP invirtió en MDD para cambiar el modo de hacer software dentro de SAP. http://www.codegeneration.net/cg2007/interviews/AxelUhlInterview.pdf
8.- EADS, AIRBUS, Volvo y muchas otras empresas del sector aeroespacial usan aproximaciones Model Driven desde hace tiempo y generan código para sistemas embebidos de misión critica. Generar p.e. maquinas de estados es trivial para una maquina (o generador) pero propenso a errores para humanos (a los que se nos da mejor dibujar con menos detalles) cuando el número de estados y transiciones crece.
Algunas referencias al respecto:
– http://www.esterel-technologies.com/technology/success-stories/airbus
– http://www2.cs.uni-paderborn.de/cs/ag-schaefer-static/Lehre/Lehrveranstaltungen/Seminare/ATSEfSCS/slides/Automated Code Generation.pdf
– http://websrv0a.sdu.dk/ups/ESD/background/lecture01_motivation/airbus-efficient-code-generation.pdf
– ftp://ftp.estec.esa.nl/pub3/tos-qq/qqs/Automatic_Code_Generation/ACG-TN-6-SE-EADS Scade config.pdf
Espero baste con estos, si hace falta, hay muchos más 😉
Con lo comentado, espero haber argumentado lo suficiente sobre la existencia de desarrollos serios donde sí se trabaja a partir de código generado automáticamente a partir del diseño.
Para aplicaciones móviles super-rompedoras o portales web únicos en su especie, ciertamente MDD no aplica, pero si el software pertenece a un dominio concreto, con volumen, donde existen «familias de programas» [Parnas76] (
http://web.cecs.pdx.edu/~omse532/Parnas_Families.pdf ) MDD aplica y ayuda a no reinventar la rueda y a cometer menos errores.
Al final, la pregunta que subyace en como nos enfrentamos al software es filosófica: ¿como programadores/arquitectos nos consideramos a nosotros mismos artesanos o ingenieros?
Mi opinión sobre esto último:
– ¿Hay arte/artesanía en lo que hacemos? Sin duda, en ocasiones, demasiada.
– ¿Hay/debería haber más ingeniería en lo que hacemos? Desde mi punto de vista: mucha, mucha más deberíamos poner.
Hola Javier Pulido:
Cuando mantenemos software al modo, llamemoslo convencional, lo normal es mantener ficheros fuente, por ejemplo en un leguaje como Java o C#, pero también mantenemos otras cosas: ficheros de configuración XML, transformaciones XSL-T (afortunados los que no sepan lo que es esto último), ficheros make, ant, maven o similar, etc. Es decir, no todos los artefactos que mantenemos tienen la misma expresividad, ni el mismo lenguaje para tratar con ellos y llegar a deducir que son correctos. Hay editores especiales y adaptados, sensibles al lenguaje, para validar y tratar con cada una de estas bestias de diverso pelaje.
Como ves ya hay “más de un flanco”, en el sentido de que los artefactos software a mantener son diversos.
Lo que no hacemos es mantener un fichero *.class porque “asumimos” que se deriva de una compilación de un fichero *.java y que por tanto “confiamos” en un compilador que se encarga.
Aplicando MDD para construir software, no es muy diferente de un proyecto convencional, pero el modelo, ahora: genera otros artefactos software y tiene editores propios. El código generado aun siendo un *.java debe tratarse como si fuera un *.class (como un subproducto que puede derivarse siempre que sea necesario) y no como un asset a mantener directamente. El mantenimiento ha pasado del código al modelo y a las plantillas de generación de código. Tratar de romper esta regla solo provoca, a nivel practico, problemas.
Al trabajar en un proyecto MDD (y contestando a como seria un proceso agil de 4 semanas planteada por Javier Garzas), si queremos crear el generador sobre la marcha se procede del siguiente modo:
1. Se crea “a mano” un primer prototipo del sistema en vertical, pasando por todas las capas y buscando probar toda o la mayor parte de la casuística que nos podamos encontrar. Refactorizamos lo que haga falta hasta quedar satisfechos.
2. Separamos la parte común (librería) de la parte variable (a modelo que puede ser generada).
3. Montamos el DSL, el modelo, el generador de código y las plantillas.
4. Modelamos el prototipo, apretamos el botón rojo y obtenemos (si lo hemos hecho bien) exactamente lo mismo que el paso (1).
Pregunta: ¿Cómo de bueno es el código en (4)? Tan bueno como hayamos sido capaces de programarlo a mano en (1). El generador dirá algo así: ERROR 508 NOT MY FAULT }:-)
5. Iteramos, aplicamos análisis de coste/beneficio y decidimos si merece la pena automatizar o no:
6. Si merece la pena añadimos nuevas características en el código, o en el modelo y las plantillas, o en el framework que lo resuelva, según el caso.
7. Para lo que no merezca la pena, se diseña un punto de extensión para que convivan el código generado y el codigo manual y se documenta bien.
El tamaño de las iteraciones y su número, al buen criterio de cada cual y necesidades del proyecto.
Algunas técnicas para convivencia de código manual y generado:
– Doubled derived class
– Partial classes
– Hollywood Principle (Don’t call us, we’ll call you)
– Event subscription (pre/post/cancel)
– Aspect Oriented Programming
– Etc. hay más y no una major, se deben usar segun el caso particular
MDD es poco conocido, hay muchas herramientas y diversidad, pero lo cierto es que hasta que no lo pruebas no acabas de “ver claro” las posibilidades que se abren.
Si hay interés entre los lectores os propongo que hagamos un webcast por ejemplo una tarde de estas para hacer un sistema “en vivo” desde cero a la MDD y que podáis comprobar sus pros y contras de primera mano.
Coincido con Pedro Gónzalez.
Los programadores serán siempre necesarios, pero irán subiendo su nivel de abstracción sobre el que trabajar, por ejemplo: dejando de hacer clases DAO una y otra vez para hacer una plantilla DAO que genere todas las demás instancias.
Como dice @FransBouma ¿tu cliente te paga para que actúes como un tipista (grabador de datos) y escribir mucho código repetitivo con poco valor añadido o como ingeniero para hacer más con menos?
Si se pueden generar tablas y DAOs a partir de modelos indistingibles de los «hecho a mano», ¿como le explicas a tu cliente el sobrecoste de hacerlo «a mano»?
Indiscutible Javier: un proceso de calidad siempre viene bien siempre, con MDD y sin MDD.
Pedro, no estarás llamando programador a lo que sería un analista…? porque para mi que lo llámes como lo llámes en ese escenario no es un programador. Gracias por los interesantes comentarios.
¿y para que queremos pasar de código a modelo? es como querer pasar de ensamblador a c o de bitcode a java. nunca se ha hecho correctamente. sigamos aumentanto el nivel de expresividad de los lenguajes.
la idea es programar normal, si ves trozos de codigo que se repiten, pues intenta pasarlo al generador de codigo y controlar la variabilidad en el DSL (es como automatizar un ctrl+c ctrl+v)
El problema de este enfoque es que vas a conseguir un DSL muy técnico orientados a la arquitectura y lo ideal es crear DSL vinculados al negocio.
Disculpen pero estoy escribiendo desde el tablet.
Es cierto Miguel que al aplicar MDD, las dedicaciones de los perfiles cambian y hasta es posible que los roles se transformen: se hace más análisis, más diseño, más arquitectura y menos código (que es lo que se intenta automatizar al fin y al cabo).
Pero para este ejemplo particular que puse (automatización de DAOs) podríamos decir que el programador pasa a tener mas visión de conjunto, hacia el rol de «arquitecto» o diseñador de framework al tener que diseñar una plantilla que generaliza el comportamiento y sus variantes, pero no tiene por que ser la misma persona que hace de analista: encargado de hacer el modelo y define/descubre las entidades y restricciones de negocio.
Que conste: que no está en mi animo mandar al paro a ningún programador, entre los que me incluyo. Al contrario, sino de dotarnos de mejores herramientas que nos liberen del trabajo pesado para poner a las neuronas a trabajar en lo importante que un generador no cubre.
Efectivamente Pedro ese tipo de DSLs no son muy útiles cuando se contaminan por la tecnología.
Mi opinión es que se pueden/deben conseguir DSLs de negocio sin contaminarlos con aspectos de arquitectura para que sean de mas valor al negocio y oculten los detalles irrelevantes.
Lo bueno de MDD es que podemos tener:
– Modelo + Plantillas >> Código
– Negocio + Tecnologia/Arquitectura >> Aplicación
Mientras se mantenga la separación (SoC) de modo estricto de negocio respecto a tecnología, el DSL no se contamina.
El negocio esta descrito en DSLs. Mientras que las decisiones de arquitectura estan descrita en las plantillas.
Si llegamos hasta aqui, ganamos dos propiedades fundamentales:
1. Seperación de responsabilidades: los analistas crean los modelos, describen el negocio, los arquitectos/programadores crean la arquitectura y las plantillas en la tecnología
2. Independencia tecnológica (de la buena)
Mas que venir bien… diría que es imprescindible! 🙂
Pingback: Resumen de la semana – del 9 al 15 de Julio de 2012 - Javier Garzás, sobre calidad software y otros temas relacionados
Y eso es precisamente lo que hace Extreme Programming. Uno de sus «expertos» (por llamarlo de alguna manera) dice: «El código es el modelo». Simplemente hay que buscar la palabra modelo en el diccionario para ver que eso es completamente falso. Un modelo es una abstracción y una simplificación de la realidad, por ello, 10 páginas de C++ no son el modelo del comportamiento de un sistema, lo es un diagrama de estados y de actividad, por ejemplo. Por ello, pienso que Extreme Programming es algo malo para la industria, por centrarse en el código en lugar de subir de nivel de abstracción.
«Somos pocos, tenemos prisa» Eso ya es empezar mal, típico de España, las prisas.
«puedes llegar muy lejos sin documentación ni diseño» Seguro, y ten por seguro que llegará un momento que el programa sea completamente inmantenible, un espanto en lo que a calidad se refiere. Desgraciadamente, esa es la forma normal de trabajar en este país.
No tiene sentido convertir Java a modelos. Es como convertir ensamblador en C++ o Java. Puedes transformar de un cierto nivel de abstracción a otro más bajo, pero no al contrario, ya que la transformación hace que se pierda información.
Míralo de esta forma: Con un cerdo puedes crear 100 salchichas. Pero con 100 salchichas no puedes crear un cerdo. Por ello, lo que propones no tiene sentido.
¿Quien iba a querer hacer un programa en ensamblador para convertirlo en C++? No seas estúpido y hazlo en C++.
Es evidente que por la pregunta nunca has usado MDD.
Cambiar un modelo es más rápido, fácil y sencillo (y legible) que cambiar un montón de código en Java/C++, especialmente si no lo has hecho tú. Un modelo se ve su funcionamiento de un vistazo, en un cacho de código tienes que leer y leer y romperte los cuernos para comprender, especialmente si no lo hiciste tú.
Es más, todas las ingenierías modelan (lo cual es de cajón), mientras que en software algunos se empeñan en creer en tonterías y chorradas como «El código es el modelo» (Extreme Programming). Hay gente que parece que disfruta haciendo las cosas complicadas…
Por cierto te dejo una comparativa donde una empresa te explica sus experiencias modelando:
http://www.webml.org/webml/upload/ent5/1/LNCS_final_printed_46070539.pdf
«Jack W. Reeves: The Code is the Design»
Eso es falso, y por ello su autor para mí no vale nada, simplemente busca la palabra modelo en el diccionario. Ya te lo digo yo: «Modelo: abstracción o simplificación de la realidad»
Lo correcto es: «El modelo es el código».
Es gente como Jack que con ese pensamiento hace que el software hoy en día sea tan pobre de calidad y el desarrollo sea una artesanía chapucera.
El F22-Raptor es el avión de guerra más moderno y complejo creado. Su software fue creado con MDD.
El Chevy Volt es el coche híbrido más moderno que existe. Su software fue creado con MDD.
El Airbus A380 es el avión de pasajeros más grande que existe. Su software fue creado con MDD.
En realidad, lo que dices tú y ese autor, es justo lo contrario, y así lo dicen los ejemplos expuestos. Scott W. Ambler es otro de esos autores que tienen alergia a modelar, otro chapucero más.
Si el software más puntero que se hace, se hiciera con las técnicas de Scott W. Ambler, tú ahora mismo estarías muerto, porque tu avión se habría estrellado, por ejemplo.
Un programa en un lenguaje imperativo, no se puede validar por su naturaleza (por los efectos colaterales), pero un modelo sí. De esto, los agilistas no suelen tener la menor idea.
Un poco en la línea de lo que comentaba Pedro J… por trabajar en un nivel de abstracción más alto, el programador no deja de ser programador, ¿no crees?
¿Dejaron de ser programadores quienes transicionaron de lenguaje máquina a ensamblador?
¿Deja uno de ser programador por utilizar un framework?
MDD NO persigue reducir a la mínima expresión la figura del programador, ni mucho menos eliminarla.
La historia del desarrollo de software se caracteriza por un constante aumento de nivel de abstracción y MDD es un paso más en esa escalera evolutiva.
Juan Carlos, pues los expertos en Extreme Programming se empeñan en no seguir ese aumento normal y natural de nivel de abstracción, por eso pienso que son más un problema que una solución.
Pedro y Juan Carlos,
Podéis llamarlo como queráis, pero un programador que pasa a hacer el rol de arquitecto, es un arquitecto.
¿Por trabajar en un nivel de abstracción más alto, el programador no deja de ser programador?… Claro que si deja de serlo, deja de ser programador y ahora es diseñador.
Eso es como si a los pintores los poneis ahora a cortar arboles, podeis llamarlos pintores corta arboles pero el resto del mundo los llamará leñadores.
😉
Me da igual como llames a cada cual, pero por mi experiencia te puedo decir que los programadores en general son pésimos modeladores (no te digo ya el hecho de metamodelar o crear un compilador de modelos, eso ya piensan que son cosas de la NASA). Y eso cuando por alguna extraña razón que aún no entiendo están en contra de estas cosas. Posiblemente sea por miedo a lo desconocido, no sé, sinceramente.
MDD requiere un cambio de chip y reseteo, y muchos programadores no lo aceptarán. Y eso te lo digo por experiencia propia, por haberlo visto.
No olvides que mucha gente que programa no es ingeniero infomático, así que posiblemente crean que UML es un detergente.
Pues como dices, por la experiencia puedo comentar:
Acá es donde es me ha sido super útil…. Con proyectos que se van forjando día a día y que van dando forma con los pocos minutos de reunión que he tenido con el cliente, quedamos de acuerdo con lo macro de lo que desea y anoto los detalles que le falta (los cuales paso al programador).
Al día siguiente se revisa lo anterior, continuamos el macro (diseños que generan modelos, codigo, pruebas) vemos la funcionalidad, notamos inconsistencias con lo trabajado el día anterior, se anotan las imperfecciones y correcciones y seguimos asi durante tres semanas….
Un modelo iterativo en toda su extensión….
Unión Usuario – Arquitecto – Programador. Claro vidireccional no hemos tenido, pero con la separación de codigo generado y manual nos ha sido suficiente.
Estupenda forma de desarrollo…. con las grandes ventas que TU DISEÑO es TU CODIGO (logico, no 100%) pero sabes en realidad con certeza QUE HACE TU CODIGO….. esto no tiene precio (vale el anuncio)
Respondiente rapito y concreto Fracisco.
Codigo Generado (modelado le llamo yo, por costumbre con mis equipos de programadores) y Codigo Manual, son un complemento. Mantenerlo es como cualquier proyecto.
Pingback: Cómo ha ido este blog en 2012, algunos números y reflexiones - Javier Garzás, sobre calidad software y otros temas relacionados
Hola todos, tras 27 años en este sector he pasado por todos los tipos de paradigmas, metodologías, ciclos de vida, etc, que os podéis imaginar. Estuve en un proyecto de seguros en el que se aplicó MDD con AndroMDa con bastante éxito hasta que …, las personas que lo lideraban se fueron a otro proyecto.
Ahora estoy en una compañía con cientos de desarroladores, proveedores, factorías, cada uno de su padre y de su madre, donde la mayor parte del presupuesto en informática se la lleva el Mantenimiento de las aplicaciones, donde crear un nuevo producto de negocio no es sino adaptar lo que ya tienen hecho, un evolutivo. Y eso sí, les encantan las siglas, CMMI, Scrum, PMBOK.
Mi conclusión es que son las personas las que hacen que todo esto del desarrollo funcione. Si utilizo MDD y no tengo el equipo adecuado estoy muerto, si quiero hacer Scrum y tengo un scrum master que se cree jefe de proyecto, estoy muerto, si tengo que modificar un legacy con dos programadores que me vienen del agile, estoy muerto y los mato a ellos.
Conclusión: Personas
No se si fue Serrat quién dijo eso de «educad a los niños y no tendréis que castigar a los adultos», pues eso nos hace falta, buena cultura entre nosotros y nuestros directivos.
Abrazos,
Si hablamos del código generado por Eclipse (constructor, getters, setters) o los CRUDs que generan los framewoks, está claro que este código generado a partir de modelos dista mucho del que realmente soporta los procesos de negocio. Ese hay que codificarlo y probarlo como se ha hecho toda la vida. Si se hace con buenas prácticas, con buen estilo de programación, el producto final no tiene por que ser inmantenible. Otra cosa es que para «bajar los costes del proyecto» y pensando en que el código «se pica y lo pica cualquiera» en lugar de todo lo que implica, contrates a cuatro juniors con la cárnica de turno, los eches a todos cada tres meses y vuelta a empezar. Saludos