Embed Size (px)
DESCRIPTION
Consejos para tener éxito en la adopción de una estrategia MDD en vuestro proceso de desarrollo
Citation preview
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 (metametamode
l)
UML (metamode
l)
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
MMa MMb
Ma Mb
MMa2MMb.atl
MMa is thesourcemetamodel
Ma is the source model Mb is the target model
MMB is thetargetmetamodelATL
Transformation
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:
1. UML como solución inmediata a todos los problemas de desarrollo de software de la empresa
2. UML como “método de desarrollo”3. Generación del 100% del código de la aplicación4. UML sirve para modelar cualquier tipo de aplicación5. 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 M
DD!!!!
¿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
Model interpretation Code
generation
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
ClassA
object:B
-Fin1
* -Fin2 *
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 …
