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

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

Me Presento (por educación)

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

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

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

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)

Relationship between MDA/MDD/MDE

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

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

Reality Check – Estado de adopción en la industria

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

Situación del MDD UML?

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é?

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

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

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

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!!!!

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

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

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

1. Mis consejos acerca de la estrategia MDD a adoptar

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,…

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…

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!!

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!

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

Ej. DSL - MOSKitt User Interface Modeling

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

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

2. Mis consejos acerca de la herramienta a elegir

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

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

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

¿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.

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…

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…

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!!!

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

Ejemplo 2: WebML Web applications Code-generation Java

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

Ejemplo 4: Mendix Web applications Model Interpretation

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

Ejemplo 6: Novulo Web applications Code-generation .NET

3. Mis consejos sobre el proceso MDD

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)

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”

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

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

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

by Jordi Cabot on Apr 07, 2011

Accessibility

Categories

Tags

Upload Details

Usage Rights

2 Embeds 41

Statistics

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

http://modeling-languages.com	39
http://us-w1.rockmelt.com	2