MDD - Desarrollo de software dirigido por modelos que funciona (de verdad!)

18,773 views

Published on

Consejos para tener éxito en la adopción de una estrategia MDD en vuestro proceso de desarrollo.

Más sobre estos temas (UML, DSLs, MDA, generación de código,..) en http://modeling-languages.com

Published in: Technology
0 Comments
13 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
18,773
On SlideShare
0
From Embeds
0
Number of Embeds
3,752
Actions
Shares
0
Downloads
445
Comments
0
Likes
13
Embeds 0
No embeds

No notes for slide
  • To present you a method that helps the designer during the specification of the software system by automatically generating a set of operations for a given class diagram.
  • Simple is more or less as public
  • MDD - Desarrollo de software dirigido por modelos que funciona (de verdad!)

    1. 1. MDD - Desarrollo de software dirigido por modelos que funciona (¡de verdad!) Jordi Cabot http://modeling-languages.com @softmodeling
    2. 2. Me Presento (por educación)
    3. 3. <ul><li>PhD por la UPC (Barcelona) </li></ul><ul><li>Estancias en Italia y Canadá </li></ul><ul><li>Investigación: Director del grupo AtlanMod </li></ul><ul><ul><li>École des Mines de Nantes/INRIA </li></ul></ul><ul><ul><li>Especialista en la investigación en MDE. </li></ul></ul><ul><ul><li>www.emn.fr/x-info/atlanmod </li></ul></ul><ul><li>Divulgación: Modeling Languages portal: http://modeling-languages.com </li></ul><ul><li>Empresa: Servicios de generación de código online en el portal </li></ul>Me presento
    4. 4. ¿Qué es el desarrollo dirigido por modelos (MDD – Model Driven Development)?
    5. 5. <ul><li>MDD es un “nuevo” paradigma para el desarrollo de software </li></ul><ul><li>Modelos como principal elemento del proceso de desarrollo (ej. código generado (semi)automáticamente a partir de modelos </li></ul><ul><li>Pq MDD? – Beneficios: </li></ul><ul><ul><li>Mejora la productividad </li></ul></ul><ul><ul><li>Aumenta la calidad </li></ul></ul><ul><ul><li>Mejor comprensión del sistema a desarrollar </li></ul></ul><ul><ul><li>Facilita evolución y mantenimiento </li></ul></ul><ul><ul><li>Facilita reuso/reimplementación en otras tecnologías </li></ul></ul><ul><ul><li>… </li></ul></ul>MDD – Desarrollo de software dirigido por modelos
    6. 6. Un proceso MDD <ul><li>Un proceso MDD puede verse como un conjunto de transformaciones modelo a modelo (M2M) + una transformación final modelo a texto (M2T) </li></ul>
    7. 7. Relationship between MDA/MDD/MDE
    8. 8. Elementos clave en MDD: Modelos y Transformaciones MDE Grammarware MOF (metametamodel) UML (metamodel) ABank.uml EBNF.g Java.g MyProgram.java <ul><li>Misma arquitectura pero diferente nivel de abstracción: </li></ul><ul><ul><li>Focalización en lo importante en cada momento </li></ul></ul>
    9. 9. Elementos clave en MDD: Modelos y Transformaciones <ul><li>2 tipos: Transformaciones modelo a modelo (M2M) y transformaciónes modelo a texto (M2T) </li></ul><ul><li>Estándares (de juro o de facto): </li></ul><ul><ul><li>M2M: ATL, QVT </li></ul></ul><ul><ul><li>M2T: MOF-to-text, XPand </li></ul></ul>
    10. 10. Reality Check – Estado de adopción en la industria
    11. 11. <ul><li>S. Mellor: MDE will be commonplace in three years time </li></ul>¿Implantación en la industria? <ul><li>Aunque lo viene diciendo desde el 1985! </li></ul>
    12. 12. Situación del MDD UML?
    13. 13. <ul><li>Muchas concepciones equivocadas acerca de lo que realmente es MDD y como utilizarlo. Falsos Mitos: </li></ul><ul><ul><li>UML como solución inmediata a todos los problemas de desarrollo de software de la empresa </li></ul></ul><ul><ul><li>UML como “método de desarrollo” </li></ul></ul><ul><ul><li>Generación del 100% del código de la aplicación </li></ul></ul><ul><ul><li>UML sirve para modelar cualquier tipo de aplicación </li></ul></ul><ul><ul><li>Modelar todo y siempre </li></ul></ul><ul><li>Había que vender herramientas, formación, consultoría,…. </li></ul>¿Y porqué?
    14. 14. <ul><li>Afortunadamente las cosas están cambiando </li></ul><ul><li>Nuevas técnicas y herramientas, más maduras y más potentes </li></ul><ul><li>Estándares de facto. </li></ul><ul><li>Mejor comprensión de las ventajas de MDD (cuando se utiliza correctamente) </li></ul><ul><li>Se “palpa en el ambiente” que hay que estar ahí -> mucho interés por parte de las empresas en dar MDD una segunda oportunidad </li></ul><ul><ul><li>Miedo a perderse algo importante </li></ul></ul>MDD 2.0
    15. 15. El resto de la presentación hablaremos de las mejoras estrategias MDD pero por si quedan escépticos…
    16. 16. <ul><li>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 </li></ul><ul><li>Cualquier lenguaje de programación es de hecho un generador de código (C -> lenguaje ensamblador) </li></ul><ul><li>MDD sólo sigue esta tendencia y escoge el concepto de modelo como nivel de abstracción </li></ul><ul><li>Igual que al programar en C se pierde un poco de control pero se mejora productividad, calidad,…, lo mismo en MDD </li></ul><ul><li>… y ahora nadie defiende la idea de programar en ensamblador… </li></ul><ul><li>Diferencia entre modelado y programación cada vez más difusa! </li></ul>MDD es algo natural
    17. 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. 18. ¿Alguien no cree que esto mejora el desarrollo de software?
    19. 19. OK. Convencido. Pero ¿cómo lo aplico en mi caso?
    20. 20. <ul><li>La mejor estrategia depende de muchos factores </li></ul><ul><li>El tipo de aplicaciones que desarrollas </li></ul><ul><li>Los conocimientos de los miembros de tu equipo de desarrollo </li></ul><ul><li>El grado de cambio que quieras acometer </li></ul><ul><li>… </li></ul>DISCLAIMER: No hay recetas mágicas <ul><li>No hay recetas mágicas pero si consejos que os pueden ayudar a decidir </li></ul>
    21. 21. 1. Mis consejos acerca de la estrategia MDD a adoptar
    22. 22. Common-sense code generation <ul><li>Mi regla de Pareto para MDD (regla del 80/20): </li></ul><ul><li>20% of the modeling effort suffices to generate 80% of the application code </li></ul><ul><li>Una gran parte de las funcionalidades de cualquier aplicación se pueden deducir aplicando un poco de sentido común </li></ul><ul><ul><li>Clásico ejemplo: Páginas CRUD para cada clase del dominio </li></ul></ul><ul><ul><li>Pero también se podría: informes, gestión de usuarios,… </li></ul></ul>
    23. 23. Common-sense code generation (II) <ul><li>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 </li></ul><ul><li>Ciertamente, esto obliga a los nuevos a entender la “cultura MDD de la empresa” para empezar a ser productivos pero vale la pena </li></ul><ul><li>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 </li></ul><ul><ul><li>Ya sabemos que el sentido común es el menos común de los sentidos… </li></ul></ul>
    24. 24. Evitar roundtrip (en la medida de lo posible) <ul><li>Roundtrip engineering permite cambiar tanto los modelos como el código y mantener a ambos sincronizados. </li></ul><ul><li>En teoría parece una muy buena idea </li></ul><ul><ul><li>Se genera parte del código </li></ul></ul><ul><ul><li>Se complementa a mano y esos cambios se preservan si se regenera el código a partir de una evolución de los modelos </li></ul></ul><ul><li>En la práctica no lo es tanto </li></ul><ul><ul><li>Pocas herramientas ofrecen esta posibilidad </li></ul></ul><ul><ul><li>Hay que ser cuidadoso al hacer los cambios </li></ul></ul><ul><ul><li>Trabajo addicional de anotaciones para marcar las zonas a no modificar </li></ul></ul><ul><li>Mejor generar completamente parte de la aplicación que parcialmente toda la aplicación!! </li></ul>
    25. 25. UML vs DSLs <ul><li>Se habla mucho de los Domain-Specific Languages ( DSLs) </li></ul><ul><li>Un DSL permite proporcionar al usuario un lenguaje (de modelado) perfectamente adaptado a la semántica del dominio </li></ul><ul><li>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 </li></ul><ul><ul><li>Sintaxis, entorno de modelado, validación, ... </li></ul></ul><ul><li>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 </li></ul><ul><li>UML es un multi-domains language, es decir sirve para muchas cosas. Evitar reinventar la rueda! </li></ul>
    26. 26. Pero a veces no hay más remedio… <ul><li>Entornos para la creación de DSLs textuales: EMFText, XText, TCS </li></ul><ul><li>Entornos para la creación de DSLs gráficos: GMF y Graphiti. </li></ul><ul><li>En los dos casos, el diseñador define el metamodelo del DSL y indica la notación (gráfica o textual) para cada elemento </li></ul><ul><li>Las herramientas generan “gratis” un entorno de modelado completo para el nuevo lenguaje </li></ul><ul><li>Esto puede ser necesario, por ej., para modelar interfaces gráficas complicadas, una de las limitaciones del UML </li></ul>
    27. 27. Ej. DSL - MOSKitt User Interface Modeling
    28. 28. UML Ejecutable <ul><li>Programar con UML ya es ahora posible </li></ul><ul><ul><li>Estándard fUML ( Foundational UML specification) </li></ul></ul><ul><ul><li>Notación textual Alf (para escribir “pseudocódigo” de forma independiente al lenguaje de programación </li></ul></ul><ul><ul><li>Ej. totalBalance = 0; for (balance in myCustomer.accounts.balance) { totalBalance += balance; } </li></ul></ul><ul><li>Que sea posible no quiere decir que sea recomendable… </li></ul><ul><li>En estos momentos casi no hay herramientas </li></ul><ul><li>Mejor estrategia common-sense para las fáciles y programación directa para las difíciles </li></ul>
    29. 29. Code generation vs Model Interpretation <ul><li>Model interpretation facilita el uso de MDD a gente no técnica (e.j. despliegue automático en la cloud) </li></ul><ul><li>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 </li></ul><ul><li>Hay estrategias mixtas (despliegue automàtico en generación, intepretación a través de generación interna,…) </li></ul><ul><li>Si mejor utilizar generación de código </li></ul>
    30. 30. 2. Mis consejos acerca de la herramienta a elegir
    31. 31. Herramientas de dibujo vs Herramientas de Modelado <ul><li>Cuidado con las herramientas de dibujo. Más usables pero no entienden la semántica del lenguaje </li></ul><ul><li>Dificil interactuar con ellas: </li></ul><ul><ul><li>Exportación sólo como imagen gráfica </li></ul></ul><ul><ul><li>API limitada a las formas gráficas (se puede pedir “dame todos los rectángulos” pero no “dame todas las clases”) </li></ul></ul><ul><li>Escoger siempre una herramienta de modelado real </li></ul>
    32. 32. Herramientas de modelado vs Herramientas MDD <ul><li>Las herramientas MDD se han creado desde el principio con la intención de automatizar el proceso de desarrollo </li></ul><ul><li>El objetivo principal de las herramientas de modelado es permitir la especificación de sistemas software (para generar código, como documentación,…) </li></ul><ul><li>Con el tiempo todas las herramientas de modelado han incorporado funcionalidades de generación de código. Ojo: </li></ul><ul><ul><li>Muchas veces limitadas a generar skeletons o código muy parcial </li></ul></ul><ul><ul><li>Pueden obligar a añadir muchas anotaciones en los modelos </li></ul></ul><ul><li>Modelos para comunicación? Mejor una herramienta de modelado </li></ul><ul><li>Modelos para generación? Mejor una herramienta MDD </li></ul>
    33. 33. Diferentes modelos de negocio <ul><li>Herramientas Open Source </li></ul><ul><li>Comprar licencia </li></ul><ul><li>Pagar por uso </li></ul><ul><li>Ojo, a veces lo barato sale caro. Las herramientas OSS normalmente necesitan un mayor nivel de conocimiento para sacarles partido </li></ul><ul><li>Pagar por uso es la mejor opción para permitir empezar poco a poco y escalar después si es necesario </li></ul>
    34. 34. ¿Texto o gráficos? <ul><li>Los modelos no tienen pq estar definidos siempre con una notación gráfica </li></ul><ul><li>Cada una tiene sus ventajas: </li></ul><ul><ul><li>Gráfico: mejor comprensión global, aspectos estáticos,… </li></ul></ul><ul><ul><li>Textual: más parecido a la programación, mejor para aspectos dinámicos de bajo nivel </li></ul></ul><ul><li>Hay muchas herramientas para UML textual http://modeling-languages.com/content/uml-tools#textual </li></ul><ul><li>Combinarlas dependiendo del tipo de modelo. </li></ul>
    35. 35. Otras características a tener en cuenta <ul><li>Usabilidad? </li></ul><ul><li>Modelado colaborativo? </li></ul><ul><li>Control de versiones? </li></ul><ul><li>Gestión de modelos? </li></ul><ul><li>Flexibilidad de la herramienta? </li></ul><ul><li>Gran influencia en el uso final o no de la herramienta en la empresa. Si genera un código excelente pero no es usable… </li></ul>
    36. 36. Objetivo ideal: Turing test for MDD tools <ul><li>Idealmente, las herramientas MDD deber ían pasar mi adaptación del turing test para herramientas de generación de código: </li></ul><ul><li>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 </li></ul><ul><li>Aunque, por supuesto, todavía estamos lejos de este punto… </li></ul><ul><li>Gran influencia en el uso final o no de la herramienta en la empresa. Si genera un código excelente pero no es usable… </li></ul>
    37. 37. Ejemplo 0: DIY - Crear tu propia herramienta <ul><li>Mejor opción: basarla en Eclipse y reutilizar los componentes del Eclipse Modeling Project (EMP) </li></ul><ul><li>EMP propone componentes para: </li></ul><ul><ul><li>Definir modelos (EMF) </li></ul></ul><ul><ul><li>Transformaciones M2M (e.j. ATL) </li></ul></ul><ul><ul><li>Transformaciones M2T (e.j. JET, Xpand, …) </li></ul></ul><ul><ul><li>Definición de DSLs (XText, EMFText, TCS,..) </li></ul></ul><ul><li>Que puedes combinar para crear tu propio proceso MDD </li></ul><ul><li>Sólo apta para usuarios avanzados!!! </li></ul>
    38. 38. Ejemplo 1: Acceleo Open Source Template-based (adaptable!) Algunas predefinidas
    39. 39. Ejemplo 2: WebML Web applications Code-generation Java
    40. 40. Ejemplo 3: Modeling-Languages.com Filosofia Common-sense MDD Web applications Code-generation SQL & PHP/Symfony & Python/Django
    41. 41. Ejemplo 4: Mendix Web applications Model Interpretation
    42. 42. Ejemplo 5: OutSystems Web applications Code-generation C# and Java
    43. 43. Ejemplo 6: Novulo Web applications Code-generation .NET
    44. 44. 3. Mis consejos sobre el proceso MDD
    45. 45. MDD se integra en cualquier tipo de proceso de desarrollo <ul><li>MDD es más un framework de desarrollo que un proceso de desarrollo específico </li></ul><ul><li>MDD puede usarse como parte de procesos waterfall o en procesos de tipo Agile </li></ul><ul><li>Por ejemplo: </li></ul><ul><ul><li>Modelado adaptado a Agile: Agile Modeling </li></ul></ul><ul><ul><li>MDD adaptado a Agile: Agile MDA </li></ul></ul><ul><li>Más info en: Agile and Modeling / MDE : friends or foes? (en el portal de modelado) </li></ul>
    46. 46. <ul><li>No es suficiente con comprar una buena herramienta </li></ul><ul><li>Falta invertir también en la gente. Hay que asegurarse que el equipo de desarrollo está preparado: </li></ul><ul><ul><li>¿Y si nadie sabe modelar? Un buen programador no es necesariamente un buen analista </li></ul></ul><ul><ul><li>MDD implica nuevos roles, taras y dependencias entre los miembros del equipo -> No siempre el que las hace ve el Bº </li></ul></ul><ul><ul><li>No escoger como primer proyecto un proyecto complicado </li></ul></ul><ul><ul><li>Mejor si un experto os supervisa al principio </li></ul></ul><ul><li>Y tener paciencia </li></ul><ul><ul><li>Toda nueva tecnología disminuye la productividad al principio </li></ul></ul>pero hay que hacer las cosas bien <ul><li>Recordad: “Introduction of ANY new technology decreases productivity in the short term” </li></ul>
    47. 47. Basta por hoy, pero podemos seguir la discusión más tarde …
    48. 48. Sigamos la discusión http://modeling-languages.com [email_address] @softmodeling

    ×