026 Estado Del Arte De Mdd Model Driven Development

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

Desarrollo de software:
¿arte o ingeniería?
Ciudad de las Artes y Las Ciencias. Valencia, España.

Desarrollo de Software
1/9
8/9

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.

MDD Agenda
 introducción
 qué
 porqué
 hoy
 mañana
 conclusión
Model Driven Development
Desarrollo Dirigido por Modelos

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

MDD
qué

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

¿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

<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

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

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

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

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

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

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

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

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.

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

MDD
porqué

ROI
 Economía de alcance
 Economía de escala
 El modelo económico de MDD
 Calidad
 Impacto en la ciclo de vida del
desarrollo

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.

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]

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

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

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

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

coste de defectos y distribución
Defecto
Bug
Característica
Feature
vs

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 €

MDD
hoy

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

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

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

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

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

 Entorno de
trabajo
integrado en
Visual Studio

 DSL: Lenguaje
de acción a
medida
 Sintaxis
coloreada
 Soporte a
Intelisense

 Gestión de
errores integrada
en Visual Studio

 Ejemplo de DSL
 Diagrama de
navegación

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

 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”

 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

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

3. CUIP
Más información en http://pjmolina.com/cuip
y en http://pjmolina.com/es/investigacion/tesis.php

3. interfaces de usuario multi-canal

arquitectura: generación de código
Especificación
Código fuente
Síntesis
Plantillas
Transformaciones
Algoritmos
2. Inferencia
1. Carga
3. Generación
Modeloexplicito
enmemoria
Generador

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

MDD
desafíos

desafíos: problemas abiertos
 round trip
 escapes de usuario
 evolución de esquema
 depuración de modelos
 escalabilidad
 rigidez
 complejidad

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

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

personalización
 Acantilados de personalización
DSL DSL
Lenguaje destino Lenguaje destino
Aprendiz
Iniciado
Normal
Experto

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

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;
}
}

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

MDD
conclusión

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

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

lecciones aprendidas
El valor está en el modelo

MDD: objetivo
Ingeniero de SW
Automatizar el 80%
para poder ser de nuevo
Artista en el 20% restante

MDD
referencias

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.

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
@

026 Estado Del Arte De Mdd Model Driven Development

Más contenido relacionado

Similar a 026 Estado Del Arte De Mdd Model Driven Development (20)

Más de GeneXus (20)

Último (20)

026 Estado Del Arte De Mdd Model Driven Development

Notas del editor