026 Estado Del Arte De Mdd Model Driven Development

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.


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 DevelopmentDesarrollo 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


qué


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


¿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


<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


¿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


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ó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


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


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


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


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

DefectoBug

CaracterísticaFeature

vs


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 €


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


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


1. terminal financiero Entorno de

trabajo integrado en Visual Studio


1. terminal financiero DSL: Lenguaje

de acción a medida

Sintaxis coloreada

Soporte a Intelisense


1. terminal financiero Gestión de

errores integrada en Visual Studio


1. terminal financiero 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


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”


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


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/cuipy en http://pjmolina.com/es/investigacion/tesis.php

http://pjmolina.com/cuip

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íntes

is

Plantillas

Transformaciones

Algoritmos

2. Inferencia

1. Carga

3. Generación

Mod

elo

expl

icito

en

mem

oria

Generador


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


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 LopezFactura: 25643

Entidad: FacturaPropiedad: Apellido

Definición de entidadDefinición de formulario

ObjetosRelaciones

ValoresReferencias

Ejemplos:GenexusUMLMOF


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


referencias


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.

http://modeldrivensoftware.net/



http://www.codegeneration.net/cg2010/




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

@


http://pjmolina.com/

http://pjmolina.com/cuip


026 Estado Del Arte De Mdd Model Driven Development

Technology

Transcript of 026 Estado Del Arte De Mdd Model Driven Development