026 Estado Del Arte De Mdd Model Driven Development
1. MDD
1Dr. Pedro J. Molina, MMIX.14 de Septiembre, 2009
Dr. Pedro J. Molina
Ingeniero de Software
Capgemini España | Valencia
http://pjmolina.com/metalevel
Estado del arte
MDD
5. 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.
6. MDD Agenda
introducción
qué
porqué
hoy
mañana
conclusión
Model Driven Development
Desarrollo Dirigido por Modelos
7. 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
9. niveles de abstracción
Código máquina
COBOL / C / Basic / Java
Ensamblador
4GL
Modelos / Especificaciones
Dominio de
aplicación
Gapsemántico
Niveldeabstracció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
10. ¿qué es un dominio?
Implementación
Especificación
Requisitos
Despliegue
Sistemas
de Gestión
Sistemas de
Tiempo Real
Sistemas
de
control
aéreo
Sistemas
de
Gestión
de
Equipajes
Sistemas
de
Gestión
de
Seguros
11. <CallRecord>
<caller><number>07713248</number>
¿qué es un lenguaje?
∂C(x) h2
∂ 2
C(x)
∂ t 2m ∂ x2ih = –
Textual Gráfico
Declarativo
Imperativo
class Factura : Documento
{
public void Emitir()
Luís galletas 24 verde
José pasteles 32 azul
Empleado
Nombre
Dirección
Promocionar
Puesto
Descripción
Salario
Asignar
0..*
a>b && c==d
Llamada
Grabación
Duración
×
Coste min.
DB
12. ¿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)
¿Qué es un meta-modelo?
Un modelo de definición de modelos.
13. 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
14. 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
15. 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
16. ¿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?
17. ¿¡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
18. ¿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)
19. 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.
20. mapa conceptual de la generación de código
EspecificaciónCódigo
Fuente
Plantilla Meta-modelo
Algoritmos de
transformación
Programas Modelos
Clases /
Tipos /
Meta
Instancias
Ingeniería
Inversa
Abstracción
Síntesis
Correspon-
dencias
Instanciación
Abstracció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
22. ROI
Economía de alcance
Economía de escala
El modelo económico de MDD
Calidad
Impacto en la ciclo de vida del
desarrollo
23. 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.
24.
25. 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]
26. industrialización
Producción en masa
Cambio de proceso
Estable Dinámico
Cambioenelproducto
DinámicoEstable
Producto artesanoPersonalización en masa
Mejora continua
CMM
Agil
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 calidad
Mejora del
proceso
Pieza única
Irrepetible
Arte
27. MDD: modelo económico
Ingeniería de Dominio
Ingeniería de Aplicación
Entorno de desarrollo
de aplicaciones
Aplicaciones
Retroalimentación:
Sugerencias de los
clientes
Sugerencias sobre el
entorno de desarrollo
Retorno (ahorro en la construcción)
Inversión
28. 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
Costeacumulado
Inv
Ahorro AF = CT - CF
29. 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
30. coste de defectos y distribución
Defecto
Bug
Característica
Feature
vs
31. coste de defectos y distribución
% Defectos
Análisis Diseño Construcción Mantenimiento
Ciclo de vida tradicional
Ciclo de vida con MDD
Coste
exponencial de
los defectos
Efecto Bola de nieve
1 €
2 €
4 €
8 €
33. 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
34. 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
…
35. 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
36. experiencias de mercado
1. 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
37. 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
42. 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
43. 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”
44. 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
45. 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
46. 3. CUIP
Más información en http://pjmolina.com/cuip
y en http://pjmolina.com/es/investigacion/tesis.php
51. cadena de generación de código
Generador
de ORM
Modelo
Abstracto
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
ORM
Mappings
Generador
especifico
de ORM
Código
de capa
Lógica
Generador
de Lógica
especifico
Código
de IU
Generador
de IU
especifico
53. desafíos: problemas abiertos
round trip
escapes de usuario
evolución de esquema
depuración de modelos
escalabilidad
rigidez
complejidad
54. 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
55. 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
57. 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
58. 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;
}
}
59. 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 Lopez
Factura: 25643
Entidad: Factura
Propiedad: Apellido
Definición de entidad
Definición de formulario
Objetos
Relaciones
Valores
Referencias
Ejemplos:GenexusUMLMOF
61. 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
62. 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
66. referencias
Comunidades sobre MDD / MDA/ DSL
Model Driven Software Network
http://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.
67. 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
@
Notes de l'éditeur
Desarrollo de SW: ¿Arte o Ingeniería?
- ¿Somos artesanos? ¿La calidad de nuestros productos depende de artesanos y artistas: de la inspiración y del genio creativo?
- ¿O somos ingenieros? ¿Tenemos un método reproducible para la construcción? ¿La calidad no depende tanto de la creatividad del individuo sino de que el método sea correctamente aplicado?
¿Y la arquitectura? ¿Es arte o es ingeniería? (Ej. Calatrava / VLC CaC)
Tal vez seamos a la vez artistas e ingenieros (o eso me gusta pensar). Lo que fabricamos ha de ser funcional y operativo, sin renunciar a la belleza y al diseño emocional.
El mundo del siglo XXI, la llamada Sociedad del Conocimiento demanda cada vez más SW para agilizar labores de gestión, mejorar procesos productivos y mejorar nuestra calidad de vida.
Necesitamos producir SW en cantidades industriales. Rápido, barato y robusto (a ser posible).
Por tanto: no debemos descuidar la parte artística pero me atrevería a decir que el 90% de nuestro trabajo como en un coche o en un edificio es Ingeniera y solo un 10% de arte. (Solo un 10% aunque este 10% sin duda marque la diferencia.)
Fontanería.
Plumbing
¿Cómo podemos satisfacer la demanda mejorando al tiempo calidad, productividad y reduciendo costes?
¿Podemos modelarlo todo?
En el extremo ¡sín duda! Pero... ¿a qué coste?
El análisis de coste/beneficio responde a la pregunta
Coste de implementación frente a la frecuencia y coste de un desarrollo convencional
Evitar añadir características de diseño a modelos conceptuales Usar Modelos de diseño (PSM) en su lugar
&lt;number&gt;
Domain Knowledge: Business processes, Business rules, Information, Business driven
Technological Knowledge: Technology driven, Cyclical waves