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.

¿arte o ingenierí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 .

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 .

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

introducción

qué

porqué

hoy

mañana

conclusión

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

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ántico 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 Nivel de abstracción

¿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

¿qué es un lenguaje? <CallRecord> <caller><number>07713248</number> Textual Gráfico Declarativo Imperativo class Factura : Documento { public void Emitir() a>b && c==d  C(x) h    C(x)  t 2m  x  ih = – Luís galletas 24 verde José pasteles 32 azul Empleado Nombre Dirección Promocionar Puesto Descripción Salario Asignar 0..* 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.

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

“ 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

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

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?

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!? ¿Qué características deben ser añadidas a un modelo? Aproximación totalmente pragmática: dirigida por la ley de Novak. 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! Sí No 1 2 3

¿Qué características deben ser añadidas a un modelo?

Aproximación totalmente pragmática: dirigida por la ley de Novak.

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

“ Lo bueno, si breve,

dos veces bueno.”

Baltasar Gracián, (siglo XVII)

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

Conocimiento capturado en dos compartimentos separados:

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ón Algoritmos de transformación Programas Modelos Clases / Tipos / Meta Instancias 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 Código Fuente Plantilla Meta-modelo Ingeniería Inversa Abstracción Síntesis Correspon-dencias Instanciación Abstracción

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

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]

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 Cambio en el producto Dinámico Estable 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 Producto artesano Personalización en masa Mejora continua CMM Agil MDD, Factorías de SW CD, DVD, Copia de ficheros

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

Retroalimentación:

Sugerencias de los clientes

Sugerencias sobre el entorno de desarrollo

MDD: modelo económico Coste tradicional = N * C T Coste con MDD = Inv + N * C F Miembros de la familia 1 2 3 4 5 5 C T 4 C T 3 C T 2 C T C T Coste acumulado Inv Ahorro A F = C T - C F

Coste tradicional = N * C T

Coste con MDD = Inv + N * C F

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

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 Coste exponencial de los defectos Efecto Bola de nieve 1 € 2 € 4 € 8 € Análisis Diseño Construcción Mantenimiento Ciclo de vida tradicional Ciclo de vida con 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

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 …

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

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 Terminal Financiero Cumplimiento de regulaciones Frameworks / Arquitecturas cliente Guías de estilo / Reglas de nombrado Sabarney Oxley / Audit Trail Accesibilidad AAA / Section 508 CUIP Interfaces de usuario Multicanal

Terminal Financiero

Cumplimiento de regulaciones

Frameworks / Arquitecturas cliente

Guías de estilo / Reglas de nombrado

Sabarney Oxley / Audit Trail

Accesibilidad AAA / Section 508

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

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

Entorno de trabajo integrado en Visual Studio

1. terminal financiero DSL: Lenguaje de acción a medida Sintaxis coloreada Soporte a Intelisense

DSL: Lenguaje de acción a medida

Sintaxis coloreada

Soporte a Intelisense

1. terminal financiero Gestión de errores integrada en Visual Studio

Gestión de errores integrada en Visual Studio

1. terminal financiero Ejemplo de DSL Diagrama de navegación

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

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”

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

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

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

Más información en http://pjmolina.com/cuip

y en http:// pjmolina.com /es/ investigacion / tesis.php

3. i nterfaces de usuario multi-canal

3. i nterfaces de usuario multi-canal

3. i nterfaces de usuario multi-canal

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

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

desafíos

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

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

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

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

Acantilados de personalización

test de regresión automatizados 1. Generar código y tests Modelo Generador Código generado Test de regresión generado Código manual Test de regresión manual + + Aplicación Test de regresión 2. Aplicar los parches 3. Ejecutar los test de regresión 4. Publicar versión

1. Generar código y tests

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

Particionado

SoC

El editor importa

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: Genexus UML MOF

Delta de cambios

Históricos

Diferencia de modelos

Versionado

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

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

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

El valor está en el modelo

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

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

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 @

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