026 estado del arte de mdd model driven development
DESCRIPTION
TRANSCRIPT
MDD1Dr. Pedro J. Molina, MMIX.14 de Septiembre, 2009
Dr. Pedro J. Molina Ingeniero de SoftwareCapgemini España | Valencia
http://pjmolina.com/metalevel
Estado del arteMDD
Dr. Pedro J. Molina, MMIX. 214 de Septiembre, 2009
Desarrollo de software:¿arte o ingeniería?
Ciudad de las Artes y Las Ciencias. Valencia, España.
Dr. Pedro J. Molina, MMIX. 314 de Septiembre, 2009
Dr. Pedro J. Molina, MMIX. 414 de Septiembre, 2009
Desarrollo de Software
1/9
8/9
Dr. Pedro J. Molina, MMIX. 514 de Septiembre, 2009
Escenario actual Siglo XXI, Sociedad del Conocimiento
Demanda SW en gran cantidad De calidad, robusto, rápido (Time to Market) Más a menor precio
La demanda cae en épocas de crisis
Sin embargo el SW, en general Es muy complejo gestión de la configuración, análisis de
impacto Tareas repetitivas propensas a errores (plumbing) Requiere de profesionales cualificados, experimentados y
motivados.
Dr. Pedro J. Molina, MMIX. 614 de Septiembre, 2009
MDD Agenda
introducción qué porqué hoy mañana conclusión
Model Driven DevelopmentDesarrollo Dirigido por Modelos
Dr. Pedro J. Molina, MMIX. 714 de Septiembre, 2009
breve presentación
Pedro J. Molina Doctor e Ingeniero en Informática por la Univ. Politécnica de
Valencia, 2003 Tesis doctoral en Generación de código para Interfaces de Usuario
en aplicaciones de negocio Ingeniero Técnico en Informática de Gestión por la Univ. de
Castilla-La Mancha en Albacete, 1996
UPV y CARE Technologies Investigador de Ingeniería de SW Desarrollo de generadores de código comerciales para interfaces
de usuario de aplicaciones de negocio
Capgemini España Arquitecto de SW Jefe de proyectos Especialista en MDD y .NET
MDD8Dr. Pedro J. Molina, MMIX.14 de Septiembre, 2009
qué
Dr. Pedro J. Molina, MMIX. 914 de Septiembre, 2009
niveles de abstracción
Código máquina
COBOL / C / Basic / Java
Ensamblador
4GL
Modelos / Especificaciones
Dominio de aplicación
Gap
sem
ántic
o
Niv
el d
e ab
stra
cció
n
The entire history of software engineering is one of rising levels of abstraction (abstraction is the primary way we as humans deal with complexity).
Grady Booch
Dr. Pedro J. Molina, MMIX. 1014 de Septiembre, 2009
¿qué es un dominio?
Implementación
Especificación
Requisitos
Despliegue
Sistemasde Gestión
Sistemas deTiempo Real
Sistemasde
controlaéreo
Sistemasde
Gestiónde
Equipajes
Sistemasde
Gestiónde
Seguros
Dr. Pedro J. Molina, MMIX. 1114 de Septiembre, 2009
<CallRecord>
<caller><number>07713248</number>
¿qué es un lenguaje?
C(x) h C(x) t 2m xih = –
Textual Gráfico
Declarativo
Imperativo
class Factura : Documento{
public void Emitir()
Luís galletas 24 verde
José pasteles 32 azul
EmpleadoNombreDirecciónPromocionar
PuestoDescripciónSalarioAsignar
0..*
a>b && c==d
Llamada
Grabación
Duración
Coste min.
DB
Dr. Pedro J. Molina, MMIX. 1214 de Septiembre, 2009
¿qué es un modelo? Un modelo permite describir una familia de problemas dentro de un
dominio dado Tiene el grado de abstracción cuidadosamente seleccionado para:
Descartar detalles irrelevantes (reduce complejidad) Descartar detalles constantes en la familia (reduce complejidad) Explicitar los aspectos importantes (variables) (pero no oculta lo relevante)
Cliente Tarjeta
1 *
tiene
¿Qué es un meta-modelo? Un modelo de definición de modelos.
Clase Asociación
Origen
Destino
CardinalidadAtributos
Dr. Pedro J. Molina, MMIX. 1314 de Septiembre, 2009
regla de Novak
“La programación automática se define como la síntesis de un programa a partir de una especificación (o modelo).
Para que la programación automática sea útil, la especificación debe ser más pequeña y fácil de crear que el programa construido de la manera convencional con un lenguaje de programación.”
G.S. Novak
Dr. Pedro J. Molina, MMIX. 1414 de Septiembre, 2009
principios de modelado Tan simple como sea posible (KISS)
pero expresivo Semánticamente bien definido Canónico (DRY)
solo una manera de expresar el mismo concepto
Correcto nivel de abstracción Separación de aspectos (SoC)
Mantener modelos organizados y manejables Agnóstico respecto a la tecnología Punto de vista pragmático
si no lo vas a usar, no lo modeles, todavía
Dr. Pedro J. Molina, MMIX. 1514 de Septiembre, 2009
principios para generación de código Ingeniería hacia delante
Forward Engineering
El valor esta en el modelo el código es descartable Refactorizable, regenerable
siempre que sea necesario
La tecnología cambia más rápido que los modelos
Dr. Pedro J. Molina, MMIX. 1614 de Septiembre, 2009
¿modelarlo todo? Generar el 100% del código ¿Utopía?
Depende mucho del dominio y de lo acotado que esté Posible en el 5-10% de los casos, resto aproximación del
80%-20%
La pregunta útil no es: ¿Podemos modelarlo todo?
Las preguntas pragmáticas son: ¿Merece la pena modelar esta característica?
¿El nivel de abstracción estará todavía en sincronía con el modelo tras añadir la característica?
Dr. Pedro J. Molina, MMIX. 1714 de Septiembre, 2009
¿¡modelarlo todo!?
Nueva característica propuesta al modelo
¿Puede ser modelada?
Análisis de Coste/Be-
neficio
Cambio manual al código
Proporcionar un punto de extensión al usuario en el código
generado
Incluir la característica en el Modelo y Editores
Sí
No
Rentable
No rentable
Característica que no puede ser modelada hoy
¿La nece-sitamos?
¡Olvidalo!
¿Qué características deben ser añadidas a un modelo? Aproximación totalmente pragmática: dirigida por la ley
de Novak.
Sí
No
1
2
3
Dr. Pedro J. Molina, MMIX. 1814 de Septiembre, 2009
¿qué (y qué no) incluir en el modelo?
“Lo bueno, si breve, dos veces bueno.”
Baltasar Gracián, (siglo XVII)
Variable vs
Inmutable
“Everything should be as simple as possible,but no simpler.”
Albert Einstein, (siglo XX)
Dr. Pedro J. Molina, MMIX. 1914 de Septiembre, 2009
separation of concerns (SoC)Conocimiento capturado en dos compartimentos separados:
¿Qué?
¿Cómo?
Conocimiento de negocio: capturado y encapsulado en forma de modelos (especificaciones): aislado de aspectos tecnológicos.
Conocimiento tecnológico: capturado y encapsulado en forma de buenas practicas, frameworks, plantillas, patrones diseño en generadores de código e interpretes.
Dr. Pedro J. Molina, MMIX. 2014 de Septiembre, 2009
mapa conceptual de la generación de código
EspecificaciónCódigoFuente
Plantilla Meta-modelo
Algoritmos detransformación
Programas Modelos
Clases / Tipos / Meta
Instancias
Ingeniería Inversa
Abst
racc
ión
Síntesis
Correspon-dencias
Inst
anci
ació
n
Abst
racc
ión
Cambia con la tecnología
Cambia con el negocio
Tiende a ser bastante estable
Código descartable
¡AGIL!
Cambia con la tecnología
Tecnología
Negocio
MDD21Dr. Pedro J. Molina, MMIX.14 de Septiembre, 2009
porqué
Dr. Pedro J. Molina, MMIX. 2214 de Septiembre, 2009
ROI
Economía de alcance Economía de escala El modelo económico de MDD
Calidad Impacto en la ciclo de vida del
desarrollo
Dr. Pedro J. Molina, MMIX. 2314 de Septiembre, 2009
economía de escala
Economía de escala (economies of scale): La condición donde pocas entradas, como esfuerzo y tiempo, son
necesarias para producir grandes cantidades de una única salida. [Wit96]
Pero: ¡No aplica en Software!Una vez producido el bien¡el coste de copia es = ¥ 0!
Fabrica de galletas japonesa: Línea de producción.
Dr. Pedro J. Molina, MMIX. 2414 de Septiembre, 2009
Dr. Pedro J. Molina, MMIX. 2514 de Septiembre, 2009
economía de alcance Economía de alcance (economies of scope):
La condición donde pocas entradas, como esfuerzo y tiempo, son necesarias para producir una gran variedad de salidas. Se produce mayor valor añadido produciendo de manera conjunta diferentes salidas. Producir cada salida de modo aislado provoca un sobrecosto en las partes comunes.
La economía de alcance ocurre cuando el coste de combinar dos o más productos en una sola línea de producción es menor que producirlos por separado. [Wit96]
Dr. Pedro J. Molina, MMIX. 2614 de Septiembre, 2009
industrialización
Producción en masa
Cambio de procesoEstable Dinámico
Cam
bio
en e
l pro
duct
oD
inám
ico
Esta
ble
Producto artesanoPersonalización en masa
Mejora continua
CMMAgil
MDD, Factorías de SW
CD, DVD, Copia de ficheros
Basado en trasparencia original de: Steve Cook
Economía de escala
Economía de alcance
Aseguramiento de la calidadMejora del
proceso
Pieza únicaIrrepetible
Arte
Dr. Pedro J. Molina, MMIX. 2714 de Septiembre, 2009
MDD: modelo económico
Ingeniería de Dominio
Ingeniería de Aplicación
Entorno de desarrollode aplicaciones
Aplicaciones
Retroalimentación: Sugerencias de los
clientes Sugerencias sobre el
entorno de desarrollo
Retorno (ahorro en la construcción)
Inversión
Dr. Pedro J. Molina, MMIX. 2814 de Septiembre, 2009
MDD: modelo económico Coste tradicional = N * CT Coste con MDD = Inv + N * CF
Miembros de la familia
1 2 3 4 5
5 CT
4 CT
3 CT
2 CT
CT
Co
ste
acu
mu
lad
o
Inv
Ahorro AF = CT - CF
Dr. Pedro J. Molina, MMIX. 2914 de Septiembre, 2009
impacto en el ciclo de vida
Mas tiempo en análisis y diseño Menos tiempo en codificación
Menos defectos, más calidad Más productividad
ordenes de magnitud
Integración continua Ciclos de desarrollo más ágiles Menos coste
Dr. Pedro J. Molina, MMIX. 3014 de Septiembre, 2009
coste de defectos y distribución
DefectoBug
CaracterísticaFeature
vs
Dr. Pedro J. Molina, MMIX. 3114 de Septiembre, 2009
coste de defectos y distribución
% Defectos
Análisis Diseño Construcción Mantenimiento
Ciclo de vida tradicionalCiclo de vida con MDD
Coste exponencial de los defectos
Efecto Bola de nieve
1 €
2 €
4 €
8 €
MDD32Dr. Pedro J. Molina, MMIX.14 de Septiembre, 2009
hoy
Dr. Pedro J. Molina, MMIX. 3314 de Septiembre, 2009
UML/MDA ¿es suficiente? UML
Origen: notación de compromiso (propuesta de unificación) OCL: lenguaje de restricciones Gran aceptación, lenguaje común para ingenieros de software
MDA: Model Driven Architecture MDA = MDD con UML Propuesta de la OMG Profiles PIM/PSM MOF / XMI
“Only a 20% of UML is generally needed for SW development.” Ivar Jacobson Pero: ¿Qué porcentaje de mi problema resuelve ese 20%?
Carencias Semántica Lenguaje de acción Dominios no cubiertos por UML: p.e. Interfaces de usuario El abuso de profiles fuerza los modelos Herramientas: multitud de dialectos de XMI Torre de Babel Interoperabilidad prometida Pesadilla
DSL (Domain Specific Languages) y modelos a medida
Dr. Pedro J. Molina, MMIX. 3414 de Septiembre, 2009
quién está haciendo qué Eclipse EMF/GMF
IBM SAP
OpenArchitectureware XText Itemis
xUML / MDA Kennedy Carter Blue Age Artisan AndroMDA Olivanova Model Execution
Microsoft DSL Tools OSLO
MetaCase MetaEdit+
JetBrains MPS
Intentional Software ??
Muchos otros …
Dr. Pedro J. Molina, MMIX. 3514 de Septiembre, 2009
un vistazo a Genexus desde “fuera”
Hechos
Base de conocimiento (KB) Enfocado en el dominio de
aplicaciones de negocio DSLs en Genexus
entidades, modelado de datos reglas de negocio procedural consultas (vistas sobre datos) flujos de trabajo interfaz de usuario
Modelo independiente de tecnología
Generación de código a múltiples entornos
Conclusiones
Ingeniería hacia a delante
Independencia de tecnología
Separación del KH de negocio del KH tecnológico
Diversos DSL para especificar diferentes aspectos (SoC)
El valor está en el “modelo de negocio” (KB)
Genexus es un buen ejemplo de MDD hecho realidad
Dr. Pedro J. Molina, MMIX. 3614 de Septiembre, 2009
experiencias de mercado1. Terminal Financiero
2. Cumplimiento de regulaciones Frameworks / Arquitecturas cliente Guías de estilo / Reglas de nombrado Sabarney Oxley / Audit Trail Accesibilidad AAA / Section 508
3. CUIP Interfaces de usuario Multicanal
Dr. Pedro J. Molina, MMIX. 3714 de Septiembre, 2009
1. terminal financiero PISA es un entorno completo de modelado
construido para Bancaja sobre Visual Studio. MS DSL Tools, XML Schema, gramáticas, compiladores,
generadores de código a C#
El entorno permite modelar y desarrollar funciones de negocio para un Terminal Financiero de un banco
Entorno cerrado: generación de código al 100%.
Totalmente agnóstico respecto a la tecnología. Facil de cambio de arquitectura Cambio del
generador
Dr. Pedro J. Molina, MMIX. 3814 de Septiembre, 2009
1. terminal financiero Entorno de
trabajo integrado en Visual Studio
Dr. Pedro J. Molina, MMIX. 3914 de Septiembre, 2009
1. terminal financiero DSL: Lenguaje
de acción a medida
Sintaxis coloreada
Soporte a Intelisense
Dr. Pedro J. Molina, MMIX. 4014 de Septiembre, 2009
1. terminal financiero Gestión de
errores integrada en Visual Studio
Dr. Pedro J. Molina, MMIX. 4114 de Septiembre, 2009
1. terminal financiero Ejemplo de DSL
Diagrama de navegación
Dr. Pedro J. Molina, MMIX. 4214 de Septiembre, 2009
2. cumplimiento de regulaciones Frameworks / Arquitecturas cliente
Guías de estilo / Guías de nombrado Un generador las aplica SIEMPRE Sin errores, ni
olvidos Más aun: cuando no existe regla, el generador
proporciona una regla de facto determinista MDD aporta soluciones específicas para cada
cliente Sectores propicios
Gran volumen: Banca, Seguros, Energía, Retail, Telco, Distribución
Objetivo: reducir el TCO
Dr. Pedro J. Molina, MMIX. 4314 de Septiembre, 2009
2. cumplimiento de regulaciones Sabarney Oxley / Audit Trail
Caso Enron Cotizadas en bolsa en EE.UU. Auditoria ferrera: ¿quién hizo qué cuando?
Caso: Cliente del sector energético Tamaño: 100 clases (110 tablas) Persistencia a BD con Audit-Trail Diseño de solución implica 3 triggers por tabla Generado al 100%. Audit-Trail como opción si/no del generador
Accesibilidad AAA / Section 508 Garantizar accesibilidad sobre IU es complejo Requiere de auditorias Algunas pautas de accesibilidad pueden ser incorporadas a los generadores
de código Garantizando que los productos producidos cumplen las pautas “por método de
construcción”
Dr. Pedro J. Molina, MMIX. 4414 de Septiembre, 2009
2. cumplimiento de regulaciones Las regulaciones son aburridas
Obligan a los desarrolladores a tenerlas todas en cuenta a la vez y a aplicarlas en cada caso particular
Un olvido no cumplimiento
Regulaciones = Fontanería (Plumbing) Como el hielo bajo el agua del iceberg No se ve, no se valora, pero es muy trabajoso
Recomendación Que sea la máquina la que se encargue de la mayor parte del
trabajo pesado, aburrido y propenso a errores Un generador garantiza el 100% de calidad y cumplimiento
Dr. Pedro J. Molina, MMIX. 4514 de Septiembre, 2009
3. CUIP Patrones Conceptuales de Interfaz de Usuario (CUIP)
Una colección de patrones conceptuales para aplicaciones de gestión en el dominio de interfaces de usuario
Incrementa el nivel de abstracción en el diseño de interfaces de usuario
Interfaces multicanal La habilidad de producir múltiples IUs para diferentes dispositivos a
partir de un modelo origen común
Basado en Patrones Conceptuales de Interfaz de Usuario, el problema de la correspondencia se simplifica a:
hacer corresponder cada patrón con una solución de diseño en el dispositivo particular
Dr. Pedro J. Molina, MMIX. 4614 de Septiembre, 2009
3. CUIP
Más información en http://pjmolina.com/cuipy en http://pjmolina.com/es/investigacion/tesis.php
Dr. Pedro J. Molina, MMIX. 4714 de Septiembre, 2009
3. interfaces de usuario multi-canal
Dr. Pedro J. Molina, MMIX. 4814 de Septiembre, 2009
3. interfaces de usuario multi-canal
Dr. Pedro J. Molina, MMIX. 4914 de Septiembre, 2009
3. interfaces de usuario multi-canal
Dr. Pedro J. Molina, MMIX. 5014 de Septiembre, 2009
arquitectura: generación de código
Especificación
Código fuente
Síntes
is
Plantillas
Transformaciones
Algoritmos
2. Inferencia
1. Carga
3. Generación
Mod
elo
expl
icito
en
mem
oria
Generador
Dr. Pedro J. Molina, MMIX. 5114 de Septiembre, 2009
cadena de generación de código
Generador de ORM
ModeloAbstracto
Modelo de ORM
Modelo de capa Lógica
Modelo de DB
Modelo de IU
Generador de Persistencia
Generador de capa Lógica
Generador de IU
Scripts de DB
Generador de BD especifico
ORMMappings
Generador especifico
de ORM
Código de capa Lógica
Generador de Lógica especifico
Código de IU
Generador de IU
especifico
MDD52Dr. Pedro J. Molina, MMIX.14 de Septiembre, 2009
desafíos
Dr. Pedro J. Molina, MMIX. 5314 de Septiembre, 2009
desafíos: problemas abiertos
round trip
escapes de usuario
evolución de esquema
depuración de modelos
escalabilidad
rigidez
complejidad
Dr. Pedro J. Molina, MMIX. 5414 de Septiembre, 2009
round trip Una de las características más impresionantes de
aplicar MDD es que: el código generado tiene integridad por si mismo
Si se permite mezclar código manual y código generado las cosas se complican.
Una vez se introduce una línea de código manual, nadie puede garantizar la integridad de la mezcla El modelo puede ser validado y comprobado El código manual puede ser válido y compilar Sin embargo, la mezcla de los dos puede no serlo
Dr. Pedro J. Molina, MMIX. 5514 de Septiembre, 2009
escapes de usuario Punto de vista pragmático: TODO no puede ser modelado
Tarde o temprano deberemos permitir escapes al usuario
Los escapes de usuario permiten añadir código manual Per solo en los lugares designados Para extender la funcionalidad que estamos proporcionando
Deben ser cuidadosamente documentados para dejar claro: Los lugares permitidos El objetivo y los problemas que el código de extensión solventará y lo que
NO solventará Las asunciones y convenciones que deban ser seguidas Los cambios a realizar al código manual cuando una nueva versión de
nuestras herramientas aparecen cuidadosos con la compatibilidad hacia atrás
Técnicas para añadir escapes de usuario Creación de Librerías Herencia y sobrecarga en el código generado Clases parciales (C#) Eventos, Intercepción AOP
Dr. Pedro J. Molina, MMIX. 5614 de Septiembre, 2009
personalización Acantilados de personalización
DSL DSL
Lenguaje destino Lenguaje destino
Aprendiz
Iniciado
Normal
Experto
Dr. Pedro J. Molina, MMIX. 5714 de Septiembre, 2009
test de regresión automatizados
Modelo
Generador
Código generado Test de regresión generado
Código manual Test de regresión manual
+ +
Aplicación
Test de regresión
1. Generar código y tests
2. Aplicar los parches
3. Ejecutar los test de regresión
4. Publicar versión
Dr. Pedro J. Molina, MMIX. 5814 de Septiembre, 2009
escalabilidad de modelos
Particionado SoC
El editor importa
namespace Demo{ class Customer { string Name;
string Surname; }}
namespace Demo{ class Customer {
string Address;string Country;int Rating;
}}
namespace Demo{ class Customer { string Name;
string Surname;string Address;string Country;int Rating;
}}
Dr. Pedro J. Molina, MMIX. 5914 de Septiembre, 2009
evolución de modelos Delta de cambios
Históricos Diferencia de modelos Versionado
M0
M1
M2
M3
Aplic. en ejecución
Modelo UML para contabilidad
Metamodelo de UML
Primitivas
Aplicación del cliente Z
KB para contabilidad
Metamodelo de Genexus
Primitivas
Cliente: Luis LopezFactura: 25643
Entidad: FacturaPropiedad: Apellido
Definición de entidadDefinición de formulario
ObjetosRelaciones
ValoresReferencias
Ejemplos:GenexusUMLMOF
MDD60Dr. Pedro J. Molina, MMIX.14 de Septiembre, 2009
conclusión
Dr. Pedro J. Molina, MMIX. 6114 de Septiembre, 2009
conclusiones MDD es una aproximación al desarrollo de SW
Ingenieril Repetible, auditable, medible, optimizable
(En CMMI niveles de calidad) Menor dependencia del artesano
Proporciona un fuerte separación entre El conocimiento del negocio (Bz KH) El conocimiento de la tecnología (Tech KH)
La tecnología cambia cíclicamente como las modas… Evitar que un cambio tecnológico impacte
en el negocio
Dr. Pedro J. Molina, MMIX. 6214 de Septiembre, 2009
conclusiones Hay teoría donde fundamentar MDD
Hay herramientas reales para poner MDD en práctica
Inevitable Es el siguiente paso lógico en la madurez
del desarrollo de SW
Hay fabricantes apostando muy fuerte por MDD
El modo de desarrollo de SW está cambiando y va tomando velocidad
Dr. Pedro J. Molina, MMIX. 6314 de Septiembre, 2009
lecciones aprendidas
El valor está en el modelo
Dr. Pedro J. Molina, MMIX. 6414 de Septiembre, 2009
MDD: objetivo
Ingeniero de SW Automatizar el 80%
para poder ser de nuevo Artista en el 20% restante
MDD65Dr. Pedro J. Molina, MMIX.14 de Septiembre, 2009
referencias
Dr. Pedro J. Molina, MMIX. 6614 de Septiembre, 2009
referencias Comunidades sobre MDD / MDA/ DSL
Model Driven Software Networkhttp://modeldrivensoftware.net/
Conferencia Code Generation 2010 http://www.codegeneration.net/cg2010/
DSL Eclipse EMF/GMF openArchitectuware Microsoft DSL Tools Microsoft OSLO Antlr
Generación de código Program Generators with XML and Java. J. Craig Cleaveland. Prentice
Hall, 2001.
Software Product-Line Engineering: A Family Based Software Development Process. Chi Tau Robert Lai (Preface), David M. Weiss, David L. Parnas. Addison-Wesley, 1999.
Dr. Pedro J. Molina, MMIX. 6714 de Septiembre, 2009
contacto
Dr. Pedro J. Molina Ingeniero de Software Capgemini España | Valencia
Blog: http://pjmolina.com/metalevel Página: http://pjmolina.com/ pjmolina gmail.com
Patrones Conceptuales de Interfaz de Usuario CUIP: http://pjmolina.com/cuip Tesis doctoral: http://pjmolina.com/es/investigacion/tesis.php
@