MDD - Desarrollo de software dirigido por modelos

que funciona (¡de verdad!)

Jordi Cabot

http://modeling-languages.com

@softmodeling
Me Presento (por educación)
 Me presento

 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

¿Qué es el desarrollo dirigido por modelos
(MDD – Model Driven Development)?
 MDD – Desarrollo de software dirigido por
modelos
 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
 …
 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 EBNF.g
(metametamodel)

UML Java.g
(metamodel)

ABank.uml 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

MMa is the MMB is the

source target
metamodel
MMa ATL
Transformation MMb metamodel

MMa2MMb.atl

Ma Mb
Ma is the source model Mb is the target model
Reality Check – Estado de adopción en la
industria
 ¿Implantación en la industria?

 S. Mellor: MDE will be commonplace in three years time

 Aunque lo viene diciendo desde el 1985!

Situación del MDD

UML?
 ¿Y porqué?

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

 MDD 2.0

 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
El resto de la presentación hablaremos de
las mejoras estrategias MDD pero
por si quedan escépticos…
 MDD es algo natural

 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

D !!
D
M
e n Qué tienen todos

g u ellos en

S i común?????

Dado un modelo, crean la base

de datos y toda la interfaz
para CRUD
¿Alguien no cree que esto mejora el desarrollo de
software?
OK. Convencido. Pero ¿cómo lo aplico en mi
caso?
 DISCLAIMER: No hay recetas mágicas

 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

 …

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

Model
interpretation Code
generation

 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

object:B
ClassA
-Fin1

* -Fin2 *

 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)
 pero hay que hacer las cosas bien

 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

 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

@softmodeling

jcabot@acm.org