El desarrollo de software dirigido por modelos (MDD) es un paradigma que utiliza modelos como actores principales en la creación de software, mejorando la productividad, calidad y entendimiento del sistema a desarrollar. A pesar de su aceptación creciente, persisten mitos y confusiones sobre su aplicación en la industria, como la idea errónea de que UML puede resolver todos los problemas de desarrollo. MDD implica transformaciones de modelo a modelo y de modelo a texto, y su implementación efectiva requiere estrategias adaptativas y un enfoque basado en el sentido común.

1. MDD - Desarrollo de software dirigido por modelos que funciona (¡de verdad!) Jordi Cabot http://modeling-languages.com @softmodeling

2. Me Presento (por educación)

3. PhD por la UPC (Barcelona) Estancias en Italia y Canadá Investigación: Director del grupo AtlanMod École des Mines de Nantes/INRIA Especialista en la investigación en MDE. www.emn.fr/x-info/atlanmod Divulgación: Modeling Languages portal: http://modeling-languages.com Empresa: Servicios de generación de código online en el portal Me presento

4. ¿Qué es el desarrollo dirigido por modelos (MDD – Model Driven Development)?

5. MDD es un “nuevo” paradigma para el desarrollo de software Modelos como principal elemento del proceso de desarrollo (ej. código generado (semi)automáticamente a partir de modelos Pq MDD? – Beneficios: Mejora la productividad Aumenta la calidad Mejor comprensión del sistema a desarrollar Facilita evolución y mantenimiento Facilita reuso/reimplementación en otras tecnologías … MDD – Desarrollo de software dirigido por modelos

6. Un proceso MDD Un proceso MDD puede verse como un conjunto de transformaciones modelo a modelo (M2M) + una transformación final modelo a texto (M2T)

7. Relationship between MDA/MDD/MDE

8. Elementos clave en MDD: Modelos y Transformaciones MDE Grammarware MOF (metametamodel) UML (metamodel) ABank.uml EBNF.g Java.g MyProgram.java Misma arquitectura pero diferente nivel de abstracción: Focalización en lo importante en cada momento

9. Elementos clave en MDD: Modelos y Transformaciones 2 tipos: Transformaciones modelo a modelo (M2M) y transformaciónes modelo a texto (M2T) Estándares (de juro o de facto): M2M: ATL, QVT M2T: MOF-to-text, XPand

10. Reality Check – Estado de adopción en la industria

11. S. Mellor: MDE will be commonplace in three years time ¿Implantación en la industria? Aunque lo viene diciendo desde el 1985!

12. Situación del MDD UML?

13. Muchas concepciones equivocadas acerca de lo que realmente es MDD y como utilizarlo. Falsos Mitos: UML como solución inmediata a todos los problemas de desarrollo de software de la empresa UML como “método de desarrollo” Generación del 100% del código de la aplicación UML sirve para modelar cualquier tipo de aplicación Modelar todo y siempre Había que vender herramientas, formación, consultoría,…. ¿Y porqué?

14. Afortunadamente las cosas están cambiando Nuevas técnicas y herramientas, más maduras y más potentes Estándares de facto. Mejor comprensión de las ventajas de MDD (cuando se utiliza correctamente) Se “palpa en el ambiente” que hay que estar ahí -> mucho interés por parte de las empresas en dar MDD una segunda oportunidad Miedo a perderse algo importante MDD 2.0

15. El resto de la presentación hablaremos de las mejoras estrategias MDD pero por si quedan escépticos…

16. Toda la historia de la informática ha sido una lucha constante para subir el nivel de abstracción al que había que trabajar Cualquier lenguaje de programación es de hecho un generador de código (C -> lenguaje ensamblador) MDD sólo sigue esta tendencia y escoge el concepto de modelo como nivel de abstracción Igual que al programar en C se pierde un poco de control pero se mejora productividad, calidad,…, lo mismo en MDD … y ahora nadie defiende la idea de programar en ensamblador… Diferencia entre modelado y programación cada vez más difusa! MDD es algo natural

17. MDD es algo natural Qué tienen todos ellos en común????? Dado un modelo, crean la base de datos y toda la interfaz para CRUD Siguen MDD!!!!

18. ¿Alguien no cree que esto mejora el desarrollo de software?

19. OK. Convencido. Pero ¿cómo lo aplico en mi caso?

20. La mejor estrategia depende de muchos factores El tipo de aplicaciones que desarrollas Los conocimientos de los miembros de tu equipo de desarrollo El grado de cambio que quieras acometer … DISCLAIMER: No hay recetas mágicas No hay recetas mágicas pero si consejos que os pueden ayudar a decidir

21. 1. Mis consejos acerca de la estrategia MDD a adoptar

22. Common-sense code generation Mi regla de Pareto para MDD (regla del 80/20): 20% of the modeling effort suffices to generate 80% of the application code Una gran parte de las funcionalidades de cualquier aplicación se pueden deducir aplicando un poco de sentido común Clásico ejemplo: Páginas CRUD para cada clase del dominio Pero también se podría: informes, gestión de usuarios,…

23. Common-sense code generation (II) Cuando el conocimiento implícito dentro de la empresa es suficiente, modelar algunas partes del sistema no aporta nada y nos hace perder el tiempo Ciertamente, esto obliga a los nuevos a entender la “cultura MDD de la empresa” para empezar a ser productivos pero vale la pena Aplicar el comon-sense code generation siempre que sea posible, eso sí, definir claramente en algún documento público cuál es el sentido común a aplicar Ya sabemos que el sentido común es el menos común de los sentidos…

24. Evitar roundtrip (en la medida de lo posible) Roundtrip engineering permite cambiar tanto los modelos como el código y mantener a ambos sincronizados. En teoría parece una muy buena idea Se genera parte del código Se complementa a mano y esos cambios se preservan si se regenera el código a partir de una evolución de los modelos En la práctica no lo es tanto Pocas herramientas ofrecen esta posibilidad Hay que ser cuidadoso al hacer los cambios Trabajo addicional de anotaciones para marcar las zonas a no modificar Mejor generar completamente parte de la aplicación que parcialmente toda la aplicación!!

25. UML vs DSLs Se habla mucho de los Domain-Specific Languages ( DSLs) Un DSL permite proporcionar al usuario un lenguaje (de modelado) perfectamente adaptado a la semántica del dominio De hecho la idea no es nueva (SQL es un DSL y UsiXML para definir interfaces gráficas otro) pero ahora hay herramientas que facilitan mucho la creación de DSLs Sintaxis, entorno de modelado, validación, ... UML no es un DSL, es un GML (general modeling language) pero admite extensiones para adaptarlo a un dominio concreto mediante el uso de profiles UML es un multi-domains language, es decir sirve para muchas cosas. Evitar reinventar la rueda!

26. Pero a veces no hay más remedio… Entornos para la creación de DSLs textuales: EMFText, XText, TCS Entornos para la creación de DSLs gráficos: GMF y Graphiti. En los dos casos, el diseñador define el metamodelo del DSL y indica la notación (gráfica o textual) para cada elemento Las herramientas generan “gratis” un entorno de modelado completo para el nuevo lenguaje Esto puede ser necesario, por ej., para modelar interfaces gráficas complicadas, una de las limitaciones del UML

27. Ej. DSL - MOSKitt User Interface Modeling

28. UML Ejecutable Programar con UML ya es ahora posible Estándard fUML ( Foundational UML specification) Notación textual Alf (para escribir “pseudocódigo” de forma independiente al lenguaje de programación Ej. totalBalance = 0; for (balance in myCustomer.accounts.balance) { totalBalance += balance; } Que sea posible no quiere decir que sea recomendable… En estos momentos casi no hay herramientas Mejor estrategia common-sense para las fáciles y programación directa para las difíciles

29. Code generation vs Model Interpretation Model interpretation facilita el uso de MDD a gente no técnica (e.j. despliegue automático en la cloud) Code generation protege mejor ante problemas con la empresa que vende la herramienta (siempre te quedan los ficheros fuente de la aplicación) y ofrece mejor control Hay estrategias mixtas (despliegue automàtico en generación, intepretación a través de generación interna,…) Si mejor utilizar generación de código

30. 2. Mis consejos acerca de la herramienta a elegir

31. Herramientas de dibujo vs Herramientas de Modelado Cuidado con las herramientas de dibujo. Más usables pero no entienden la semántica del lenguaje Dificil interactuar con ellas: Exportación sólo como imagen gráfica API limitada a las formas gráficas (se puede pedir “dame todos los rectángulos” pero no “dame todas las clases”) Escoger siempre una herramienta de modelado real

32. Herramientas de modelado vs Herramientas MDD Las herramientas MDD se han creado desde el principio con la intención de automatizar el proceso de desarrollo El objetivo principal de las herramientas de modelado es permitir la especificación de sistemas software (para generar código, como documentación,…) Con el tiempo todas las herramientas de modelado han incorporado funcionalidades de generación de código. Ojo: Muchas veces limitadas a generar skeletons o código muy parcial Pueden obligar a añadir muchas anotaciones en los modelos Modelos para comunicación? Mejor una herramienta de modelado Modelos para generación? Mejor una herramienta MDD

33. Diferentes modelos de negocio Herramientas Open Source Comprar licencia Pagar por uso Ojo, a veces lo barato sale caro. Las herramientas OSS normalmente necesitan un mayor nivel de conocimiento para sacarles partido Pagar por uso es la mejor opción para permitir empezar poco a poco y escalar después si es necesario

34. ¿Texto o gráficos? Los modelos no tienen pq estar definidos siempre con una notación gráfica Cada una tiene sus ventajas: Gráfico: mejor comprensión global, aspectos estáticos,… Textual: más parecido a la programación, mejor para aspectos dinámicos de bajo nivel Hay muchas herramientas para UML textual http://modeling-languages.com/content/uml-tools#textual Combinarlas dependiendo del tipo de modelo.

35. Otras características a tener en cuenta Usabilidad? Modelado colaborativo? Control de versiones? Gestión de modelos? Flexibilidad de la herramienta? Gran influencia en el uso final o no de la herramienta en la empresa. Si genera un código excelente pero no es usable…

36. Objetivo ideal: Turing test for MDD tools Idealmente, las herramientas MDD deber ían pasar mi adaptación del turing test para herramientas de generación de código: A human judge examines the code generated by one programmer and one code-generation tool for the same formal specification. If the judge cannot reliably tell the tool from the human, the tool is said to have passed the test Aunque, por supuesto, todavía estamos lejos de este punto… Gran influencia en el uso final o no de la herramienta en la empresa. Si genera un código excelente pero no es usable…

37. Ejemplo 0: DIY - Crear tu propia herramienta Mejor opción: basarla en Eclipse y reutilizar los componentes del Eclipse Modeling Project (EMP) EMP propone componentes para: Definir modelos (EMF) Transformaciones M2M (e.j. ATL) Transformaciones M2T (e.j. JET, Xpand, …) Definición de DSLs (XText, EMFText, TCS,..) Que puedes combinar para crear tu propio proceso MDD Sólo apta para usuarios avanzados!!!

38. Ejemplo 1: Acceleo Open Source Template-based (adaptable!) Algunas predefinidas

39. Ejemplo 2: WebML Web applications Code-generation Java

40. Ejemplo 3: Modeling-Languages.com Filosofia Common-sense MDD Web applications Code-generation SQL & PHP/Symfony & Python/Django

41. Ejemplo 4: Mendix Web applications Model Interpretation

42. Ejemplo 5: OutSystems Web applications Code-generation C# and Java

43. Ejemplo 6: Novulo Web applications Code-generation .NET

44. 3. Mis consejos sobre el proceso MDD

45. MDD se integra en cualquier tipo de proceso de desarrollo MDD es más un framework de desarrollo que un proceso de desarrollo específico MDD puede usarse como parte de procesos waterfall o en procesos de tipo Agile Por ejemplo: Modelado adaptado a Agile: Agile Modeling MDD adaptado a Agile: Agile MDA Más info en: Agile and Modeling / MDE : friends or foes? (en el portal de modelado)

46. No es suficiente con comprar una buena herramienta Falta invertir también en la gente. Hay que asegurarse que el equipo de desarrollo está preparado: ¿Y si nadie sabe modelar? Un buen programador no es necesariamente un buen analista MDD implica nuevos roles, taras y dependencias entre los miembros del equipo -> No siempre el que las hace ve el Bº No escoger como primer proyecto un proyecto complicado Mejor si un experto os supervisa al principio Y tener paciencia Toda nueva tecnología disminuye la productividad al principio pero hay que hacer las cosas bien Recordad: “Introduction of ANY new technology decreases productivity in the short term”

47. Basta por hoy, pero podemos seguir la discusión más tarde …

48. Sigamos la discusión http://modeling-languages.com [email_address] @softmodeling